Product prioritization frameworks: RICE, ICE, MoSCoW, Kano and more, compared

Product prioritization frameworks are structured methods for deciding what to build next by scoring or sorting ideas against agreed criteria such as reach, impact, effort, customer satisfaction or cost of delay. The most widely used are RICE, ICE, MoSCoW, Kano, value vs effort, opportunity scoring and WSJF. Use RICE or ICE to rank a backlog, MoSCoW to cut scope for a fixed date, Kano and opportunity scoring to understand customer value, and WSJF when the timing of delivery changes its value.

Key takeaways

• No framework makes the decision for you. Each one makes your assumptions visible so they can be argued about.
• RICE is the best default for ranking a mixed backlog; ICE is the fast version for experiments.
• MoSCoW is for scope negotiation against a deadline, not for ranking ideas against each other.
• Kano and opportunity scoring need customer input. They tell you what kind of value a feature creates.
• WSJF and cost of delay matter when waiting is expensive: regulatory deadlines, seasonal peaks, contracts.
• Score against your north star metric, not against a generic idea of "impact".

What is a product prioritisation framework?

A product prioritisation framework is a repeatable scoring or sorting method that helps a product team compare competing ideas on the same criteria, so decisions are explainable and less dependent on whoever argues loudest.

Every framework trades off speed, rigour and the kind of input it needs. Some can be filled in by a PM in ten minutes. Others need survey data from hundreds of customers. The right one depends on the decision in front of you.

Prioritization frameworks compared

RICE: reach, impact, confidence, effort

RICE was developed at Intercom and described by Sean McBride on the Intercom blog. It scores each idea by how many people it affects and how much, discounted by how sure you are, and divided by the work required.

Formula: RICE score = (Reach × Impact × Confidence) ÷ Effort

Two habits make RICE work. Define "impact" against one specific goal (for example weekly active payers), and treat anything below 50% confidence as a signal to do research before scoring, not as a number to plug in.

Worked RICE scoring example

Imagine a fictional Indian bill-payments app with about a million monthly users, planning next quarter. The goal is to grow monthly users who pay at least one bill. Here is how six candidate features score:

For example, UPI AutoPay is 120,000 × 2 × 0.8 ÷ 4 = 48,000.

Now read the table like a PM, not a calculator:

• Reminders win clearly. Wide reach, cheap to build, directly tied to paying a bill. Ship it.
• Dark mode ranks second, and that should make you suspicious. Its reach is everyone, but does it make anyone pay a bill? An impact of 0.25 against the stated goal may still be generous. RICE rewards broad, shallow changes; this is the moment to sanity-check rather than obey the score.
• AutoPay is the strategic bet. It scores well and creates a habit that compounds, which RICE does not capture. Many teams would sequence it right after reminders.
• Language support scores last because confidence is low, not necessarily because the idea is weak. The right move is a small study, perhaps a handful of customer interviews with users in Tamil Nadu and the Hindi belt, to raise or lower confidence before the next planning cycle.

The score is where the conversation starts. The decision, and the reason for it, belongs in the PRD and the roadmap.

ICE: impact, confidence, ease

ICE is a lighter scoring model popularised by Sean Ellis for growth experiments. Each factor is scored from 1 to 10.

Formula: ICE score = Impact × Confidence × Ease (some teams average the three instead of multiplying).

Use ICE when you have dozens of small experiments and the cost of a wrong guess is low: onboarding copy tests, notification timing, landing page variants. Because every input is a judgement, calibrate as a team. Score three past experiments together first, so "7 out of 10 impact" means roughly the same thing to everyone.

MoSCoW: must, should, could, won't

MoSCoW was created by Dai Clegg at Oracle in the mid-1990s and adopted by the DSDM agile method, now maintained by the Agile Business Consortium. It sorts requirements for a specific release into four buckets:

• Must have: the release fails without it (legally required, safety, or the core job cannot be done).
• Should have: important, but there is a workaround.
• Could have: desirable if time allows.
• Won't have (this time): explicitly out of scope for this release.

DSDM guidance recommends that Must haves take no more than about 60% of the effort in a timebox, leaving Should and Could items as contingency. That rule is the whole point: if Musts fill 100% of capacity, any slip means missing the date.

MoSCoW is excellent for negotiating scope with stakeholders before a fixed deadline, such as a Diwali sale or a regulatory compliance date. It is poor at ranking ideas against each other, because everything inside a bucket is equal.

Kano model: basic, performance and delighters

The Kano model, developed by Professor Noriaki Kano in the 1980s, classifies features by how their presence or absence affects customer satisfaction:

You find the categories by asking customers two questions per feature: how they would feel if it were present (functional) and how they would feel if it were absent (dysfunctional), each answered with options from "I like it" to "I dislike it". The pairing of answers places the feature in a category.

The insight Kano offers: delighters decay into basics over time. Live order tracking once surprised people; now its absence feels broken. Budget for basics before chasing delighters.

Value vs effort matrix

The simplest framework: plot each idea on a 2×2 grid of value (to customers and the business) against effort.

It is ideal for a 45-minute workshop where you need to sort 30 sticky notes. It is too coarse for choosing between two similar ideas, and teams systematically underestimate effort, so expect items to drift right once engineers weigh in.

Opportunity scoring

Opportunity scoring comes from Tony Ulwick's Outcome-Driven Innovation method. Instead of scoring features, you survey customers on the outcomes they want, rating each for importance and for how satisfied they are with current solutions.

Formula: Opportunity = Importance + max(Importance − Satisfaction, 0), with each rated on a 1–10 scale. (See the outcome-driven innovation overview on Wikipedia.)

High importance with low satisfaction marks an underserved need. In this example, payout reconciliation is the clearest opportunity, even though fast printing feels more urgent on a busy evening. Opportunity scoring is powerful early in discovery, before you have committed to specific features.

Cost of delay and WSJF

Cost of delay asks: how much value do we lose for every week this is not shipped? Don Reinertsen made the idea central to product development economics. Dividing cost of delay by duration gives a sequencing rule: do the work with the highest cost of delay per unit of time first.

The Scaled Agile Framework turns this into Weighted Shortest Job First (WSJF), using relative scores (often 1, 2, 3, 5, 8, 13, 20):

Formula: WSJF = Cost of delay ÷ Job size, where cost of delay = user-business value + time criticality + risk reduction and/or opportunity enablement.

The small, risk-reducing retry logic goes first, then the deadline-driven compliance work, then the dashboard. WSJF shines for platform and cross-team work where RICE's "reach" is meaningless.

Which prioritisation framework should you use?

Most mature teams combine two: an opportunity or Kano study to decide which problems matter, then RICE or WSJF to sequence the solutions on the product roadmap.

How to run a prioritisation session

1. Agree the goal first. One metric, ideally an input to your north star. Without it, "impact" means something different to each person.
2. Pick one framework and share the scales in advance.
3. Have people score independently, then compare. Big disagreements are the most useful output: they reveal different assumptions.
4. Discuss outliers, not averages. Ask "what would have to be true for this to be a 3?"
5. Sanity-check the top five. Does the ranking feel wrong anywhere? Say why, and either change an input or record an override with its reason.
6. Publish the result and the reasoning, including what you chose not to do.
7. Re-score when you learn something, not on a fixed ritual.

Common prioritisation mistakes

• Spreadsheet theatre: inflating inputs until a favourite idea wins.
• Ignoring confidence: treating a guess and a measured result as equally reliable.
• Comparing unlike work in one model: bugs, tech debt and new features rarely belong in the same RICE table.
• Forgetting strategy: a framework ranks within your strategy; it does not replace it.
• No follow-up: never checking whether shipped items delivered the impact you scored. That check is how your estimates improve.

Prioritisation also comes up constantly in interviews; expect a version of "how would you prioritise these five features?" in most product manager interview questions rounds.

Frequently asked questions

What is the best product prioritization framework?

There is no single best one. RICE is the most useful default for ranking a backlog because it includes reach, impact, confidence and effort. Switch to MoSCoW when you are cutting scope for a deadline, and to WSJF when timing changes the value of the work.

What is the difference between RICE and ICE?

RICE adds reach and measures effort in person-months, so it suits larger, planned features. ICE scores impact, confidence and ease from 1 to 10, so it is faster but more subjective. ICE is best for high volumes of small, cheap experiments.

How do you calculate a RICE score?

Multiply reach by impact by confidence, then divide by effort. For example, a feature reaching 120,000 users a quarter with impact 2, confidence 80% and effort of 4 person-months scores 120,000 × 2 × 0.8 ÷ 4 = 48,000.

When should you use the Kano model?

Use Kano when you need to understand how features affect customer satisfaction, especially when deciding between investing in basics and building delighters. It needs a survey of real customers, so it suits planning cycles rather than weekly decisions.

Is MoSCoW good for product prioritisation?

MoSCoW is good for scoping a specific release against a deadline and for stakeholder alignment. It is weak at ranking ideas against each other, because every item in a bucket is treated as equal. Keep Must haves to no more than about 60% of the effort, as DSDM recommends.

Practise prioritising with other PMs

Frameworks get easier when you watch experienced people argue about real trade-offs. In Product Circle, members bring questions like these to a weekly AMA with a PM or founder, and can book office hours with VCs and founders who have built and hired before. If you would like to join 250+ PMs and founders doing this, see how to join.

• Prioritisation
• Frameworks
• Roadmaps