This process separates maintenance work (updates to existing courses) from development work (new courses and major initiatives).
Each track has its own intake, prioritization, and approval workflow to ensure the Learning Development team balances operational
needs with strategic growth.
Guiding Principles
This process is built on industry best practices and core principles that ensure strategic alignment, resource efficiency, and execution discipline:
- Separate operational from strategic work: Maintenance (10-12% capacity) doesn't compete with strategic development for resources or attention.
- Capital investment requires rigor: Development projects demand business cases, go-to-market plans, and presidential approval before resource commitment.
- GTM readiness is non-negotiable: Products without validated go-to-market plans stay in the backlog. No more "build it and hope" projects.
- Sponsor owns outcomes: Request sponsors own GTM planning by default. If you request it, you have to sell it (or prove internal adoption).
- Revenue owns markets: Since Head of Revenue owns all external markets (B2C, B2B, SFP partners), most GTM plans will be owned by Revenue.
- Transparent prioritization: Weighted scoring makes trade-offs visible and prevents "squeaky wheel" prioritization.
- Weekly pipeline visibility: Development pipeline reviewed at L10 ensures strategic projects stay aligned with company priorities and capacity reality.
- Incremental commitment: Projects move through stages (backlog → this quarter → in progress) with clear gates, not blanket annual commitments.
Process Overview
Track 1: Maintenance
10-12% Team Capacity
Updates to existing published courses, bug fixes, minor content changes, regulatory updates.
- Managed by Head of Learning Development
- RICE prioritization framework
- 48-hour triage, clear SLAs
- No presidential approval needed
Track 2: Development
Remaining Capacity
New course creation, major redesigns, new product lines, platform capabilities.
- Capital investment (requires approval)
- Weighted scoring framework
- Presidential review at weekly L10
- Quarterly commitment cycle
Maintenance Process
Maintenance Workflow
1
Submit Request
Via Maintenance Request Form
2
Triage
Head of LD reviews within 48 hours
3
Prioritize
RICE scoring, added to backlog
4
Execute
Assigned within capacity allocation
5
Complete
Requestor notified
RICE Prioritization Framework
RICE Score = (Reach × Impact × Confidence) / Effort
| Factor |
Scale |
Description |
| Reach |
1-5 |
How many learners/courses affected? (1=Single low-enrollment, 5=Multiple high-enrollment or regulatory mandate) |
| Impact |
1-5 |
What happens if we don't fix? (1=Minor cosmetic, 5=Critical/blocking/non-compliance) |
| Confidence |
50-100% |
How certain are estimates? (50%=guess, 80%=some data, 100%=verified) |
| Effort |
Hours |
Estimated hours to complete (actual number, e.g., 2, 8, 16) |
Maintenance SLAs: Critical (1 week), High (2 weeks), Medium (4 weeks), Low (8 weeks)
Development Process
Development Workflow
1
Submit Brief
Complete Development Project Brief
2
Review
Head of LD validates feasibility
3
Score
President scores at L10
4
Prioritize
Ranked in Development Pipeline
5
Commit
Quarterly commitment, project launch
Weighted Scoring Framework
Total Score = (Strategic × 0.25) + (Financial × 0.20) + (GTM × 0.20) + (Urgency × 0.15) + (Risk × 0.10) + (Efficiency × 0.10)
| Criterion |
Weight |
Scale (1-5) |
| Strategic Alignment |
25% |
5=Core to strategy, 3=Aligned, 1=Tangential |
| Financial Return |
20% |
5=>300% ROI, 4=200-300%, 3=100-200%, 2=50-100%, 1=<50% |
| Go-to-Market Readiness |
20% |
5=Complete validated plan, 3=Partial plan, 1=No GTM plan |
| Time to Market / Urgency |
15% |
5=Critical deadline, 3=Seasonal opportunity, 1=No urgency |
| Risk / Feasibility |
10% |
5=Proven/low risk, 3=Moderate risk, 1=High risk/experimental |
| Resource Efficiency |
10% |
5=Small (<200h), 3=Medium (200-800h), 1=X-Large (>2000h) |
L10 Integration: Development pipeline reviewed weekly at Leadership Team L10 meeting (15 min agenda slot after Scorecard Review, before Rock Review). Includes GTM plan review before committing resources.
Supporting Documents & Templates
📋
Maintenance Request Form
Standardized intake form for all maintenance requests. Captures course info, request type, urgency, and requestor details.
View Form Template
📄
Development Project Brief
1-2 page template for development requests. Includes strategic alignment, SPICED business case, ROI estimate, and dependencies.
View Brief Template
📊
Maintenance Backlog (Kanban)
Live view of all maintenance requests by status: Submitted → Triaged → This Week → In Progress → Done.
View Backlog
🎯
Development Pipeline
Ranked list of all development projects with scores, status, and quarterly commitments. Updated weekly at L10.
View Pipeline
📈
Capacity Dashboard
Real-time view of team capacity utilization: maintenance allocation, development hours committed, available capacity.
View Dashboard
📚
Process Documentation
Complete process guide including workflows, scoring frameworks, roles & responsibilities, FAQs, and implementation roadmap.
View Full Guide
Key Roles & Responsibilities
Head of Learning Development
- Owns both Maintenance and Development tracks
- Triages all maintenance requests within 48 hours
- Reviews all development project briefs within 1 week
- Estimates effort for all work
- Manages team capacity allocation (10-12% to maintenance)
- Reports pipeline status at weekly L10
- Escalates capacity issues or blocked projects to President
President (Glenn Bosch)
- Scores and ranks all development projects using weighted framework
- Approves development projects and quarterly commitments
- Reviews pipeline at weekly L10 (10-15 min)
- Makes final call on prioritization conflicts or strategic trade-offs
Leadership Team
- Submits development requests via Project Brief
- Owns Go-to-Market planning for their requests (request sponsor = GTM owner)
- Provides input on strategic alignment and urgency during L10 review
- Champions approved projects in their functions
Head of Revenue (Primary GTM Owner)
- Owns GTM planning for most development projects (Revenue owns markets: B2C, B2B, SFP partners)
- Defines target customer, value proposition, pricing, channel strategy
- Commits to launch execution with 90-day plan and success metrics
- Accountable for post-launch performance vs. projections
GTM Ownership Rule: Request sponsor owns GTM planning by default. Since Revenue owns markets (B2C, B2B, partner channels), most GTM plans will be owned by Head of Revenue. Exceptions: Internal-facing projects (platform tools, delivery improvements) where sponsor owns internal stakeholder adoption.
Success Metrics
| Metric |
Target |
Tracked |
| Maintenance capacity utilization |
10-12% |
Weekly |
| Maintenance SLA compliance |
>90% |
Monthly |
| Development projects on time |
>80% |
Quarterly |
| Development projects on budget |
>80% |
Quarterly |
| Team capacity utilization |
85-95% |
Weekly |
| Pipeline velocity |
3-5 projects/quarter |
Quarterly |
Implementation Roadmap
Week 1: Setup
- Customize intake forms and templates
- Set up project management tool (Ninety.io, Asana, or Monday.com)
- Define team capacity and calculate 10-12% maintenance allocation
- Train Learning Development team on new process
- Present to Leadership Team at L10 for buy-in
Weeks 2-4: Pilot
- Run new process for 3 weeks
- Migrate existing requests into appropriate tracks
- Score existing development projects
- Track submission volume, triage time, capacity utilization
- Collect feedback from team and requestors
Week 5: Refine & Lock In
- Adjust scoring weights if needed
- Refine SLAs based on actual cycle times
- Lock in process for next quarter
Ongoing: Quarterly Reviews
- Review process effectiveness every quarter
- Adjust capacity allocation if maintenance consistently over/under
- Update prioritization criteria if strategy shifts
Alignment with WKT's RevOps Model
This process enables WKT's RevOps revenue model (Demand → Revenue → Delivery) by ensuring Learning Development supports all three functions strategically, not reactively.
Cross-Functional Support
Learning Development sits at the intersection of all three revenue functions:
- Demand needs content to convert pipeline (landing pages, demos, trial experiences)
- Revenue needs products to sell (new B2B courses, SFP offerings, pilot programs)
- Delivery needs materials to retain and expand (onboarding content, training, expansion SKUs)
The weighted scoring ensures no single function monopolizes Learning Dev capacity. A Demand request (landing page) competes fairly against a Revenue request (new course) based on Strategic + Financial + GTM + Urgency + Risk + Efficiency.
GTM Ownership with Revenue
Since Head of Revenue owns markets (B2C, B2B, SFP partners), most development projects require Revenue to own go-to-market planning. This prevents "build it and hope" projects and ensures Learning Dev output aligns with revenue strategy.
Prevents Misalignment
Without this process:
- Learning Dev builds what's requested, not what's strategic
- Revenue sells capabilities Learning Dev hasn't prioritized
- Delivery commits to features Learning Dev has deprioritized
- Demand launches campaigns for products with no GTM plan
L10 integration surfaces conflicts early and forces cross-functional collaboration before resource commitment.
Compensates for Missing RevOps Enablement
WKT doesn't yet have a RevOps Enablement Manager. This process compensates by:
- Forcing GTM rigor upfront (20% scoring weight)
- Requiring sponsors to own GTM (Revenue typically, with Demand support)
- Providing weekly L10 cross-functional coordination
When RevOps Enablement fills: They'll validate GTM plans with data/benchmarks, track post-launch performance vs. projections, and close the feedback loop that this process currently doesn't capture.
What's Still Missing
This process ends at "Launched." The RevOps model requires a post-launch feedback loop:
- Did the GTM plan work? (Revenue vs. projection, CAC, conversion rate)
- Did it impact the funnel? (Pipeline growth, deal velocity, win rate)
- Did customers adopt? (Usage, NPS, expansion rate)
RevOps Enablement will close this loop by tracking actual vs. projected outcomes and feeding learnings back into future prioritization.