Product Prioritization Frameworks: RICE, MoSCoW, Kano and Value vs Effort

A meal-kit subscription company has six ideas on its board and room to build two this quarter. The founder wants gift subscriptions, support wants a skip-a-week button, and an engineer is quietly pushing for dark mode. Everyone has a good argument and a loud voice. A prioritization framework does not magically pick the winner. What it does is make the arguments comparable, so that the debate is about numbers and assumptions instead of volume.

RICE: scoring by reach, impact, confidence and effort

RICE gives each idea a single number. Reach is how many people it affects in a fixed period, for example per quarter. Impact is how much it moves the goal for each of those people, usually on a rough scale such as 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal. Confidence is a percentage that discounts your own optimism. Effort is the work required, commonly in person-months. The formula is Reach times Impact times Confidence, divided by Effort.

Here is the meal-kit backlog scored for one quarter. Every number below is an invented example to show the arithmetic, not data from a real company. Imagine the goal is to reduce the number of subscribers who cancel.

Check one row by hand: the skip-a-week button is 4000 x 2 x 0.8 = 6400, divided by 2 person-months, which gives 3200. The SMS reminder wins because it is cheap and reaches many people, even though its impact per person is only medium.

Now look at what RICE got wrong. Allergy filters rank fifth, but for a food business, showing a customer meals containing an ingredient they are allergic to is a safety issue, not a nice-to-have. RICE has no notion of a legal or safety floor. It also treats Confidence as a rounding error, when a 50 percent guess on a 5-person-month project is really a research task disguised as a feature.

MoSCoW: deciding what is in or out of a release

MoSCoW sorts items into Must have, Should have, Could have and Won't have this time. It suits a fixed deadline or budget, such as a launch date, where the question is not "what is best?" but "what must be there for this release to make sense?". A good test for a Must: if it were missing on launch day, would we delay or cancel? If the answer is no, it is a Should.

Applied to the meal-kit board for a relaunch of the app, allergy filters would be a Must. SMS reminders and skip-a-week would be Shoulds. Dark mode and recipe ratings would be Coulds, and gift subscriptions would be a Won't this time. The framework's weakness is inflation: stakeholders label everything Must. A common guardrail is to cap Musts at roughly half of the available capacity, so that there is room to absorb surprises.

Value versus effort: a quick map for a group

Plot each idea on a two-by-two grid with value on one axis and effort on the other. High value and low effort are quick wins to do first. High value and high effort are big bets that need planning. Low value and low effort are fillers, and low value and high effort are things to avoid. Its strength is speed: a team can place sticky notes in twenty minutes without a spreadsheet.

                 HIGH VALUE
                      |
   BIG BETS           |   QUICK WINS
   Allergy filters    |   SMS reminder
                      |   Skip-a-week
                      |
 HIGH EFFORT ---------+--------- LOW EFFORT
                      |
   AVOID              |   FILLERS
   Gift subscriptions |   Dark mode
   Recipe ratings     |
                      |
                 LOW VALUE

The weakness is that "value" is whatever the people in the room think it is. Without a stated goal, a loud person's favourite idea drifts to the upper half of the grid.

Kano: why some features do not behave like others

The Kano model is less about ranking and more about understanding how customers react. It separates features into must-be (expected; their absence angers people but their presence earns no praise, like allergy safety), performance (more is better, such as faster delivery windows), attractive (unexpected delighters, such as a surprise recipe card) and indifferent (people do not care). Over time attractive features tend to become expected.

To use it, ask a sample of users two questions per feature: how would you feel if it existed, and how would you feel if it did not. The answer pair places the feature in a category. Kano needs real customer input, takes more effort than the other methods, and tells you nothing about cost, so use it to sanity-check a shortlist rather than as your only filter.

Using them together

1. Name the goal and any hard constraints, such as legal or safety items and committed dates.
2. Pull out the non-negotiables first. These are your Musts and they skip the scoring.
3. Score the remainder with RICE, and mark any item whose Confidence is below 60 percent as a research task rather than a build.
4. Sanity-check the top five with a value-vs-effort map and ask whether any surprises you.
5. Use Kano on a few high-visibility features if you are unsure how customers will react.
6. Treat the final order as a proposal. Show the assumptions and invite the team to challenge them.

Common mistakes

• Treating the score as the decision. Symptom: the team ships a 3200 over a safety fix and a customer complains. Frameworks inform judgment; they do not replace it.
• Changing numbers until your favourite wins. Symptom: the same idea's reach doubles between two meetings. Fix the scale beforehand and record where each number came from.
• Comparing scores computed against different goals. Symptom: a retention idea ranks beside an acquisition idea and no one can explain why. Score one goal at a time.
• Estimating effort without engineers. Symptom: a 1-month item takes four. Ask the people who will build it.
• Ignoring dependencies. Symptom: a high-ranked item cannot start because a low-ranked one must come first.

How this shows up in real projects and interviews

Most teams use a rough mix of these, not a pure version of one. A planning meeting usually starts from goals, takes commitments off the top, and uses a quick score to order the rest. What stakeholders trust is the transparency: when the owner of a rejected idea can see the numbers and challenge them, they accept the outcome more easily.

In interviews you will often be given a list of features and asked what to build first. Do not recite a framework by name. Say the goal, name the constraint, score the top few out loud, and point out where the framework would mislead you, as we did with allergy filters. That shows judgment, which is what the question is really testing. For a similar approach to personal workloads, see the Eisenhower Matrix lesson.