Embed badge
Show
Style
[](https://versuz.dev/skills/evolution-foundation-evo-nexus-claude-skills-pm-roadmap-update)Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install evolution-foundation-evo-nexus-claude-skills-pm-roadmap-updategit clone https://github.com/evolution-foundation/evo-nexus.gitcp evo-nexus/SKILL.MD ~/.claude/skills/evolution-foundation-evo-nexus-claude-skills-pm-roadmap-update/SKILL.md--- name: pm-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 Update, create, or reprioritize a product roadmap. ## Usage ``` /pm-roadmap-update $ARGUMENTS ``` ## Workflow ### 1. Understand Current State If **Linear MCP** (`int-linear-review`) is available: - 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 Linear is not 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 Linear MCP is connected, offer to update ticket statuses directly ## 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 1. **Acknowledge the change**: Be direct about what is changing and why 2. **Explain the reason**: What new information drove this decision? 3. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping? 4. **Show the new plan**: Updated roadmap with the changes reflected 5. **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.