product-roadmap
Turns product strategy into a themed Now/Next/Later roadmap with explicit trade-offs, confidence levels, and no committed dates beyond one quarter. Use when someone asks "build our product roadmap", "turn these priorities into a roadmap", "execs want committed ship dates for next year", or needs to communicate direction without over-promising. Do NOT use for company-wide annual operating plans - use annual-plan instead; for defining the goals a roadmap serves, use okr-builder; for scheduling work inside a sprint, use sprint-planning.
- License 许可
- MIT
- 最近更新
- 2026-10-14
- Stars
- ★ 25
- Forks
- 3
01 前言 Front Matter
- name
- product-roadmap
- metadata
- { "title": "Product Roadmap" }
- description
- Turns product strategy into a themed Now/Next/Later roadmap with explicit trade-offs, confidence levels, and no committed dates beyond one quarter. Use when someone asks "build our product roadmap", "turn these priorities into a roadmap", "execs want committed ship dates for next year", or needs to communicate direction without over-promising. Do NOT use for company-wide annual operating plans - use annual-plan instead; for defining the goals a roadmap serves, use okr-builder; for scheduling work inside a sprint, use sprint-planning.
03 SKILL.md 正文
Product Roadmap
A roadmap is a communication tool, not a promise to ship a feature list on fixed dates. The costly failure it prevents is double-sided: a Gantt chart of dated features sets the team up to publicly "miss the roadmap" within two months, while a roadmap with no trade-offs is a wishlist that aligns nobody. This skill builds one that aligns the organization around outcomes and survives contact with reality.
Operating procedure
Step 1: Gather inputs and anchor to strategy
Collect before building; where an input is missing, that is upstream work, not a blank to improvise:
- Vision - where the product is going in 1-3 years.
- Goals - the 2-4 outcomes for this period (growth, retention, expansion). More than 4 goals means no goals; send goal-setting itself to okr-builder.
- Target users and problems - who is served and what pain is being solved.
- The candidate list: everything currently being considered, with rough effort and any evidence of value.
Every roadmap item must trace back to a goal. An item that traces to no goal gets questioned, and either a goal is missing or the item is.
Step 2: Organize by themes, not features
Group work into themes - problem areas and outcomes, such as "Reduce onboarding friction", never "Build feature X". Themes survive when specific solutions change, communicate intent without over-promising implementation, and leave teams free to find the best solution inside the theme. If a theme name contains a solution noun (a screen, an integration, a widget), rewrite it as the problem it solves.
Step 3: Bucket into Now / Next / Later - and hold the date line
Use horizon buckets instead of dates:
- Now (this quarter): committed, scoped, in motion. This is the only bucket that may carry dates, and only within the quarter.
- Next (next quarter): high-confidence direction, not fully scoped. No dates.
- Later (beyond): directional bets that will change. No dates, ever.
The discipline: no committed dates beyond one quarter. Confidence decreases with distance, and precision implies a promise. When an exec asks for a date on a Later item, the correct answer is the horizon plus its confidence level - a date given under pressure today becomes a public miss next quarter, and each miss devalues every future roadmap. Label every item's confidence explicitly: High / Medium / Low. A useful sanity check: Now items should be High confidence, Next mostly Medium, Later mostly Low - a Later item marked High confidence usually means it belongs in Next.
Step 4: Make trade-offs visible
For each major theme, record:
- Why this, why now - the rationale tied to a goal.
- What we're NOT doing - the explicit trade-off. Saying no is the roadmap's real value; without a not-doing line, the roadmap is a wishlist.
- Key assumptions and risks - what new information would change the plan.
Step 5: Prioritize with a consistent framework
Score candidates with one framework - RICE (Reach, Impact, Confidence, Effort), value vs. effort, or weighted goal alignment - so prioritization is defensible rather than loudest-voice-wins. Re-score when new information arrives; a framework applied once and frozen is theater.
Step 6: Communicate and maintain
- Tailor the view: execs get themes and outcomes; engineering gets Now/Next detail.
- Revisit monthly. A roadmap is a living document, not a contract; a stale roadmap loses all credibility at once, not gradually.
- Pair with metrics: report progress against each theme's success measure, not feature ship counts.
Roadmap row template
Theme: [FILL: outcome-oriented name - a problem, not a feature]
Goal it serves: [FILL: strategic goal]
Horizon: Now | Next | Later
Confidence: High | Medium | Low
Why now: [FILL: rationale]
Not doing: [FILL: the explicit trade-off]
Success measure: [FILL: how we'll know it worked]
Worked contrast: one entry, bad and good
Bad:
Theme: Build Slack integration
Horizon: Q3, ships Sept 15
Why now: Sales asked for it
Why it fails: the theme is a solution, not a problem; it carries a committed date two quarters out; the rationale traces to a request, not a goal; there is no confidence, no trade-off, and no success measure. In two months this row is either a public miss or an anchor the team ships badly to honor.
Good:
Theme: Meet users inside their existing workflow
Goal it serves: Activation - lift week-1 active rate
Horizon: Next
Confidence: Medium
Why now: 40% of churned trials cite "another tool to check"; workflow embedding
is the highest-scored RICE candidate against the activation goal
Not doing: native mobile app this period - same goal, 3x the effort, lower reach
Success measure: week-1 active rate for integrated users vs. baseline
Why it works: problem-framed theme (Slack may still be the answer, but so might email or Teams), honest horizon with matching confidence, goal-traced rationale with evidence, a named sacrifice, and a measurable outcome.
Deliverable
Produce a complete roadmap: the strategy anchor (vision, 2-4 goals, target users/problems), themed entries in Now/Next/Later buckets each using the row template with confidence, not-doing, and success measure filled, the prioritization scores behind the ordering, and the two communication views (exec theme view, engineering Now/Next view) with a monthly revisit date set.
Do NOT
- Do not build a Gantt chart of features with fixed dates - it manufactures public misses and trains the org to distrust the roadmap.
- Do not commit dates beyond one quarter - precision at distance is a promise the data cannot back.
- Do not list solutions instead of problems - solution-named themes box the team into the first idea anyone had.
- Do not omit the "not doing" line - without visible trade-offs the roadmap is a wishlist and every stakeholder assumes their item is implied.
- Do not let prioritization be loudest-voice-wins - score with one framework and show the scores.
- Do not let it go stale - an unrevised roadmap is worse than none, because people plan against it.
Quality bar
- Every item traces to one of 2-4 named goals; untraceable items removed or a missing goal surfaced.
- Every theme is problem/outcome-framed - zero solution nouns in theme names.
- Dates appear only inside the current quarter; Next and Later carry horizons and confidence only.
- Confidence labels follow the gradient (Now high, Later low) or the mismatch is explained.
- Every theme has a not-doing trade-off and a success measure.
- A monthly review is scheduled and the framework scores are attached, not implied.
04 同仓库更多 Skills
有氧运动计划
zone-2-cardio-plan
当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练,或提高静息心率、最大摄氧量或耐力时,可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导,不构成医疗建议。请勿用于设计力量或举重训练计划(请使用力量训练计划)、高强度间歇训练 (HIIT) 或循环训练(请使用体能训练和 HIIT 计划),或灵活性/柔韧性训练(请使用灵活性训练计划)。
youtube-script-writer
Writes retention-engineered long-form YouTube scripts on a hook/body/payoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says "script my next video", "my retention graph dies at the start", "tighten this draft", or "outline a video on X". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.
win-back-campaign
Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says "our users went quiet", "design a win-back campaign", "how do I re-engage lapsed customers", "should we email people who haven't logged in for months", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.
wikipedia-style
Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks "write this like a Wikipedia article", "draft a Wikipedia page for this company or person", "make this neutral and encyclopedic", or "why does my article draft keep getting rejected". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.
whitepapers
Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.
white-space-analysis
Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks "where are the gaps in this market", "what's underserved here", "where should we play next", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.