product-roadmap-prioritizer

name

product-roadmap-prioritizer

description

Runs candidate features through Reach-Impact-Confidence-Effort (RICE), Kano, Must-Should-Could-Won't (MoSCoW), and Cost-of-Delay scoring, surfaces convergence and divergence across frameworks, and produces a defensible quarterly priority list with explicit trade-offs. Use when building a quarterly or annual roadmap, resolving conflicting stakeholder input, justifying a deprioritization to a stakeholder, or normalizing requests from multiple sources (sales, customer success, leadership) into one queue.

Product Roadmap Prioritizer

Multi-framework feature ranking that withstands stakeholder pushback.

What this skill is

A workflow that scores candidate features across four complementary prioritization frameworks - Reach-Impact-Confidence-Effort (RICE), Kano, Must-Should-Could-Won't (MoSCoW), and Cost of Delay - surfaces where they agree and disagree, and turns that into a ranked quarterly roadmap with explicit reasoning. Designed so that every "no" can be defended with the same rigor as every "yes."

What it solves

• Highest-Paid-Person's-Opinion (HiPPO) driven prioritization
• Feature ranking that ignores effort or confidence
• Single-framework analysis that misses the trade-off (RICE without Kano misses delighters; Kano without RICE misses scale)
• Sales, customer success, and executive requests that bypass any structured queue
• Inability to explain to a stakeholder why their request didn't make the cut

When to invoke

• Quarterly or annual roadmap planning
• Resolving conflicting input from sales, customer success, and leadership
• Justifying a deprioritization in writing
• Normalizing a backlog of 50+ requests into a ranked queue
• Pre-Objectives and Key Results (pre-OKR) planning to align roadmap with stated objectives

Phase 1: Inventory candidates

Collect every candidate from every source:

• Sales requests (deal-driven asks)
• Customer success and support themes (volume, severity)
• Leadership, board, or strategy directives
• Customer interview opportunity tree
• Technical debt and platform investments
• Engineering quality and reliability work

For each, capture: title, sponsor, source link, hypothesized outcome, hypothesized customer.

Reject anything missing sponsor or outcome.

Phase 2: Score with RICE

For each candidate:

Reach-Impact-Confidence-Effort (RICE) = (Reach × Impact × Confidence) / Effort

• Reach - number of users affected per time period
• Impact - 0.25 (minimal) / 0.5 / 1 (medium) / 2 / 3 (massive)
• Confidence - 50% / 80% / 100% - based on quality of evidence
• Effort - person-months

Document the data source behind each number. A RICE score with no evidence is a feeling.

Phase 3: Classify with Kano

For each candidate, classify the customer perception:

Kano category	Definition	Investment posture
Must-have	Expected baseline; absence → dissatisfaction	Reach parity, then stop
Performance	More is better; linear satisfaction	Invest while Return on Investment (ROI) holds
Delighter	Unexpected; non-linear satisfaction	Invest selectively for differentiation
Indifferent	No effect on satisfaction	Defer or kill
Reverse	More → less satisfaction	Avoid

Classification source: survey, interview, behavioral data, or analyst hypothesis (flag the confidence).

A roadmap of all must-haves is a defensive crouch. A roadmap of all delighters is fragile. Balance.

Phase 4: Categorize with MoSCoW (per release)

For each candidate within a release window, apply the Must-Should-Could-Won't (MoSCoW) categorization:

• Must - non-negotiable; release fails without it
• Should - important; release weaker without it
• Could - nice to have; first to cut
• Won't (this time) - explicitly out of scope

Rule of thumb: Must ≤ 60% of release capacity. Anything higher means everything is "must," which means nothing is.

Phase 5: Weight with Cost of Delay

For time-sensitive items, compute Cost of Delay Divided by Duration (CD3):

CD3 = Cost of Delay / Duration

Cost of delay components:

• Revenue at risk (deal blockers, churn risk)
• Competitive timing (feature parity windows)
• Compliance or regulatory deadlines
• Dependency unblocking (other teams gated)
• Brand or public-relations opportunity

CD3 sorts the queue for sequencing within a release.

Phase 6: Convergence analysis

Build the convergence table:

Candidate	RICE rank	Kano	MoSCoW	CD3 rank	Convergence
A	1	Performance	Must	1	Strong yes
B	5	Delighter	Should	3	Mixed - investigate
C	12	Must-have	Must	8	Table stakes - do
D	2	Indifferent	Could	15	RICE alone is misleading

Where frameworks agree → high confidence to commit. Where they disagree → the disagreement IS the strategy conversation. Don't average; investigate.

Phase 7: Quarterly roadmap

For the chosen quarter:

• 60% capacity → must-haves and high-converging items
• 25% capacity → performance and delighter bets
• 10% capacity → technical debt and platform investment
• 5% capacity → discovery experiments (no committed output)

Stakeholder reply template for declined requests:

Thanks for the request. We scored [X] using RICE / Kano / MoSCoW. It scored [Y], which puts it behind [Z]. We'd reconsider if [explicit trigger]. Here's what we're doing instead: [items A, B, C] and the outcome we expect.

Output

• Scored candidate table across all four frameworks
• Convergence and divergence analysis with reasoning
• Ranked quarterly roadmap with capacity allocation
• Explicit "won't do this quarter" list with reasoning
• Stakeholder decline templates per declined request
• Re-evaluation triggers for next quarter

Operating rules

Always

• Source every RICE input from evidence
• Apply at least two frameworks before committing
• Investigate divergence - don't average it away
• Cap "Must" at 60% of release capacity
• Document why each declined item was declined

Never

• Score with confidence above what the evidence supports
• Use one framework alone
• Promote a request because the sponsor is senior
• Treat technical debt as automatically deferrable
• Confuse a feature with an outcome