RICE Scoring

Deciding what comes first, when there is more to build than time to build it, belonged to the meeting room for a long time. The problem was that the room only had one word for it. Everybody says "this matters," and everybody means something different by it.

A Pagedeck quarterly planning session ran into exactly that. The product backlog, the ordered pile of what might get built next, had 24 items on it. Sofia pushed permissions management that three enterprise customers had asked for, Ravi pushed a signup screen redesign, and Theo pushed structural cleanup that would be untouchable in six months if left alone. Two hours later there was still no order.

Each of them was arguing on a different axis. With all of it compressed into one word, there was no way to point at which axis the disagreement actually lived on.

RICE splits that one word into four: how many people this reaches, how large the change is for each of them, how much the estimate can be trusted, and what it costs to build. Split up, the argument moves from "does this matter" to "is the reach estimate of 2,000 right," and that question has an answer.

The arithmetic is the last line. The five steps before it are what produce the value.

1. Match the size of the candidates. Put a few days of work and a few months of work on the same table and whatever has the smallest effort figure wins every time. Copy changes and a payment-system replacement go on separate tables, each scored against its own peers.
2. Get reach — the number of users this change touches over a fixed period. Pinning the period down first is the trick. If the table is quarterly, every candidate gets counted quarterly; count one of them annually and that one inflates fourfold. If 2,000 people pass through the payment screen in a quarter, that is the reach.
3. Get impact — the size of the effect on one person who was reached, on a scale fixed in advance. A common one runs 3 for massive, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal. Reinvent the scale each round and this quarter's scores cannot be set beside last quarter's.
4. Get confidence — how much the previous two figures can be trusted, written as 100, 80, or 50 percent. Experiment results or usage records give 100, an inference from a comparable case gives 80, a guess gives 50. When more than half the table is sitting at 50, this is not a scoring exercise yet; it is a research one.
5. Get effort — the people and time required, counted in person-months. One person for one month is 1. This figure comes from the people who will actually build it, not from whoever is filling in the table. Written by the product side alone, it usually lands at half the real number, and that flips the whole ranking.

The calculation multiplies the first three and divides by the last. A candidate that 2,000 people pass in a quarter, with impact 2, confidence 80 percent, and three person-months, gives 2,000 times 2 times 0.8 divided by 3, which is 1,067. That figure means nothing on its own, and reading it as a quantity is the first mistake people make with it. What means something is that the candidate beside it, scored the same way, came out at 240.

It earns its keep once there are more than twenty candidates of roughly similar size. At five candidates, building the table costs more than reading the answer off it returns. It also fits when several teams are involved: being able to answer, axis by axis, why thirty items were deferred keeps the same discussion from reopening next quarter.

Three situations it does not suit.

1. A new product or a new market. There is nothing to base reach on. Any number written for a feature with no users yet is a guess, which puts every confidence value at 50 and leaves the scores indistinguishable from each other.
2. Deliberate strategic bets. Work that reaches few people today but sits on the path the company is taking always scores low here. Pick strictly by score and its turn never comes.
3. Small, easily reversed decisions. Scoring four axes for a copy change takes longer than making the change. Something lighter, like a value-effort matrix that pins candidates to quadrants on two axes, does better.

The limitation comes from how objective the numbers look. All four values are estimates a person wrote down, and passing them through a division makes them read as evidence. Effort is the sensitive one: written slightly low, it moves the ranking a long way. Three person-months recorded as two takes the score from 1,067 to 1,600, which is why the rule that builders own that figure is the method's safeguard.

"Let's run this through RICE. Right now everyone is just saying it's important."

A proposal to split the discussion into four axes and find where it diverges.

"Where does reach of 2,000 come from?"

Questioning the ingredients of a score rather than the score.

"It's third by score, but it has to happen this quarter — there's a date in the contract."

Naming an exception that gets pulled forward regardless of the ordering.

Pagedeck fills the table in once before quarterly planning. Mia gathers the candidates and writes the reach and impact columns, Theo supplies effort, and Sofia supplies the customer-side evidence. Once it is filled in, the meeting stops being a place where scores get read out and becomes one where odd-looking cells get questioned, which is a much shorter meeting.

The most common mistake is expecting the score to make the decision. Numbers come out in a ranked list, so building from the top looks like the plan. What the table actually does is move where the discussion happens. When two candidates score 1,067 and 980, that gap disappears if effort was off by half a month. Break ties by score only when the figures differ by an order of magnitude; when they're close, decide by which one sits nearer the direction the company is heading.

The second is treating the absolute number as meaningful. A value of 1,067 looks like it says something on its own, but the team set its own impact scale and its own period, so another team's 1,067 is not the same amount of anything. Compare scores only inside one table, and when two tables get merged, align the scales first.