planning-create-roadmapUse this skill when the user says 'create roadmap', 'roadmap', 'product roadmap', 'feature roadmap', 'quarterly roadmap', 'release plan', 'timeline', 'roadmap planning'. Build a structured product roadmap with themes, timeline, prioritization, and communication plan. Do NOT use for: sprint planning or project scheduling.
Independent GitHub snapshot · Automated classification · Original documentation governs
Build strategic product roadmaps that align stakeholder priorities with team capacity. Combines theme-based quarterly planning with RICE prioritization, timeline visualization, and iterative monthly updates.
A good roadmap communicates direction without falsely promising specific dates. It answers two questions the whole organization cares about: what is the team working on and why does it matter? This skill produces a living document organized by strategic themes, prioritized by data (RICE scores), and sized with a 20% buffer for the inevitable unplanned work. The output is audience-ready for stakeholder presentations and simultaneously actionable for engineering sprint planning. The roadmap is reviewed quarterly and updated monthly — daily changes destroy trust.
The tension at the heart of roadmapping is between certainty and flexibility. Stakeholders want firm dates; engineering knows that estimates are ranges, not points. This skill navigates that tension by using "Now/Next/Later" framing for uncertain environments and "Q1-Q4 with monthly milestones" for mature products. Both formats communicate priority and direction without over-committing to dates that will inevitably shift.
Product maturity?
|-- Early stage / high uncertainty --> Now/Next/Later format
| Benefits: Flexible, sets direction, manages expectations
| Drawbacks: Vague on timelines, stakeholders may push for dates
|-- Mature product / predictable delivery --> Q1-Q4 with milestones
| Benefits: Concrete, stakeholder-friendly, tracks progress
| Drawbacks: Creates false precision, harder to change
|-- Enterprise / contractual commitments --> Q1-Q4 with fixed scope
Benefits: Legal/contractual clarity
Drawbacks: Least flexible, highest maintenance overhead
Stakeholder preference?
|-- Outcome-focused --> Theme-based roadmap (what we will achieve)
|-- Date-focused --> Feature-based roadmap (what we will ship by when)
|-- Mixed --> Hybrid: themes for outer quarters, features for next quarter
Data availability?
|-- Quantitative data available (usage metrics, revenue data) --> RICE or WSJF
| RICE: Best for feature-level prioritization, simpler to calculate
| WSJF: Best for SAFe/agile at scale, requires cost of delay data
|-- Qualitative data only (stakeholder input, research) --> MoSCoW or Opportunity Scoring
| MoSCoW: Simple, fast, widely understood by non-technical stakeholders
| Opportunity Scoring: Better for customer-needs-driven prioritization
|-- No data / early stage --> Kano Model or Effort-Impact Matrix
| Kano: Understanding what delights vs what is expected vs basic needs
| Effort-Impact: Quick visual prioritization for early-stage tradeoffs
|-- Regulatory/compliance driven --> Priority overrides all scoring (must-do)
Team allocation?
|-- Dedicated team --> Full-time on roadmap items
| Budget: 60% feature, 20% tech debt, 20% buffer
|-- Shared team --> Splits time across multiple initiatives
| Budget: Allocate by percentage per initiative
|-- Multiple teams --> Each team gets its own roadmap swimlane
Coordinate dependencies across swimlanes with explicit sync points
Has team velocity been measured?
|-- YES (3+ sprints of data) --> Use average velocity for capacity
|-- NO / new team --> Use estimated capacity: (team size * 0.6 * sprint days)
"create roadmap", "roadmap", "product roadmap", "feature roadmap", "quarterly roadmap", "release plan", "timeline", "roadmap planning"
Roadmap document with strategic themes, timeline view (Now/Next/Later or Q1-Q4), prioritized features with RICE scores, and explicit capacity allocation.
Roadmap covers 2-4 consecutive quarters. At least 3 strategic themes defined per quarter. Features listed with RICE scores and assigned to a theme and timeframe. Capacity allocation sums to 100%. Format suitable for stakeholder presentation.
3000 tokens
Collect all inputs before placing anything on the timeline:
Create 3-5 strategic themes per quarter. A theme is a bounded initiative with a clear outcome statement: a sentence describing what will be true when this theme is complete.
Theme quality criteria:
Theme template:
### Theme: {Outcome Statement}
**Success metric:** {metric that defines completion}
**OKR alignment:** {OKR this theme supports}
**Key features:**
- {Feature 1}: {brief description}
- {Feature 2}: {brief description}
Two format options depending on planning horizon certainty.
Now/Next/Later — best for early-stage or fast-moving products:
Q1-Q4 with monthly milestones — best for mature products with predictable delivery:
Timeline construction rules:
Score every feature using RICE before placing it on the timeline.
RICE formula: RICE = (Reach * Impact * Confidence) / Effort
| Component | Description | Scale |
|---|---|---|
| Reach | How many users affected per quarter | Absolute number |
| Impact | Effect magnitude | 1 (low) / 2 (medium) / 3 (high) |
| Confidence | Certainty in Reach and Impact | Percentage (20-100%) |
| Effort | Engineering person-days | Absolute number |
Example: (50,000 users * 2 impact * 80% confidence) / 20 days = 4,000 RICE.
After scoring, apply MoSCoW categories:
Prepare the visual roadmap in two views:
Communication cadence:
Update roadmap status monthly. For each feature, report:
Monthly status report format:
## Roadmap Status: {Month} {Year}
### Shipped This Month
- {Feature}: {brief outcome}
### In Progress
- {Feature}: {progress %, ETA}
### At Risk
- {Feature}: {risk description, mitigation}
### Changes
- {Previous plan} -> {New plan}: {reason}
### Won't Have (This Quarter)
- {Feature}: {reason for deferral}
When: Product-led org, outcome-focused culture Process: Define themes by customer outcomes, not features. Each theme has a hypothesis: "If we deliver {outcome}, we expect {metric} to change by {amount}." Features within a theme can change as long as the outcome stays the same. Best for: Mature products with empowered product teams.
When: Fixed deadline (conference, regulation, contract) Process: Work backward from the fixed date. Scope is variable, time is fixed. Use MoSCoW aggressively — Must Have is the absolute minimum. Track feature count against remaining time weekly. Best for: Event-driven launches, compliance deadlines, contractual commitments.
When: Multiple small teams working independently Process: Use Now/Next/Later format with all teams. Each team has its own swimlane. Dependencies between teams are explicitly marked and assigned a dependency owner. Monthly cross-team sync to resolve dependency conflicts. Best for: Organizations with 3+ product teams.
When: High uncertainty, fast-changing market Process: Plan only the next quarter in detail. Quarter 2 is directional. Quarters 3-4 are placeholders. Every month, review the next quarter plan and adjust. Archive old versions to track how priorities changed. Best for: Startups, emerging markets, new product lines.
Exact dates on features create false certainty and erode trust when they slip. Use quarters, months, or "Now/Next/Later" buckets. A roadmap is NOT a project schedule.
Failing to explicitly state what is not being worked on creates the expectation that everything is possible. The "Won't Have" list is essential expectation management.
Without capacity data (velocity, headcount, leaves), the roadmap is a wish list, not a plan. A roadmap without capacity allocation has zero credibility with engineering teams.
Every team has bugs, incidents, escalations, and support requests. Budgeting zero for unplanned work ensures the roadmap will slip. Minimum 20% buffer is non-negotiable.
A roadmap that changes daily is useless. It signals the team has no strategy, only reactions. Establish a monthly update cadence.
If every theme is "improve performance" or "fix bugs," the product is not evolving. At least one theme per quarter should be growth-oriented or customer-facing.
The CEO or VP overrides the RICE score and inserts their pet project without context. If stakeholders override prioritization, the data-driven process loses credibility. Document overrides and their rationale.
Features keep getting pushed to the next quarter without explanation. Track deferred features — if something has been deferred 3+ quarters, it should be explicitly dropped or promoted. Endless deferral is a failure to decide.
## Theme: {Outcome Statement}
**Success metric:** {Single metric that defines completion}
**OKR:** {Linked OKR}
**Dependencies:** {Other themes or external dependencies}
**Risk level:** {High / Medium / Low}
**Features:**
- {Feature}: RICE {score} — Must/Should/Could
- {Feature}: RICE {score} — Must/Should/Could
# Roadmap: {Quarter} {Year}
## Focus
{1-2 sentence strategic focus for the quarter}
## Themes
1. {Theme 1}: {outcome} [{effort estimate}]
2. {Theme 2}: {outcome} [{effort estimate}]
3. {Theme 3}: {outcome} [{effort estimate}]
## Capacity
- Feature work: {n}%
- Tech debt: {n}%
- Buffer: {n}%
## Won't Have
- {Feature}: {reason}
- {Feature}: {reason}
| Metric | Target | How to Measure |
|---|---|---|
| Theme completion rate | > 80% of planned themes | Quarterly review |
| RICE score correlation | High-RICE features deliver > expected impact | Post-launch measurement |
| Deferred feature rate | < 20% of features pushed more than 1 quarter | Track across quarters |
| Stakeholder satisfaction | > 80% feel roadmap reflects their priorities | Quarterly survey |
| Monthly update compliance | 100% of months have status report | Calendar audit |
| Buffer utilization | Actual buffer usage 15-25% | Capacity tracking |
RICE = (Reach * Impact * Confidence) / Effort
Reach = Number of users affected per quarter (e.g., 50,000)
Impact = 1 (low) / 2 (medium) / 3 (high) — estimated effect magnitude
Confidence = Percentage (0-100%) — how confident in Reach and Impact estimates
Effort = Engineering person-days — total cost to deliver
Feature work: 60% — New capabilities, improvements, user-facing changes
Tech debt: 20% — Refactoring, upgrades, performance, security, reliability
Unplanned: 20% — Bugs, escalations, incidents, urgent support requests
WSJF = Cost of Delay / Job Duration
Cost of Delay = User Value + Time Criticality + Risk Reduction / Opportunity Enablement
Job Duration = Estimated effort (same as RICE Effort)
| Category | Meaning | RICE Range | Capacity |
|---|---|---|---|
| Must have | Non-negotiable | Any | 40% |
| Should have | High value | Top 30% of remaining | 30% |
| Could have | Nice to include | Middle 30% | 20% |
| Won't have | Explicitly deferred | Bottom 40% | 10% |
For roadmaps with 50+ features across 4 quarters, spreadsheet performance degrades. Use dedicated roadmap tools (Aha!, Productboard, Notion) for large roadmaps.
Set update cadence proportional to team size. Oversized teams updating weekly waste 50+ hours/month.
A roadmap is NOT a project schedule. Do not put exact dates on features. Use quarters, months, or "Now/Next/Later" buckets. Exact dates create false certainty and erode trust when they slip.
Failing to explicitly state what is not being worked on creates the expectation that everything is possible. The "Won't Have" list is essential expectation management.
Without capacity data (velocity, headcount, leaves), the roadmap is a wish list, not a plan. A roadmap without capacity allocation has zero credibility with engineering teams.
Every team has bugs, incidents, escalations, and support requests. Budgeting zero for unplanned work ensures the roadmap will slip. Minimum 20% buffer is non-negotiable.
A roadmap that changes every day is useless. It signals that the team has no strategy, only reactions. Establish a monthly update cadence.
If every theme is "improve performance" or "fix bugs," the product is not evolving. At least one theme per quarter should be growth-oriented.
| Framework | Time Horizon | Granularity | Best For |
|---|---|---|---|
| Now/Next/Later | 3-9 months | Themes -> Features -> Tasks | Early-stage, uncertain |
| Q1-Q4 with milestones | 12 months | Themes with monthly checkpoints | Mature products |
| OKR-driven | 3-12 months | Objectives -> Key Results -> Initiatives | Outcome-focused |
| SAFe Roadmap | 6-12 months | Program Increments (PI) | Large enterprises |
| Feature-based | 3-6 months | Individual features | Simple products |
| Theme-based | 6-12 months | Strategic themes | Product-led orgs |
references/create-roadmap-fundamentals.md — Roadmap Fundamentalsreferences/create-roadmap-advanced.md — Roadmap Advanced Topicsreferences/roadmap-examples.md — Roadmap Examplesreferences/roadmap-strategies.md — Roadmap Strategiesreferences/roadmap-template.md — Roadmap Templatereferences/roadmap-tools.md — Roadmap Toolsreferences/roadmap-prioritization-methods.md — Roadmap Prioritization Methodsreferences/roadmap-communication-stakeholder.md — Roadmap Communication & Stakeholder Managementcreate-story, create-tech-spec
` interface EventObserver { onEvent(event: T): Promise; }
class EventBus { private observers: Set<EventObserver> = new Set(); subscribe(observer: EventObserver): void { this.observers.add(observer); } unsubscribe(observer: EventObserver): void { this.observers.delete(observer); } async emit(event: T): Promise { const results = Array.from(this.observers).map(o => o.onEvent(event)); await Promise.allSettled(results); } } `
config: defaults: timeout: 30s retryCount: 3 overrides: production: timeout: 60s retryCount: 5 development: timeout: 300s retryCount: 1
| Metric | Threshold | Severity | Action |
|---|---|---|---|
| Error rate | > 1% over 5min | Critical | Page on-call |
| p99 latency | > 2s over 5min | Warning | Investigate |
| Throughput drop | > 50% over 1min | Critical | Check upstream |
| Queue depth | > 1000 over 1min | Warning | Scale consumers |
| Disk usage | > 85% | Warning | Clean or expand |
| Memory usage | > 90% heap | Critical | Restart or scale |
| Anti-Pattern | Symptom | Root Cause | Solution |
|---|---|---|---|
| Premature optimization | Complex code for no measured benefit | Guessing instead of profiling | Measure first, optimize based on data |
| Copy-paste reuse | Duplicate code across codebase | Lack of abstraction | Extract shared logic into libraries |
| Gold-plating | Features with no current requirement | Over-engineering | YAGNI — build what's needed now |
| Magical thinking | Assumptions without validation | Skipping error handling | Handle all failure modes explicitly |
Cache hierarchy: L1 (in-memory local) → L2 (distributed Redis/Memcached) → L3 (CDN/Edge). Cache invalidation: TTL-based (simple, stale), event-based (complex, fresh), write-through (consistent, higher write latency), write-behind (fast writes, eventual consistency).