A roadmap with 50 priorities has zero priorities.
1RICE: The ROI Calculator
Use RICE when you need to defend your roadmap to stakeholders with data. It forces you to estimate 'Reach' (how many people) and 'Effort' (how many weeks), making the trade-offs explicit.
2MoSCoW: The Release Guard
MoSCoW is perfect for fixed-deadline projects. Identify the 'Must Haves' (the Minimum Viable Product). If you run out of time, you cut the 'Could Haves' first.
3The Bias Trap
Beware of 'HIPPO' (Highest Paid Person's Opinion). Prioritization frameworks are the PM's shield against arbitrary feature requests from powerful stakeholders.
4Step-by-Step Breakdown
Prioritization is the most visible skill of a PM. You have infinite ideas but finite time. Frameworks help remove emotion and bias from the decision.
RICE Score: (Reach x Impact x Confidence) / Effort. It's a quantitative way to rank features based on their potential return on investment.
MoSCoW helps with release planning (Must have vs. Could have). The Kano Model helps distinguish between 'Basic' features and 'Delighters'.
In the RICE framework, what does 'Confidence' represent?
- →How much the CEO likes the idea
- →A percentage (0-100%) reflecting how much data you have to support your Reach and Impact estimates
- →How quickly the engineering team can build it
- →The number of users who will see the feature
According to the Kano Model, what happens to a 'Delighter' feature over time?
- →It stays a delighter forever
- →It eventually becomes a 'Basic' expectation as competitors copy it (e.g., WiFi in hotels)
- →It becomes a 'Performance' feature
- →It is removed from the product
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Weight Accessibility Fixes Fairly in RICE Scoring
Accessibility improvements often score low on a naive RICE calculation because 'Reach' looks small (only users with disabilities) even though the legal, ethical, and brand impact is large. Adjust your Impact score to account for risk and inclusion, not just raw usage numbers, so accessibility work doesn't permanently lose to flashier features.
// Naive: reach=500, impact=1, confidence=0.8, effort=3 -> low score
// Adjusted: impact weighted for legal/brand risk, not just raw usage countSEO Implications
- 1
Deprioritized Technical SEO Debt Compounds
Technical SEO fixes (broken canonical tags, slow Core Web Vitals) often lose RICE scoring battles against visible features because their 'Reach' is hard to quantify. Left deprioritized for multiple cycles, this debt can quietly erode organic traffic, which is much more expensive to win back than to prevent.
Best Practices
Score as a Group, Not Solo
RICE and Kano scores are estimates, and a single PM's estimates carry personal bias. Score major roadmap items with input from design, engineering, and data so the numbers reflect more than one person's gut feeling.
Revisit Scores When New Data Arrives
A feature's Confidence score should go up once you've run an experiment or gathered user research. Don't let prioritization scores sit stale for a whole quarter — refresh them as evidence changes.
Frequent Bugs
Using RICE scores as if they were exact math down to the decimal, when the underlying Reach and Impact inputs were rough guesses.
Treat RICE output as a ranking signal for discussion, not a precise formula — round scores into tiers (high/medium/low) rather than debating whether 8.4 beats 8.1.
Real-World Examples
Prioritizing a Backlog With RICE
A product team has 12 candidate features for the next quarter and needs a defensible way to rank them for a stakeholder review.
const features = [
{ name: 'Bulk export', reach: 2000, impact: 2, confidence: 0.8, effort: 3 },
{ name: 'Dark mode', reach: 8000, impact: 1, confidence: 0.9, effort: 2 },
];
const score = f => (f.reach * f.impact * f.confidence) / f.effort;
features.sort((a, b) => score(b) - score(a));