Roadmap Prioritisation Frameworks That Actually Work
RICE, MoSCoW, and ICE are fine. Here's when they break — and what to use instead.
Every PM learns RICE in their first week on the job. Most use it wrong for the next decade. Prioritisation frameworks — RICE, MoSCoW, ICE, the Kano model — are genuinely useful. But there's a fundamental misunderstanding about what they're for, and it quietly ruins roadmaps everywhere.
Frameworks don't make decisions. They structure conversations.
When a PM fills in a RICE score, they're not calculating an objective truth. They're encoding a set of assumptions — about reach, impact, confidence, and effort — that can then be challenged, debated, and refined with engineering, design, and stakeholders. The framework's value is that it makes those assumptions explicit. The danger is when the framework's output is treated as the decision itself.
I've sat in planning sessions where someone said "RICE says 4.2, so we build it." That's a category error. RICE said 4.2 given your assumptions. Challenge the assumptions and you might get 1.8 — or 9.1. The number is a starting point for a conversation, not a conclusion.
When RICE breaks
When "Reach" is speculative. For new features with no historical data, reach estimates are essentially fiction. You're comparing made-up numbers with a veneer of precision. A simple 2x2 — impact vs. effort — with honest uncertainty is more useful.
When "Impact" conflates user value and business value. A feature might have high user impact but low revenue impact, or vice versa. RICE collapses these into one score and creates invisible distortions in your roadmap over time.
When stakeholders game the scores. Every experienced PM has seen this. Engineering inflates effort to protect scope. Sales inflates reach to get their features built. The framework then amplifies politics rather than reducing them.
What I use instead
For early-stage roadmaps, I prefer opportunity sizing with explicit assumptions: "We believe X users have Y problem. If we solve it, we expect Z behaviour change." Score confidence in each belief separately. Slower, but forces intellectual honesty.
For mature products with good instrumentation, I use retention impact modelling. Which features, if removed, would cause users to churn? Build those first. Which features, if added, would cause users to upgrade? Build those second.
For alignment across teams, I use the "what breaks if we don't build this" test. If the answer is "nothing, really" — deprioritise. If the answer is "our biggest customer churns" — that feature doesn't need a RICE score. It needs a delivery date.
The meta-lesson
Good prioritisation is less about which framework you use and more about how honestly you interrogate your assumptions. Pick any framework. Use it to start conversations, not end them. Update it when you learn something new. And always ask: what would have to be true for this to be wrong?