| name | roadmap-update |
| description | Update, create, or reprioritize your product roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from scratch. |
| argument-hint | <update description> |
Roadmap Update
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Update, create, or reprioritize a product roadmap.
Usage
/roadmap-update $ARGUMENTS
Workflow
1. Understand Current State
If ~~project tracker is connected:
- Pull current roadmap items with their statuses, assignees, and dates
- Identify items that are overdue, at risk, or recently completed
- Surface any items without clear owners or dates
If no project management tool is connected:
- Ask the user to describe their current roadmap or paste/upload it
- Accept any format: list, table, spreadsheet, screenshot, or prose description
2. Determine the Operation
Ask what the user wants to do:
Add item: New feature, initiative, or work item to the roadmap
- Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies
- Suggest where it fits based on current priorities and capacity
Update status: Change status of existing items
- Options: not started, in progress, at risk, blocked, completed, cut
- For "at risk" or "blocked": ask for the blocker and mitigation plan
Reprioritize: Change the order or priority of items
- Ask what changed (new information, strategy shift, resource change, customer feedback)
- Apply a prioritization framework if helpful — see Prioritization Frameworks below for RICE, MoSCoW, ICE, and value-vs-effort
- Show before/after comparison
Move timeline: Shift dates for items
- Ask why (scope change, dependency slip, resource constraint)
- Identify downstream impacts on dependent items
- Flag items that move past hard deadlines
Create new roadmap: Build a roadmap from scratch
- Ask about timeframe (quarter, half, year)
- Ask about format preference (Now/Next/Later, quarterly columns, OKR-aligned) — see Roadmap Frameworks below
- Gather the list of initiatives to include
3. Generate Roadmap Summary
Produce a roadmap view with:
Status Overview
Quick summary: X items in progress, Y completed this period, Z at risk.
Roadmap Items
For each item, show:
- Name and one-line description
- Status indicator (on track / at risk / blocked / completed / not started)
- Target timeframe or date
- Owner
- Key dependencies
Group items by:
- Timeframe (Now / Next / Later) or quarter, depending on format
- Or by theme/goal if the user prefers
Risks and Dependencies
- Items that are blocked or at risk, with details
- Cross-team dependencies and their status
- Items approaching hard deadlines
Changes This Update
If this is an update to an existing roadmap, summarize what changed:
- Items added, removed, or reprioritized
- Timeline shifts
- Status changes
4. Follow Up
After generating the roadmap:
- Offer to format for a specific audience (executive summary, engineering detail, customer-facing)
- Offer to draft communication about roadmap changes
- If project management tool is connected, offer to update ticket statuses
Roadmap Frameworks
Now / Next / Later
The simplest and often most effective roadmap format:
- Now (current sprint/month): Committed work. High confidence in scope and timeline. These are the things the team is actively building.
- Next (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.
- Later (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.
When to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.
Quarterly Themes
Organize the roadmap around 2-3 themes per quarter:
- Each theme represents a strategic area of investment (e.g., "Enterprise readiness", "Activation improvements", "Platform extensibility")
- Under each theme, list the specific initiatives planned
- Themes should map to company or team OKRs
- This format makes it easy to explain WHY you are building what you are building
When to use: When you need to show strategic alignment. Good for planning meetings and executive communication.
OKR-Aligned Roadmap
Map roadmap items directly to Objectives and Key Results:
- Start with the team's OKRs for the period
- Under each Key Result, list the initiatives that will move that metric
- Include the expected impact of each initiative on the Key Result
- This creates clear accountability between what you build and what you measure
When to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear "why" tied to measurable outcomes.
Timeline / Gantt View
Calendar-based view with items on a timeline:
- Shows start dates, end dates, and durations
- Visualizes parallelism and sequencing
- Good for identifying resource conflicts
- Shows dependencies between items
When to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).
Prioritization Frameworks
RICE Score
Score each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) / Effort
- Reach: How many users/customers will this affect in a given time period? Use concrete numbers (e.g., "500 users per quarter").
- Impact: How much will this move the needle for each person reached? Score on a scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal.
- Confidence: How confident are we in the reach and impact estimates? 100% = high confidence (backed by data), 80% = medium (some evidence), 50% = low (gut feel).
- Effort: How many person-months of work? Include engineering, design, and any other functions.
When to use: When you need a quantitative, defensible prioritization. Good for comparing a large backlog of initiatives. Less good for strategic bets where impact is hard to estimate.
MoSCoW
Categorize items into Must have, Should have, Could have, Won't have:
- Must have: The roadmap is a failure without these. Non-negotiable commitments.
- Should have: Important and expected, but delivery is viable without them.
- Could have: Desirable but clearly lower priority. Include only if capacity allows.
- Won't have: Explicitly out of scope for this period. Important to list for clarity.
When to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.
ICE Score
Simpler than RICE. Score each item 1-10 on three dimensions:
- Impact: How much will this move the target metric?
- Confidence: How confident are we in the impact estimate?
- Ease: How easy is this to implement? (Inverse of effort — higher = easier)
ICE Score = Impact x Confidence x Ease
When to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.
Value vs Effort Matrix
Plot initiatives on a 2x2 matrix:
- High value, Low effort (Quick wins): Do these first.
- High value, High effort (Big bets): Plan these carefully. Worth the investment but need proper scoping.
- Low value, Low effort (Fill-ins): Do these when you have spare capacity.
- Low value, High effort (Money pits): Do not do these. Remove from the backlog.
When to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.
Dependency Mapping
Identifying Dependencies
Look for dependencies across these categories:
- Technical dependencies: Feature B requires infrastructure work from Feature A
- Team dependencies: Feature requires work from another team (design, platform, data)
- External dependencies: Waiting on a vendor, partner, or third-party integration
- Knowledge dependencies: Need research or investigation results before starting
- Sequential dependencies: Must ship Feature A before starting Feature B (shared code, user flow)
Managing Dependencies
- List all dependencies explicitly in the roadmap
- Assign an owner to each dependency (who is responsible for resolving it)
- Set a "need by" date: when does the depending item need this resolved
- Build buffer around dependencies — they are the highest-risk items on any roadmap
- Flag dependencies that cross team boundaries early — these require coordination
- Have a contingency plan: what do you do if the dependency slips?
Reducing Dependencies
- Can you build a simpler version that avoids the dependency?
- Can you parallelize by using an interface contract or mock?
- Can you sequence differently to move the dependency earlier?
- Can you absorb the work into your team to remove the cross-team coordination?
Capacity Planning
Estimating Capacity
- Start with the number of engineers and the time period
- Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO
- A common rule of thumb: engineers spend 60-70% of time on planned feature work
- Factor in team ramp time for new members
Allocating Capacity
A healthy allocation for most product teams:
- 70% planned features: Roadmap items that advance strategic goals
- 20% technical health: Tech debt, reliability, performance, developer experience
- 10% unplanned: Buffer for urgent issues, quick wins, and requests from other teams
Adjust ratios based on team context:
- New product: more feature work, less tech debt
- Mature product: more tech debt and reliability investment
- Post-incident: more reliability, less features
- Rapid growth: more scalability and performance
Capacity vs Ambition
- If roadmap commitments exceed capacity, something must give
- Do not solve capacity problems by pretending people can do more — solve by cutting scope
- When adding to the roadmap, always ask: "What comes off?"
- Better to commit to fewer things and deliver reliably than to overcommit and disappoint
Communicating Roadmap Changes
When the Roadmap Changes
Common triggers for roadmap changes:
- New strategic priority from leadership
- Customer feedback or research that changes priorities
- Technical discovery that changes estimates
- Dependency slip from another team
- Resource change (team grows or shrinks, key person leaves)
- Competitive move that requires response
How to Communicate Changes
- Acknowledge the change: Be direct about what is changing and why
- Explain the reason: What new information drove this decision?
- Show the tradeoff: What was deprioritized to make room? Or what is slipping?
- Show the new plan: Updated roadmap with the changes reflected
- Acknowledge impact: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.
Avoiding Roadmap Whiplash
- Do not change the roadmap for every piece of new information. Have a threshold for change.
- Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.
- Distinguish between "roadmap change" (strategic reprioritization) and "scope adjustment" (normal execution refinement).
- Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.
Output Format
Use a clear, scannable format. Tables work well for roadmap items. Use text status labels: Done, On Track, At Risk, Blocked, Not Started.
Tips
- A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.
- When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.
- Flag capacity issues early. If the roadmap has more work than the team can handle, say so.
- Dependencies are the biggest risk to roadmaps. Surface them explicitly.
- If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.
