RICE Scoring

What is RICE Scoring?

RICE scoring is a prioritization framework that ranks competing ideas by multiplying Reach, Impact, and Confidence, then dividing the result by Effort, so you can compare projects that have nothing else in common on one number.

The method was introduced by Sean McBride on the Intercom blog in a post titled "RICE Prioritization Framework for Product Managers." In it, Reach is the number of people or events an initiative touches in a given period, Impact uses a five-step multiplier scale (3 for massive, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal), Confidence is a percentage band (100% high, 80% medium, 50% low) that discounts scores you're less sure about, and Effort is estimated in person-months. ProductPlan's glossary entry describes RICE the same way and attributes the model's origin to Intercom, built to sharpen the company's own internal roadmap decisions.

Both sources are consistent on one point worth stating plainly: the score is an input to judgment, not a replacement for it. McBride's post is explicit that RICE scores "shouldn't be used as a hard and fast rule," because dependencies between projects or a must-have feature for a sales deal can justify working on a lower-scoring item first.

Why it matters for product-market fit

RICE earns its place in the Decide stage of Produck's Listen, Diagnose, Decide, Ship loop. By the time a team is scoring anything, they've already listened to raw signal and diagnosed which problems are real. RICE is the tool that turns a pile of validated problems into an ordered list you can actually commit to shipping.

Where RICE breaks down for most teams isn't the math, it's the inputs. Reach and Confidence are only as good as the evidence behind them, and if your feature request backlog is just a spreadsheet of one-line asks with no record of who asked or how often, you're scoring guesses and dressing them up as rigor. Produck's Listen stage exists to fix that upstream problem: it captures each request with the user and the frequency attached, so a Reach estimate is a count you can defend instead of a number you made up to fill a cell. That link between real evidence and PM decisions is also the whole thesis behind what PMF actually requires from a product team: you can't decide well on feedback you never organized.

RICE isn't the only way to rank a backlog. The MoSCoW Method sorts by necessity instead of score, which some teams prefer when they want a simpler, four-bucket call rather than a formula. Neither is universally right. The point is to pick the framework that matches how confidently your team can fill in the inputs, and to feed it real data rather than internal hunches.

When it works, and when it doesn't

It works when:

• You have enough usage or request data to estimate Reach and Impact from something other than a gut feeling.
• You're comparing several plausible initiatives at once and need a shared scale, not just one idea you're trying to justify.

It falls short when:

• The backlog is small enough that a real conversation would settle the order faster than four separate estimates.
• Reach, Impact, and Confidence are all guesses, in which case the score just launders opinion into a number that looks objective.
• A dependency, contractual requirement, or safety issue means the highest score isn't actually free to build first.
• Effort estimates come from whoever is loudest in the room rather than the engineers who'll do the work.

How to apply it

1. Pull your shortlist of candidate initiatives from a Decide-stage review, ideally ones that already survived a Diagnose pass so you know the underlying problem is real.
2. For each one, estimate Reach as a count of people or events over a fixed period, using actual request or usage data wherever you have it.
3. Score Impact on the five-step scale (massive, high, medium, low, minimal) and assign the matching multiplier.
4. Set Confidence at 100%, 80%, or 50% based on how much of your Reach and Impact estimate is data versus intuition.
5. Estimate Effort in person-months with input from engineering, then calculate (Reach x Impact x Confidence) / Effort for each item and rank the list.
6. Treat the ranking as a starting point. Before you commit to the order, check it against anything the formula can't see, like a customer contract that requires a specific fix by a specific date.