Prioritisation frameworks: RICE, MoSCoW, Kano and value versus effort

Every product team has more ideas than time. Prioritisation frameworks exist to make the choice between them less political and more consistent. None of them makes the decision for you. What they do is force you to state your assumptions in a way other people can challenge.

This guide covers four common approaches: RICE, MoSCoW, the Kano model and the value versus effort matrix. For each one you will find how it works, a worked example and where it tends to go wrong. They answer slightly different questions, so the last section explains which to pick.

RICE: scoring ideas against each other

RICE was developed at Intercom and described by Sean McBride in a 2018 article on the Intercom blog. It scores each idea on four factors:

• Reach: how many people or events the idea affects in a set period, such as customers per quarter. Use real product data where you can.
• Impact: the effect on each person, on a fixed scale: 3 for massive, 2 high, 1 medium, 0.5 low and 0.25 minimal.
• Confidence: how sure you are about the estimates: 100% high, 80% medium, 50% low. Intercom describes anything below 50% as a moonshot.
• Effort: total person-months across product, design and engineering.

The score is Reach × Impact × Confidence ÷ Effort, which Intercom describes as total impact per time worked.

An example (illustration only). A team selling accounting software to small firms compares three ideas for the next quarter.

The dull fix wins by a wide margin because it touches many people and costs almost nothing. That is a common and useful result. Intercom is clear that scores are a guide, not a rule: a lower-scoring item may still go first because of a dependency or a commitment to a key customer. Re-read the sorted list and adjust anything that looks wrong.

MoSCoW: agreeing scope for a fixed deadline

MoSCoW was created by Dai Clegg in 1994 and became part of the DSDM agile method, according to Wikipedia. It sorts requirements for a specific release or timebox into four groups. The Agile Business Consortium guidance defines them as:

• Must have: the Minimum Usable SubseT. Without these the release is not worth shipping on the planned date.
• Should have: important but not vital. Painful to leave out, but there is usually a workaround.
• Could have: wanted but less important, and the first to drop if time runs short.
• Won’t have this time: agreed as out of scope for this timeframe, and recorded so they do not creep back in.

The guidance recommends that Must haves take typically no more than 60% of the effort, with around 20% in Could haves as contingency. That rule is the part most teams skip, and it is the part that makes MoSCoW work. If everything is a Must, you have no room to absorb surprises.

The main criticisms, noted on Wikipedia, are that MoSCoW does not rank items within a group and gives little reason why something is a Must rather than a Should. It is a scope tool, not a ranking tool.

Kano: understanding how features affect satisfaction

The Kano model, developed by Noriaki Kano in the 1980s, sorts features by how they affect customer satisfaction:

• Must-be: basic expectations. Meeting them earns no praise, but missing them causes strong dissatisfaction.
• One-dimensional (performance): more is better, less is worse. Speed and price often sit here.
• Attractive: unexpected features that delight when present and are not missed when absent.
• Indifferent: features customers do not care about either way.
• Reverse: features some customers actively dislike.

To classify a feature, you ask customers two questions: how they would feel if the product had it, and how they would feel if it did not. Each answer uses a five-point scale (like it, expect it, neutral, can tolerate it, dislike it), and the combination places the feature in a category. Categories drift over time. What delights customers this year often becomes an expectation once competitors copy it.

Kano is useful before you score anything, because it tells you which features you cannot skip and which ones might set you apart. It needs real customer responses to be worth much.

Value versus effort: the quick visual

The simplest approach plots each idea on a two-by-two grid with value (or impact) on one axis and effort on the other. Product School names the quadrants as quick wins (high value, low effort), big bets (high value, high effort), fill-ins (low value, low effort) and money pits (low value, high effort).

It works well in a workshop to sort a long list fast. Its main weakness, which Product School also points out, is inconsistent scoring. If two people mean different things by “high value”, the grid looks precise while hiding disagreement. Agree what each axis means, in numbers if possible, before anyone places a sticky note.

Choosing the right one

They also combine well. Use Kano to find the must-be features, MoSCoW to protect them in a release, and RICE to order everything else.

Common mistakes

• Treating the score as the decision. The output is an input to a conversation, not a verdict.
• Inflating confidence. If nobody has spoken to a customer about an idea, its confidence is low, however sure the person proposing it feels.
• Scoring features, not problems. Prioritise the problem first, then the best solution to it.
• Letting Musts swell. Hold the 60% line or MoSCoW stops protecting the deadline.
• Never revisiting. Estimates change as you learn. Re-score at least every planning cycle.

When not to use a framework

Some work does not belong in a scoring exercise. Legal and regulatory changes, security fixes and outages need doing regardless of score. Strategic bets the leadership team has already agreed should be framed as outcomes, not fed into a spreadsheet to compete with small fixes. And if you have only three ideas, a short conversation is often faster than any framework.