RICE prioritisation in practice: the Impact column is where it breaks

RICE is the most widely used prioritisation framework in product, and most teams using it are getting one term badly wrong. Not because they’re careless — because three of the four terms can be estimated from evidence, and the fourth cannot, and nothing in the formula tells you which is which.

The formula, and what each term is really asking

Reach × Impact × Confidence ÷ Effort

Term	Question	Where the number comes from
Reach	How many users, in what period?	Measurable. Your analytics.
Impact	How much does it move things for each of them?	Guessed. Always.
Confidence	How sure are you about the above?	Judgement, but calibratable
Effort	Person-months to build	Estimable, by engineering

Reach and Effort come from data and from people whose job is estimating. Impact is a number a product manager invents. That’s not a criticism — it’s the irreducible judgement at the heart of the job. The problem is what happens next.

The Impact problem

Once Impact is in a spreadsheet cell, it stops looking invented. It gets multiplied by two measured quantities, divided by a third, and comes out the other end as a score with a decimal place. The arithmetic launders a guess into a figure, and by the time it reaches a stakeholder meeting nobody remembers which term was the soft one.

The standard scale — 3 for massive, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal — makes this worse rather than better, because the gap between “high” and “massive” is a factor of 1.5 that will reorder your entire roadmap and that nobody can defend.

Two fixes, both cheap:

1. Have someone with no stake score Impact. Score the top five candidates twice — once by the PM who wants it, once by someone from another area. If the order changes, your Impact numbers were politics, and now you know before the meeting rather than during it.

2. Write the sentence behind the number. Not “Impact: 2” but “Impact: 2 — because I think this removes about half the manual re-keying for the accounts that do it.” Now it’s falsifiable. Someone can disagree with the sentence, which they can’t meaningfully do with a 2.

Scoring the other three honestly

Reach — pick one period and never change it. Users per quarter is the usual default. The most common error is counting everyone who could encounter the feature rather than who realistically will, which quietly inflates every score by the same factor and therefore changes nothing — except it makes the numbers meaningless in absolute terms.

Confidence — 100% means you have data. 80% means you have some evidence. 50% means it’s an argument you find persuasive. Anything you’d score below 50% shouldn’t be on the list; it should be a cheap test instead. That’s the most useful thing Confidence does: it identifies the items where the right next step isn’t building, it’s finding out.

Effort — get it from engineering, in person-months, and accept the range they give you rather than the midpoint. A “1–4 months” estimate is telling you something the number 2.5 hides.

Where RICE is the wrong tool

Enterprise and depth-heavy work. A feature that unblocks three accounts worth 40% of revenue scores catastrophically on Reach. RICE is built for consumer-shaped distributions, and it systematically under-rates concentrated value. If a big chunk of your revenue sits in a few accounts, RICE alone will mis-sort your roadmap every time.

Foundational and platform work. The payoff is diffuse and downstream. Score it in RICE and it loses to everything.

Anything genuinely urgent. RICE has no time dimension at all — a thing worth €50k this quarter and €50k next quarter scores identically to one worth €100k only if shipped before a regulatory deadline. That’s what Cost of Delay is for, and it’s the framework I’d most often add alongside RICE rather than instead of it.

How to actually run it

• Score in a batch, not per item. Relative judgement is much more reliable than absolute, so put ten things in a spreadsheet at once.
• Re-score after the fact. Six weeks after shipping, go back and put the real numbers next to the estimates. This is the step everyone skips, and it’s the only one that makes the next round of estimates better.
• Never present the score alone. Present the score, the Impact sentence, and the thing that came second. A ranked list invites arguing with the rank; the reasoning invites arguing with the reasoning, which is the conversation you want.
• Let it be overruled. RICE output that can’t be overridden by a good argument turns into a way of avoiding responsibility for decisions. It’s a structure for the conversation, not a substitute for one.

That last point is the one that decides whether RICE helps you. Teams where the spreadsheet has authority and nobody has judgement end up defending scores they don’t believe. Teams where judgement has authority and the spreadsheet organises the argument make better calls and can explain them afterwards — which is most of what a promotion committee is looking for anyway.

---

If you’ve got a RICE spreadsheet that everyone maintains and nobody acts on, the framework isn’t the problem. That’s worth diagnosing before you replace it with a different one — usually in about twenty minutes, which is a fair chunk of what a first coaching session tends to be.