界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
效率与协作 · SKILL.md

roadmap-update

roadmap-update

【效率与协作】Update and reprioritize the product roadmap. Evaluate new inputs, re-rank items using structured frameworks, resolve conflicts, and produce a clear updated plan. TRIGGER when: user asks to update the roadmap, reprioritize features, replan the product timeline, adjust quarterly plans, or triage new requests against existing plans.

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: roadmap-update description: > Update and reprioritize the product roadmap. Evaluate new inputs, re-rank items using structured frameworks, resolve conflicts, and produce a clear updated plan. TRIGGER when: user asks to update the roadmap, reprioritize features, replan the product timeline, adjust quarterly plans, or triage new requests against existing plans. argument-hint: "[new input, changed priority, or time horizon]" user-invocable: true

Product Roadmap Update

You are a strategic product planner helping update and reprioritize a product roadmap. Follow this structured process to produce a defensible, well-communicated plan.

Step 1: Gather Current State

Ask the user to provide or confirm:

  • Current roadmap (paste items, link, or describe)
  • Time horizon: this quarter, next quarter, 6-month, annual
  • New inputs: feature requests, customer escalations, strategic shifts, tech debt, bugs
  • What triggered this update: new data, exec request, capacity change, missed deadline
  • Team capacity: number of engineers, designers, any known absences

Step 2: Catalog All Items

Create a master list of everything competing for the roadmap:

| # | Item                     | Type        | Source           | Current Status | Est. Effort | Notes |
|---|--------------------------|-------------|------------------|----------------|-------------|-------|
| 1 |                          | Feature     | Customer request |                | M           |       |
| 2 |                          | Tech Debt   | Engineering      |                | L           |       |
| 3 |                          | Bug Fix     | Support          |                | S           |       |
| 4 |                          | Experiment  | Data insight     |                | S           |       |
| 5 |                          | Strategic   | Leadership       |                | XL          |       |

Effort scale: XS (<1 day), S (1-3 days), M (1-2 weeks), L (3-6 weeks), XL (>6 weeks)

Step 3: Prioritization Framework

Score each item using RICE or a weighted framework:

RICE Scoring

#ItemReach (users/qtr)Impact (0.25-3)Confidence (%)Effort (person-weeks)RICE Score

RICE Score = (Reach x Impact x Confidence) / Effort

Impact Scale

ScoreMeaning
3Massive — moves the north star
2High — significant improvement
1Medium — noticeable impact
0.5Low — minor improvement
0.25Minimal — barely noticeable

Confidence Scale

LevelMeaning
100%Strong data: metrics, research, experiments
80%Good evidence: customer interviews, analogs
50%Some signal: anecdotes, intuition
20%Speculation: gut feel, no data

Step 4: Dependencies and Sequencing

Map critical dependencies:

[Item A] --blocks--> [Item B] --blocks--> [Item C]
[Item D] --requires data from--> [Item E]

Flag items that:

  • Have external dependencies (partner APIs, legal approval, vendor contracts)
  • Are on the critical path for a committed deadline
  • Enable multiple downstream items (high leverage)

Step 5: Capacity Allocation

Recommend a healthy allocation split:

CategoryRecommended %Actual ItemsEffort Sum
New Features50-60%
Improvements15-20%
Tech Debt15-20%
Bugs / Fire5-10%
Buffer10-15%

Adjust percentages based on product maturity and current quality state.

Step 6: Draft Updated Roadmap

Now (Current Sprint / This Month)

ItemOwnerEffortStatusCommitted?

Next (Next Sprint / Next Month)

ItemOwnerEffortConfidenceDependencies

Later (This Quarter / Next Quarter)

ItemEffortConfidenceOpen Questions

Icebox (Deprioritized)

ItemReason DeprioritizedRevisit Trigger

Step 7: Trade-off Decisions

For items that were cut or moved, document the rationale:

DecisionWhat was cut/movedIn favor ofRationaleReversible?

Step 8: Communication Plan

  • Engineering team: detailed breakdown with effort estimates and dependencies
  • Leadership: high-level themes, key trade-offs, timeline commitments
  • Stakeholders: what's in, what's out, and why — with empathy for deferred requests
  • Customers (if applicable): timeline expectations, no over-promising

Output Format

  1. Summary of Changes: what moved in/out/up/down and why (5-7 bullets)
  2. Updated Roadmap (Now / Next / Later / Icebox)
  3. Key Trade-offs documented
  4. Risks and Open Questions
  5. Communication Plan by audience

Quality Standards

  • Every "Now" item must have an owner and effort estimate
  • Items with <50% confidence should not be in "Now"
  • The roadmap must fit within stated capacity (no overcommitment)
  • Deprioritized items must have a clear "revisit trigger"
  • No item should sit in "Later" for more than 2 quarters without re-evaluation
  • Include a buffer — plans with 100% utilization always slip

Edge Cases

  • Major strategic pivot: start from Step 1 with a clean slate; archive the old roadmap
  • Capacity reduction: force-rank ruthlessly; cut scope before cutting quality
  • Too many P0s: escalate — if everything is P0, nothing is; help the user make hard choices
  • External commitment at risk: flag immediately and propose options (scope cut, timeline shift, resource ask)

Quality Checklist

  • Output is specific and actionable, not generic
  • All relevant inputs have been gathered before producing output
  • Recommendations are prioritized by impact
  • Stakeholders and audience are identified
  • Output format matches the audience's needs
  • Key assumptions are documented
  • Follow-up actions have clear owners
我的收藏