Prioritization frameworks: RICE, MoSCoW, Kano and ICE
RICE, MoSCoW, Kano and ICE are frameworks for deciding what to build first. What each one measures, how to apply it, its limits and when to pick it.
Why prioritize with a framework?
Because there is almost never time for everything. Without explicit criteria, priorities are set by whoever speaks loudest, or by the last meeting. A framework does not remove the debate, but it forces it to happen with visible criteria: what we assume, what weighs most and why.
For a designer, prioritization is part of the job. Deciding which flow to redesign first, which accessibility problem to tackle or which missing error state to complete is, at heart, a priority decision. If that decision is not justified, the team ends up doing what is most visible rather than what matters most.
If the discussion is about what to measure, review outcomes versus outputs before you score anything. And if you need to order priorities over time, the design roadmap is where they live.
What does each framework measure?
| Framework | Criteria | Scale | Best for |
|---|---|---|---|
| RICE | Reach, impact, confidence, effort | Numbers; impact from 3 to 0.25 | Comparing many initiatives with data |
| MoSCoW | Must, should, could, won’t | Categories, no numbers | Scope of a release or sprint |
| Kano | How the user feels about the feature | Five categories (must-be, one-dimensional, attractive, indifferent, reverse) | Understanding what users value |
| ICE | Impact, confidence, ease | 1 to 10 per factor | Quick decisions, experiments |
How does each framework work?
RICE
RICE combines four factors into a single score. Intercom describes it as a model for deciding what to build.
- Reach: how many people or events it affects in a period, for example “customers per quarter”.
- Impact: how much it affects each person reached; each team can measure it against its own goal, such as conversion. Intercom uses 3 (massive), 2 (high), 1 (medium), 0.5 (low) and 0.25 (minimal).
- Confidence: how sure we are of the numbers. Intercom uses 100%, 80% and 50%, and warns that below that an initiative is a “moonshot”.
- Effort: in person-months, adding the time of product, design and engineering.
The formula is (Reach × Impact × Confidence) / Effort. Intercom admits that scoring impact is subjective, and that RICE is not a rigid rule: dependencies or table-stakes features may justify working first on something with a lower score. It recommends re-checking the result and adjusting the estimates if the order looks wrong. The value of RICE lies in forcing you to write the numbers down, not in the final number.
MoSCoW
Dai Clegg proposed it in 1994 for rapid application development, and it is widely used today for releases with fixed scope. Its four categories, according to Wikipedia’s definitions:
- Must have: critical to the current delivery.
- Should have: important, but not necessary for this delivery.
- Could have: desirable, but not necessary.
- Won’t have: agreed with stakeholders as the least critical, for now.
Its main limit is that it does not help order items within the same category. “Won’t have” is also ambiguous: it can mean “not in this version” or “never”.
Kano
Noriaki Kano developed it in the 1980s. Instead of scoring, it classifies each feature by how it affects satisfaction. Wikipedia lists five categories (must-be, one-dimensional, attractive, indifferent and reverse); the three most useful for design are:
- Must-be: requirements users take for granted. If they are missing, they cause strong dissatisfaction; if they are present, they add little. A working brake in a car is Wikipedia’s example.
- One-dimensional: satisfaction rises with performance. More speed, more precision, more options (within reason).
- Attractive: features users do not expect, which create satisfaction when present. These are the ones people remember.
Kano helps you decide where to invest beyond what users ask for. Wikipedia’s article notes that several sections do not cite sources, so verify any classification with your own research.
ICE
ICE is attributed to Sean Ellis and rates three factors from 1 to 10: impact (how much it moves the needle), confidence (how sure we are of that impact) and ease (how much effort it takes). The score is the product of the three.
It is fast, but almost entirely subjective: two people can give different scores. ProductPlan says it is probably not the best method for prioritizing an entire product roadmap. It works best for short experiments, where the discussion is the valuable part.
When should you NOT use a framework?
- When you already know something is urgent, such as a critical bug in production.
- When you have no data or hypotheses. A framework with invented numbers gives false precision.
- When priority depends on strategy, not on scores. For that, review the product’s strategy and vision and its North Star Metric first. Once goals are clear, the framework sorts the rest.
- When the team uses the score to avoid discussion. The framework starts the conversation; it does not end it.
Example
Illustrative example: a design team has seven candidate improvements for the next quarter. It applies RICE to three of them. A form improvement affects 4,000 people per quarter, with high impact (2), medium confidence (80%) and one person-month of effort. The score is 4,000 × 2 × 0.8 / 1 = 6,400. Another improvement affects 800 people, with massive impact (3), low confidence (50%) and three person-months of effort: 800 × 3 × 0.5 / 3 = 400. The first wins. The team discusses the confidence of the second and decides to run a test before committing three months.
For your next prioritization: choose five initiatives, write each criterion as a number, even an approximate one, and check whether the order surprises you. The surprise is a hint that an assumption is wrong.
Common mistakes
- Applying a framework without agreeing on the scale. “High impact” means something different to each person.
- Using numbers without data and treating the result as truth.
- Using MoSCoW for long roadmaps, where it does not distinguish priorities within each category.
- Classifying with Kano without asking users. The categories describe how people react, not what the team thinks.
- Ignoring strategy and prioritizing by score alone.
- Not reviewing the result: if the order makes no sense, the framework is misconfigured.