The Decision Made Most Often and Worst
Every week, every PM makes prioritisation decisions. What should we build next? What gets cut? What stays in scope? What gets pushed to next quarter? These decisions accumulate into the actual shape of your product, and yet most teams make them with very little discipline.
Frameworks like RICE, MoSCoW, and Kano are supposed to help. Done well, they impose structure on what would otherwise be instinct or politics. Done badly, they replace one form of guesswork with another, dressed up in numbers that look rigorous but aren't. The framework can become a way to appear analytical while still making decisions for the wrong reasons.
This article is about the major frameworks, when each is useful, the traps to avoid, and how to use them as tools for thinking rather than as substitutes for it. We will cover RICE, MoSCoW, Kano, the simple value-effort matrix, and a few less famous techniques worth knowing.
The RICE Framework
RICE was developed at Intercom to help compare different kinds of work. It stands for Reach, Impact, Confidence, and Effort. You score each item on those four dimensions and combine them into a single number that lets you rank items. The formula is:
Reach
How many people will this affect in a given time period? Usually measured in users per quarter or per month. A feature that affects ten thousand users per month has a higher reach than one that affects a hundred. The number should come from data where possible: page view counts, segment sizes, usage patterns.
Impact
How much will this affect each user? Intercom uses a scale from massive (3) through high (2), medium (1), low (0.5), to minimal (0.25). Impact is hard to measure objectively, so it ends up being a judgment call. The discipline is to be consistent in how you score impact across items, so the comparisons are fair even if the absolute numbers are rough.
Confidence
How sure are you about the reach and impact numbers? Expressed as a percentage. One hundred percent means you have solid data. Eighty percent is reasonable confidence. Fifty percent is a guess. The confidence multiplier penalises items where you are speculating, which forces honesty about how much you actually know.
Effort
How many person-months of team time will this take? Estimated by engineering, design, and PM together. Effort is the denominator: more effort makes the score lower, all else equal. This biases toward smaller items, which is usually right (smaller bets carry less risk and let you learn faster).
Where RICE Excels
RICE is best when comparing items that are roughly comparable: feature requests, small initiatives, improvements to existing products. The framework forces you to think explicitly about reach (which most teams underestimate) and confidence (which most teams ignore). It produces a ranked list that gives you a starting point for discussion.
Where RICE Falls Short
RICE struggles with strategic bets. A foundational platform investment may have low immediate reach and high effort, scoring poorly on RICE, but be the right thing to do for the next five years. RICE also gives a false sense of precision: the numbers feel rigorous, but most of them are estimates with wide error bars. Treat the rankings as rough; treat the close scores as ties.
The MoSCoW Method
MoSCoW is older and simpler than RICE. It comes from agile and project management practice. Items are sorted into four buckets:
- 1. Must have: The release will fail without these. Non-negotiable for the current scope.
- 2. Should have: Important but not critical. The release works without them, though imperfectly.
- 3. Could have: Nice to have. Will be included if there is time and capacity.
- 4. Won't have (this time): Explicitly out of scope for this release. May be revisited later.
Where MoSCoW Excels
MoSCoW is best for scoping a single release or project. It forces a hard decision about what is essential, which is the decision most teams avoid. The Won't-Have category is particularly powerful: it makes scope cuts visible and explicit, rather than letting items quietly slip.
Where MoSCoW Falls Short
MoSCoW doesn't help compare initiatives across releases or make trade-offs at the strategy level. It also tends to suffer from category inflation: everyone wants their item to be a Must, and over time the Must list grows until it loses meaning. Discipline is required to keep the categories honest. A common rule is that Musts should not exceed sixty percent of effort, with the rest split among Should and Could, ensuring the team has buffer for changes during the work.
The Kano Model
The Kano Model, developed by Noriaki Kano in the 1980s, categorises features by how customers react to them. Unlike RICE and MoSCoW, Kano is about feature type, not item ranking. It suggests three main categories of features:
Basic Expectations (Must-Be Features)
Features customers expect to be present. They take them for granted when present and are angry when absent. Examples: a calendar app must let you add events. A password reset flow must let you reset your password. Customers don't thank you for these; they punish you for missing them.
Performance Features
Features whose value scales with how well they work. Faster is better than slower. More features are better than fewer. More accurate is better than less. Customers consciously evaluate these and reward improvements proportionally. Most competitive features fall in this category.
Delighters (Excitement Features)
Features customers don't expect, that produce surprise and delight when discovered. The user wasn't looking for them, but having found them, becomes a fan. The first time a user sees an unexpected useful feature can produce disproportionate loyalty.
How Kano Helps
Kano is most useful when planning a balanced feature mix. Pure investment in basic features is necessary but never produces advocacy. Pure investment in delighters is fun but skips the groundwork. A healthy roadmap usually has all three, with the balance shifting based on the product's maturity. Early-stage products focus heavily on basics. Mid-stage products invest heavily in performance features. Mature products start adding delighters to differentiate.
The Hidden Insight
Kano also points out something important: delighters become performance features, and performance features become basics, as customer expectations rise. The unexpected feature you shipped two years ago is now table stakes. Competitors have matched it. Customers expect it. Maintaining a product means constantly creating new delighters, because the old ones get absorbed into the baseline.
The Simple Value-Effort Matrix
Sometimes the simplest framework is best. A two-by-two matrix with effort on one axis and value on the other. Items go into one of four quadrants:
Low Effort High Effort
High Value Quick wins. Do these first. Big bets. Do these next, with planning.
Low Value Fill-ins. Do if there's capacity. Time sinks. Don't do.
The matrix is rough but powerful. Quick wins (high value, low effort) should be the first thing the team works on; they are the cheapest way to deliver impact. Big bets are the major strategic work and should be carefully planned. Fill-ins can be done when there is capacity but should not displace the more important categories. Time sinks should be killed; they consume effort without proportionate return.
The matrix is sometimes criticised as too simple. It is. But for many teams, even the basic discipline of asking is this high or low value, and high or low effort is a meaningful improvement over no framework at all. Use it for fast triage; use richer frameworks when the decisions deserve more rigorous treatment.
Other Methods Worth Knowing
Weighted Scoring
Pick the criteria that matter to your decision (strategic fit, user value, business value, effort, risk), assign weights to each, score each item on each criterion, and sum the weighted scores. More flexible than RICE because you choose your own criteria. Useful when the standard frameworks don't fit your situation.
Cost of Delay
From the Lean and Agile community. For each item, estimate what it would cost the business if you delayed it by a quarter. Items with high cost of delay should be prioritised. Particularly useful when timing matters: market windows, regulatory deadlines, competitor moves.
Buy-a-Feature
Each stakeholder gets a fixed budget of "dollars" they can allocate among proposed features. Reveals what people would pay for if they had to choose. Useful in workshops to make implicit priorities explicit. Less useful for ongoing prioritisation.
Opportunity Scoring
Rate each opportunity on importance (how much customers care) and satisfaction (how well current solutions serve them). Items with high importance and low satisfaction are the best opportunities. Useful for understanding the gap between what customers care about and what current products deliver.
Common Mistakes
Mistake One: False Precision
RICE produces specific numbers like 47.2 and 31.8. The precision is fake. Most of the inputs were estimates with wide error bars. Treating the difference between 47 and 32 as meaningful is a mistake. Items with similar scores should be treated as a tie and decided by other factors (strategic fit, team interest, dependencies). Only large gaps in score should drive prioritisation.
Mistake Two: Optimising for the Framework
Some teams start writing tickets to "score well" on RICE: small efforts, broad reach, high confidence. The result is a backlog optimised for the framework, not for the strategy. Frameworks should serve strategy. When they start shaping it, something has gone wrong.
Mistake Three: Ignoring Strategic Items
Most frameworks struggle with strategic bets: large, uncertain, long-term work that may not pay off for years. These items score badly on RICE and similar tools. The fix is to maintain a separate budget for strategic work, outside the framework. Allocate, say, twenty percent of capacity to strategic items and run the framework over the rest. The discipline of separating the two prevents either from being squeezed out.
Mistake Four: Skipping the Discussion
The numbers a framework produces are less valuable than the discussion that produces them. What does impact mean here? How sure are we about reach? Why is effort high? The answers to these questions are where insight comes from. Teams that simply assign scores in a spreadsheet without discussion get little benefit from the framework.
Mistake Five: Using One Framework for Everything
Different decisions need different frameworks. Comparing small features uses RICE; scoping a release uses MoSCoW; thinking about feature type uses Kano. A team that uses RICE for every decision will misuse it for many of them. Pick the framework to match the decision.
A Practical Approach to Prioritisation
Here is a practical sequence we use, drawing on multiple frameworks rather than committing to one.
- 1. Start with strategy. The roadmap and the work it contains should serve the strategy. Items that don't connect to the strategy are usually the first to cut.
- 2. Group items by type. Strategic bets, performance improvements, basic-expectation gaps, delighters. Use Kano thinking to make sure you have a balanced mix.
3. Within each group, score using RICE or value-effort. Get rough rankings within each
category. Treat close scores as ties.
- 4. Reserve capacity for each type. Don't let strategic bets get crowded out by quick wins. Allocate capacity explicitly: e.g., sixty percent on performance, twenty on basics, twenty on bets.
- 5. Use MoSCoW for release scoping. Once items are selected, group them into Must, Should, Could, Won't for the current release. This makes scope cuts visible and tells engineering what is essential.
- 6. Pressure-test the result. Walk through the priorities with engineering, design, and stakeholders. Where does the list feel wrong? Adjust based on insight, not just on preference.
- 7. Communicate the rationale. Don't just publish the list. Explain why these items, in this order. The rationale is what makes the prioritisation defensible and helps the team understand future trade-offs.
- 8. Revisit regularly. Priorities change. New evidence arrives. Re-prioritise at least quarterly, and adjust within a quarter when significant evidence comes in.
A Note on Politics
Prioritisation is also political. Different stakeholders want different things. The CEO has favourite features. Sales has deals depending on specific items. Engineering has technical debt they want to tackle. Customer success has support pain. All of these are legitimate; none should fully dictate the answer. Frameworks help here too: when the prioritisation is structured and defensible, it is easier to push back on individual political pressure.
When stakeholders push for items that score badly, ask them to argue against the framework rather than around it. This item scores low because reach is small and confidence is uncertain. What are we missing? Sometimes they reveal context that genuinely changes the analysis. Sometimes they have to admit the item isn't as critical as they thought. Either is useful.
A Final Word
Prioritisation frameworks are tools to make thinking visible and defensible. They are not oracles. They will not give you the right answer; they will help you see what you should be thinking about. The PMs who use them well treat them as a discipline, not as a calculator. Pick a primary framework that fits your context. Use it consistently. Supplement with others when they add value. Keep the discussions honest. Treat close scores as ties. Reserve capacity for strategic work that won't score well on standard frameworks. Communicate your rationale. Revisit regularly. Over time, your prioritisation will get better, not because the framework is magic, but because the practice of using it sharpens the judgment underneath.
Key Takeaways
- No framework gives you the right answer. They force you to consider the right factors. The discipline is the value.
- RICE works for comparing similar items; MoSCoW for scoping a release; Kano for thinking about feature type. Use the right framework for the decision.
- Beware false precision. RICE scores are estimates with wide error bars. Treat close scores as ties; only big gaps should drive prioritisation.
- Reserve capacity for strategic bets that score badly on standard frameworks. A separate budget prevents short-term thinking from squeezing out long-term investment.
- Discussions matter more than scores. The conversation about why something scored what it did is where the real insight lives.