Roadmap Update

1---2name: roadmap-update3description: 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.4argument-hint: "<update description>"5---6 7# Roadmap Update8 9> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).10 11Update, create, or reprioritize a product roadmap.12 13## Usage14 15```16/roadmap-update $ARGUMENTS17```18 19## Workflow20 21### 1. Understand Current State22 23If **~~project tracker** is connected:24- Pull current roadmap items with their statuses, assignees, and dates25- Identify items that are overdue, at risk, or recently completed26- Surface any items without clear owners or dates27 28If no project management tool is connected:29- Ask the user to describe their current roadmap or paste/upload it30- Accept any format: list, table, spreadsheet, screenshot, or prose description31 32### 2. Determine the Operation33 34Ask what the user wants to do:35 36**Add item**: New feature, initiative, or work item to the roadmap37- Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies38- Suggest where it fits based on current priorities and capacity39 40**Update status**: Change status of existing items41- Options: not started, in progress, at risk, blocked, completed, cut42- For "at risk" or "blocked": ask for the blocker and mitigation plan43 44**Reprioritize**: Change the order or priority of items45- Ask what changed (new information, strategy shift, resource change, customer feedback)46- Apply a prioritization framework if helpful — see **Prioritization Frameworks** below for RICE, MoSCoW, ICE, and value-vs-effort47- Show before/after comparison48 49**Move timeline**: Shift dates for items50- Ask why (scope change, dependency slip, resource constraint)51- Identify downstream impacts on dependent items52- Flag items that move past hard deadlines53 54**Create new roadmap**: Build a roadmap from scratch55- Ask about timeframe (quarter, half, year)56- Ask about format preference (Now/Next/Later, quarterly columns, OKR-aligned) — see **Roadmap Frameworks** below57- Gather the list of initiatives to include58 59### 3. Generate Roadmap Summary60 61Produce a roadmap view with:62 63#### Status Overview64Quick summary: X items in progress, Y completed this period, Z at risk.65 66#### Roadmap Items67For each item, show:68- Name and one-line description69- Status indicator (on track / at risk / blocked / completed / not started)70- Target timeframe or date71- Owner72- Key dependencies73 74Group items by:75- Timeframe (Now / Next / Later) or quarter, depending on format76- Or by theme/goal if the user prefers77 78#### Risks and Dependencies79- Items that are blocked or at risk, with details80- Cross-team dependencies and their status81- Items approaching hard deadlines82 83#### Changes This Update84If this is an update to an existing roadmap, summarize what changed:85- Items added, removed, or reprioritized86- Timeline shifts87- Status changes88 89### 4. Follow Up90 91After generating the roadmap:92- Offer to format for a specific audience (executive summary, engineering detail, customer-facing)93- Offer to draft communication about roadmap changes94- If project management tool is connected, offer to update ticket statuses95 96## Roadmap Frameworks97 98### Now / Next / Later99The simplest and often most effective roadmap format:100 101- **Now** (current sprint/month): Committed work. High confidence in scope and timeline. These are the things the team is actively building.102- **Next** (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.103- **Later** (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.104 105When to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.106 107### Quarterly Themes108Organize the roadmap around 2-3 themes per quarter:109 110- Each theme represents a strategic area of investment (e.g., "Enterprise readiness", "Activation improvements", "Platform extensibility")111- Under each theme, list the specific initiatives planned112- Themes should map to company or team OKRs113- This format makes it easy to explain WHY you are building what you are building114 115When to use: When you need to show strategic alignment. Good for planning meetings and executive communication.116 117### OKR-Aligned Roadmap118Map roadmap items directly to Objectives and Key Results:119 120- Start with the team's OKRs for the period121- Under each Key Result, list the initiatives that will move that metric122- Include the expected impact of each initiative on the Key Result123- This creates clear accountability between what you build and what you measure124 125When to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear "why" tied to measurable outcomes.126 127### Timeline / Gantt View128Calendar-based view with items on a timeline:129 130- Shows start dates, end dates, and durations131- Visualizes parallelism and sequencing132- Good for identifying resource conflicts133- Shows dependencies between items134 135When to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).136 137## Prioritization Frameworks138 139### RICE Score140Score each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) / Effort141 142- **Reach**: How many users/customers will this affect in a given time period? Use concrete numbers (e.g., "500 users per quarter").143- **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.144- **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).145- **Effort**: How many person-months of work? Include engineering, design, and any other functions.146 147When 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.148 149### MoSCoW150Categorize items into Must have, Should have, Could have, Won't have:151 152- **Must have**: The roadmap is a failure without these. Non-negotiable commitments.153- **Should have**: Important and expected, but delivery is viable without them.154- **Could have**: Desirable but clearly lower priority. Include only if capacity allows.155- **Won't have**: Explicitly out of scope for this period. Important to list for clarity.156 157When to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.158 159### ICE Score160Simpler than RICE. Score each item 1-10 on three dimensions:161 162- **Impact**: How much will this move the target metric?163- **Confidence**: How confident are we in the impact estimate?164- **Ease**: How easy is this to implement? (Inverse of effort — higher = easier)165 166ICE Score = Impact x Confidence x Ease167 168When to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.169 170### Value vs Effort Matrix171Plot initiatives on a 2x2 matrix:172 173- **High value, Low effort** (Quick wins): Do these first.174- **High value, High effort** (Big bets): Plan these carefully. Worth the investment but need proper scoping.175- **Low value, Low effort** (Fill-ins): Do these when you have spare capacity.176- **Low value, High effort** (Money pits): Do not do these. Remove from the backlog.177 178When to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.179 180## Dependency Mapping181 182### Identifying Dependencies183Look for dependencies across these categories:184 185- **Technical dependencies**: Feature B requires infrastructure work from Feature A186- **Team dependencies**: Feature requires work from another team (design, platform, data)187- **External dependencies**: Waiting on a vendor, partner, or third-party integration188- **Knowledge dependencies**: Need research or investigation results before starting189- **Sequential dependencies**: Must ship Feature A before starting Feature B (shared code, user flow)190 191### Managing Dependencies192- List all dependencies explicitly in the roadmap193- Assign an owner to each dependency (who is responsible for resolving it)194- Set a "need by" date: when does the depending item need this resolved195- Build buffer around dependencies — they are the highest-risk items on any roadmap196- Flag dependencies that cross team boundaries early — these require coordination197- Have a contingency plan: what do you do if the dependency slips?198 199### Reducing Dependencies200- Can you build a simpler version that avoids the dependency?201- Can you parallelize by using an interface contract or mock?202- Can you sequence differently to move the dependency earlier?203- Can you absorb the work into your team to remove the cross-team coordination?204 205## Capacity Planning206 207### Estimating Capacity208- Start with the number of engineers and the time period209- Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO210- A common rule of thumb: engineers spend 60-70% of time on planned feature work211- Factor in team ramp time for new members212 213### Allocating Capacity214A healthy allocation for most product teams:215 216- **70% planned features**: Roadmap items that advance strategic goals217- **20% technical health**: Tech debt, reliability, performance, developer experience218- **10% unplanned**: Buffer for urgent issues, quick wins, and requests from other teams219 220Adjust ratios based on team context:221- New product: more feature work, less tech debt222- Mature product: more tech debt and reliability investment223- Post-incident: more reliability, less features224- Rapid growth: more scalability and performance225 226### Capacity vs Ambition227- If roadmap commitments exceed capacity, something must give228- Do not solve capacity problems by pretending people can do more — solve by cutting scope229- When adding to the roadmap, always ask: "What comes off?"230- Better to commit to fewer things and deliver reliably than to overcommit and disappoint231 232## Communicating Roadmap Changes233 234### When the Roadmap Changes235Common triggers for roadmap changes:236- New strategic priority from leadership237- Customer feedback or research that changes priorities238- Technical discovery that changes estimates239- Dependency slip from another team240- Resource change (team grows or shrinks, key person leaves)241- Competitive move that requires response242 243### How to Communicate Changes2441. **Acknowledge the change**: Be direct about what is changing and why2452. **Explain the reason**: What new information drove this decision?2463. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping?2474. **Show the new plan**: Updated roadmap with the changes reflected2485. **Acknowledge impact**: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.249 250### Avoiding Roadmap Whiplash251- Do not change the roadmap for every piece of new information. Have a threshold for change.252- Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.253- Distinguish between "roadmap change" (strategic reprioritization) and "scope adjustment" (normal execution refinement).254- Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.255 256## Output Format257 258Use a clear, scannable format. Tables work well for roadmap items. Use text status labels: **Done**, **On Track**, **At Risk**, **Blocked**, **Not Started**.259 260## Tips261 262- A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.263- When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.264- Flag capacity issues early. If the roadmap has more work than the team can handle, say so.265- Dependencies are the biggest risk to roadmaps. Surface them explicitly.266- If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.