product-roadmapping v1.0.0

name: product-roadmapping description: "Build strategic product roadmaps: theme-based and outcome-based planning, disciplined prioritization (RICE, MoSCoW, Kano, WSJF, weighted scoring), honest revision patterns, and stakeholder communication tuned to each audience. Use when planning product direction, ranking initiatives, running quarterly planning, or communicating a roadmap to execs, engineering, sales, or customers."

Product Roadmapping

Purpose

Turn a pile of feature requests into a defensible product roadmap: pick the right format, rank initiatives with an honest prioritization method, allocate portfolio balance, and communicate the plan so stakeholders trust it. The roadmap is a communication tool, not a commitment. Say that out loud whenever you present one.

Workflow

1. Anchor on outcomes, not features. Before any ranking, restate each initiative as the outcome it drives ("reduce signup drop-off") rather than the output it ships ("add tooltips"). If an initiative cannot be restated as an outcome, it is a guess. Mark it as one or cut it.

1. Choose the roadmap format for the audience and context.

• Now/Next/Later — default for most teams. No dates; columns are commitment levels: Now (0-3 mo, committed, sized, owned), Next (3-6 mo, directional, unsized), Later (6+ mo, options only). Best when certainty would be dishonest.
• Theme-based — organize 3-5 strategic themes, initiatives hang under them. Best for product-led teams and customer-facing communication.
• Outcome-based — Outcome -> Hypothesis -> Bets -> Backlog. The roadmap lives at the theme level; the backlog lives at the bet level and below.
• Timeline/Gantt — dates and quarters. Only for committed deliveries, hardware, or hard dependencies. Never use it to imply certainty you do not have.
• Portfolio — multiple roadmaps across teams/segments. Only for large orgs. Detail, pros/cons, and best-for per format: references/roadmap-formats.md.

1. Rank with one method, cross-check with a second. See references/prioritization-frameworks.md for formulas and worked examples.

• Need speed? ICE (Impact, Confidence, Ease; score = average of the three).
• Have usage data and want to penalize unevidenced ideas? RICE (Reach x Impact x Confidence / Effort).
• Time has a measurable cost? WSJF (Cost of Delay / Job Size, SAFe method).
• MVP scoping or everything sounds urgent? MoSCoW (Must / Should / Could / Won't). Keep Must-have at or below ~60% of capacity, one practitioner recommendation for keeping delivery feasible.
• Splitting must-haves from delighters? Kano (Basic, Performance, Delighter).
• Complex trade-offs with custom criteria? Weighted scoring (score each criterion, multiply by agreed weights).
• Outcome-focused innovation? Opportunity scoring (Jobs-to-be-Done: Importance + max(Importance - Satisfaction, 0), prioritize above ~7.0).
• Cross-check the ranking with Value vs Effort to catch quick wins and time sinks the formula hid.

1. Balance the portfolio. A healthy quarter mixes new features, improvements, technical work, and experiments. A typical starting allocation is New Features 40-50%, Improvements 20-30%, Technical 15-25%, Innovation 5-15% (calibrate to maturity stage, debt pressure, and competition). Roadmaps that are 100% feature bets accumulate debt until the debt schedules the roadmap for you.

1. Write the one-pager. Use assets/roadmap-template.md: strategic goal, themes with success metrics, Now/Next/Later columns, a Decisions & Trade-offs log, and a "What We're NOT Doing (and Why)" section. The NOT list matters as much as the roadmap. Document every rejected item's rationale somewhere the team can find it.

1. Communicate per audience.

• Execs: themes, outcomes, key bets, risks, resource implications. No feature lists.
• Engineering: initiative plans, dependencies, sequencing, success metrics, and where the flex points are.
• Sales / CS: customer-facing value, timing kept appropriately vague, and explicitly what NOT to promise.
• Customers: directional themes only. No dates unless committed. Focus on problems being solved and gather feedback.
• Keep an internal (granular) roadmap separate from the external (themes only) one.

1. Revise honestly. Update at least monthly, weekly for Now/Next/Later. Move items between columns as reality changes. Communicate changes proactively; surprises erode trust faster than bad news. Track estimated vs actual impact on shipped initiatives and feed it back into scoring calibration.

Output Contract

When asked to produce a roadmap, return:

• One-page roadmap per assets/roadmap-template.md (goal, themes, Now/Next/Later, owners where committed).
• The prioritization scoring table used, with scores shown and assumptions documented.
• Decisions & Trade-offs log and the NOT Doing list with reasons.
• Per-audience summary: one version each for execs, engineering, and sales/CS (or whichever the requester names).
• A revision cadence: how often this roadmap gets re-examined and who owns that.

Operating Rules

• Outcomes outrank outputs. If an initiative is only an output, say so.
• Never present a formula's score as truth. Scores are conversation starters; document assumptions alongside them and re-score as you learn.
• No HiPPO prioritization (highest paid person's opinion). If the ranking surprises the loudest voice in the room, show the work, do not override it.
• Do not set-and-forget. A roadmap that never changes is a roadmap nobody uses.
• Do not commit dates in Now/Next/Later. Dates go only in timeline roadmaps with explicit commitment language.
• Combine methods rather than worshipping one: MoSCoW for release filtering, RICE for roadmap ranking, Kano for strategic balance, Value vs Effort as the sanity check.