Imported from okou-ai/vm0-skills (roadmap-planning/SKILL.md). Install upstream with npx skills add okou-ai/vm0-skills --skill roadmap-planning. Copyright stays with the author.

Roadmap Formats

Choose the format that matches your audience and planning horizon.

Now / Next / Later

A time-horizon approach that avoids false date precision:

Now (active sprint or current month): Work the team is executing. Scope and delivery confidence are high.
Next (one to three months out): Prioritized and roughly scoped. The "what" is clear; the "when" carries some uncertainty.
Later (three to six months and beyond): Strategic intentions and directional bets. Scope and timing remain deliberately flexible.

Best suited for: external communication, leadership updates, and teams that want to avoid locking into specific dates prematurely.

Thematic Quarterly Plans

Structure each quarter around two or three investment themes:

Themes articulate strategic focus areas (examples: "Self-serve onboarding", "Enterprise security posture", "Developer ecosystem growth")
Individual initiatives roll up under each theme
Themes should trace to company or team-level objectives and key results
This format foregrounds the strategic "why" behind every initiative

Best suited for: executive reviews, planning cycles, and demonstrating alignment between execution and strategy.

OKR-Driven Roadmaps

Wire every roadmap item directly to an Objective and Key Result:

Begin with the team's OKRs for the planning period
Beneath each Key Result, enumerate the initiatives expected to move that metric
Annotate each initiative with its anticipated contribution to the Key Result
This creates a direct accountability chain between delivery and measurement

Best suited for: organizations that run OKR processes and want a tight feedback loop between building and measuring.

Gantt / Timeline View

Calendar-oriented layout showing durations, parallelism, and sequencing:

Displays start dates, end dates, and work duration for each initiative
Reveals resource conflicts and scheduling bottlenecks
Exposes inter-item dependencies visually
Highlights where parallel workstreams converge

Best suited for: engineering coordination and resource allocation discussions. Avoid sharing externally, as calendar precision sets rigid expectations.

Scoring and Prioritization Models

RICE Scoring

Quantify priority using four dimensions: Score = (Reach x Impact x Confidence) / Effort

Reach: Number of users or customers affected within a defined period. Use concrete estimates ("800 accounts per quarter").
Impact: Degree of change for each person reached. Scale: 3 = transformative, 2 = significant, 1 = moderate, 0.5 = minor, 0.25 = negligible.
Confidence: Certainty in the reach and impact estimates. 100% = data-backed, 80% = reasonable evidence, 50% = informed guess.
Effort: Total person-months across all functions (engineering, design, research, etc.).

Best suited for: comparing a large backlog with quantitative rigor. Less effective for bold strategic bets where impact is inherently speculative.

ICE Scoring

A streamlined alternative when detailed data is unavailable. Rate each item 1-10 on three axes:

Impact: Expected movement on the target metric
Confidence: Reliability of the impact estimate
Ease: Implementation simplicity (inverse of effort; higher means simpler)

Score = Impact x Confidence x Ease

Best suited for: rapid backlog triage, early-stage products, or situations where RICE inputs are unavailable.

MoSCoW Classification

Sort initiatives into four buckets to force prioritization dialogue:

Must have: The plan fails without these. They represent non-negotiable commitments.
Should have: High-value and expected, but the plan remains viable if they slip.
Could have: Welcomed if capacity exists. Dropping them does not affect the timeline.
Won't have: Deliberately excluded for this period. Listing them removes ambiguity.

Best suited for: release scoping and negotiation sessions with stakeholders who need to see what trades are being made.

Value vs. Effort Quadrant

Visualize initiatives on a two-by-two grid:

High value, Low effort (Quick wins): Execute immediately. These are the highest-leverage items.
High value, High effort (Strategic investments): Commit resources deliberately. Worth the cost but need careful planning.
Low value, Low effort (Opportunistic fills): Pick these up during slack periods or between larger efforts.
Low value, High effort (Traps): Remove from consideration. They consume resources with minimal return.

Best suited for: collaborative planning sessions where the team needs shared visual alignment on tradeoffs.

Dependency Management

Taxonomy of Dependencies

Scan for dependencies across these categories:

Technical: Initiative B relies on infrastructure or platform changes delivered by Initiative A
Cross-team: Work requires deliverables from design, platform, data engineering, or other product teams
External: Blocked on a vendor deliverable, partner integration, or third-party API
Informational: Requires the output of a research spike, user study, or data analysis before work can begin
Sequential: Feature A must ship before Feature B can start due to shared surfaces or user flow constraints

Handling Dependencies Effectively

Surface every dependency explicitly in the roadmap artifact
Designate a single owner responsible for tracking and resolving each dependency
Establish a "needed by" date: when must the upstream deliverable land for the downstream item to stay on schedule
Pad timelines around dependencies -- they represent the highest-risk nodes in any plan
Escalate cross-team dependencies early; coordination overhead grows with delay
Prepare fallback plans: what is the alternative path if a dependency slips?

Strategies to Minimize Dependencies

Explore whether a reduced-scope version sidesteps the dependency entirely
Use interface contracts or mocks to enable parallel development
Reorder the sequence so the dependency resolves earlier in the timeline
Absorb the dependent work into your own team to eliminate coordination overhead

Team Capacity Planning

Estimating Available Capacity

Start with headcount and the planning window
Deduct known overhead: recurring meetings, on-call rotations, hiring loops, holidays, planned time off
A practical baseline: engineers typically invest 60-70% of their time on planned roadmap work
Account for ramp time when new team members join mid-cycle

Allocation Guidelines

A balanced split for most product teams:

70% strategic delivery: Roadmap initiatives that advance business objectives
20% infrastructure health: Technical debt reduction, reliability hardening, performance tuning, developer tooling
10% reserve: Buffer for urgent requests, incoming escalations, and small-scope opportunities

Adjust the ratios based on context:

Newer products warrant heavier feature investment and lighter debt work
Mature products benefit from increased reliability and scalability spending
Post-incident periods call for elevated infrastructure attention
Hyper-growth phases demand investment in scalability and operational resilience

Balancing Ambition and Reality

When planned commitments exceed available capacity, scope must shrink -- not expectations of individual output
Adopt a standing rule: adding an initiative to the plan requires removing or deferring another
Delivering fewer commitments reliably builds more organizational trust than overcommitting and missing dates

Communicating Roadmap Shifts

Triggers for Roadmap Revisions

A new strategic directive from leadership
User research or customer feedback that reshuffles priorities
Engineering discovery that materially changes effort estimates
A dependency from another team slipping its timeline
Team composition changes: growth, attrition, or key departures
A competitive development demanding a response

Communicating Changes Clearly

State the change directly: What is moving, and in which direction
Explain the catalyst: What new information prompted this decision
Surface the tradeoff: What was deprioritized or deferred to accommodate the shift
Present the revised plan: Updated roadmap reflecting the new state
Address affected parties: Stakeholders who were counting on deprioritized items deserve direct communication

Maintaining Stability

Not every new data point warrants a roadmap revision. Establish a materiality threshold before making changes.
Consolidate adjustments at natural cadence points (monthly or quarterly) unless genuinely urgent.
Distinguish strategic reprioritization (roadmap change) from normal execution refinement (scope adjustment within an initiative).
Track the frequency of roadmap changes. Excessive churn may indicate strategic ambiguity rather than adaptive planning.

roadmap-planning

About