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