roadmap-planning

What this skill does

## 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 develop