RICE Scoring: Prioritize Features Like a Product Manager

RICE scoring ranks features and ideas by dividing what a change is worth by what it costs: multiply Reach, Impact, and Confidence, then divide by Effort. The framework — built at Intercom and now standard across product teams — turns "what should we build next" from a gut call into four separate, defensible estimates you can argue about individually instead of all at once.

Quick Answer: RICE score = (Reach × Impact × Confidence) ÷ Effort. Score every backlog item on those four factors, rank by the resulting number, and build from the top down. It works because it forces you to separate "how many people" from "how much it helps them" from "how sure you are" from "what it costs" — four honest guesses instead of one confident one.

Before you score anything: what you need on hand

RICE only works once you have a real backlog and rough usage numbers to score it against. Running it on a single idea in isolation, or on guesses with no data behind them, produces a number that feels precise and means nothing.

Two things need to exist before you open a spreadsheet:

• A written backlog. Every feature, fix, or experiment you're considering, listed as a single line each — not a paragraph of context, just the item itself. If you haven't separated your ideas from your validation plan yet, the startup validation toolkit walks through how to get from a raw idea to a scoreable list of assumptions and features.
• Basic usage estimates. Active user counts, signup volume, or — pre-launch — waitlist and interview numbers you can use as a stand-in for Reach. RICE tolerates rough numbers; it doesn't tolerate no numbers, because a Reach score with no anchor collapses back into the same gut feeling the framework exists to replace.

If you're still deciding what belongs in a first release at all, scope that first. Building an MVP is a narrower, earlier decision than ranking a backlog, and running RICE on a feature list that's still three products wide will only rank the wrong things precisely.

Step 1: Score reach — how many people this touches

Reach is a real number: how many users, customers, or leads a specific change will touch within a fixed time window, usually a month or a quarter.

Pick a period and hold it constant across every item you score, or the comparisons stop meaning anything — "reach per quarter" and "reach per month" produce backlogs that can't be ranked against each other. Pull the number from wherever it actually lives: active users who hit the relevant screen, signups in the affected segment, support tickets naming the problem. Avoid your total user count, which almost never matches who a given feature actually reaches.

Pre-revenue and pre-launch, substitute the closest real proxy you have: waitlist signups in the affected segment, interview participants who described the problem unprompted, or comparable usage from an earlier version of the product. That number is weaker evidence than live usage data, but it's still a number — better than skipping the estimate.

Step 2: Score impact — how much it moves the needle

Impact measures how much a single instance of Reach moves your target metric — not whether the feature is nice to have, but how hard it pushes the number you actually care about.

Intercom's original model scores Impact on a fixed scale rather than a free-form guess, because an unbounded scale invites everyone to cluster near the top:

• 3 — massive impact
• 2 — high impact
• 1 — medium impact
• 0.5 — low impact
• 0.25 — minimal impact

Name one metric before you start scoring — activation rate, retention, revenue, whatever the backlog is actually meant to move — and score every item against that same metric. A feature that's a 3 for engagement might be a 0.25 for revenue; without naming the metric up front, two people scoring the same item will land on different numbers for reasons that have nothing to do with the feature itself.

Step 3: Score confidence — how sure you actually are

Confidence is a percentage that discounts your Reach and Impact guesses by how much real evidence backs them, so an exciting idea with no data behind it can't outrank a smaller, well-tested one.

Use three fixed bands instead of a free-form percentage:

• 100% — high confidence. Backed by usage data, a completed experiment, or direct customer evidence.
• 80% — medium confidence. Some supporting signal, but incomplete — a handful of interviews, a partial metric, a strong pattern from a comparable feature.
• 50% — low confidence. Mostly a hunch. You believe it, but you couldn't point to the evidence in a meeting.

Anything weaker than 50% belongs in a "needs research" bucket, not on the scored backlog — a guess that thin isn't ready to be ranked against real evidence; it's ready to be tested first. That's the same discipline the Eisenhower Matrix applies to a task list: separate what's actually ready to act on from what still needs clarifying before it earns a slot.

Step 4: Score effort — what it costs your team

Effort is the total person-time required to ship the item, measured in person-months (or person-weeks for a small team), and it has to include every function that touches the work, not just the engineering estimate.

The most common Effort mistake is scoping only the build. A feature that takes one engineer two weeks to code often needs design time, QA, content, and a support runbook before it actually ships — leave those out and every Effort score in your backlog is quietly deflated in the same direction, which doesn't change the ranking but does make every RICE score look more impressive than it is. Estimate Effort as the full cost across everyone who has to touch the work before it's live, added together, not the fastest single person's guess.

Step 5: Compute the score and rank your backlog

Multiply Reach × Impact × Confidence, then divide by Effort, for every item on the list. The result is a single comparable number, and the backlog sorted high to low is your priority order — not a suggestion to renegotiate in the next meeting.

RICE score = (Reach × Impact × Confidence) ÷ Effort

Run every item through the same formula, using the same time window and the same target metric, and sort the results from highest to lowest. The number's job isn't to be exactly right — it's to make the trade-offs explicit enough that a disagreement becomes "I think the Effort estimate is wrong" instead of "I don't like this ranking."

Worked example: scoring a five-feature backlog

Here's what the math looks like against a five-item backlog for a hypothetical B2B SaaS product. The numbers below are illustrative, not measured data from a real product, but the arithmetic is exactly what you'd run on your own.

The onboarding checklist wins even though the dark mode toggle reaches more users, because Impact and Confidence pull the toggle down — plenty of people would notice dark mode, but few would be affected deeply by it, and the team isn't fully sure it changes behavior at all. The Slack integration looks exciting in a roadmap meeting but drops to fourth once its real Effort — three person-months across engineering and a partner review — is counted honestly. That reordering is exactly the pattern RICE is built to catch: it happens precisely where a loud idea meets an honest Effort number.

RICE vs. ICE vs. value/effort: which scoring method fits

RICE, ICE, and a value/effort quadrant all rank the same kind of decision — what to build next — but they trade precision for speed differently, and the right one depends on how much time you have and how much data backs your estimates.

ICE, popularized by growth practitioner Sean Ellis, drops Reach entirely and swaps Effort for Ease — faster to fill in, but it can't tell you whether an idea helps five users or five thousand. A value/effort quadrant is faster still and useful for a first pass in a workshop, but it's a conversation aid, not a ranking you'd defend in a planning doc. Reach for RICE once you have real usage numbers and a backlog big enough that "it feels important" stops being a reliable filter.

Common mistakes: confidence inflation and effort optimism

The two failure modes that quietly wreck a RICE backlog are confidence inflation — scoring everything at 100% because admitting uncertainty feels like admitting the idea is weak — and effort optimism, which scopes only the easiest slice of the work.

Watch for both, plus two related traps:

• Confidence inflation. If most of your backlog sits at 100%, you're not scoring confidence — you're scoring enthusiasm. Require a written reason for every 100%: which experiment, which dataset, which repeated customer signal. No citation, no 100%.
• Effort optimism. An Effort score that only counts the engineer's estimate is missing design, QA, content, support enablement, and rollout — every one of those adds real weeks. Undercounting Effort doesn't just distort one item; because Effort is the denominator, it inflates that item's rank relative to everything scored honestly.
• Rescoring only when the old answer is inconvenient. Updating Confidence the moment new evidence lands is the point of the framework. Updating it only when the old score produced a ranking you didn't like is gaming your own tool.
• Treating the score as final. RICE ranks your current guesses; it doesn't override judgment about sequencing dependencies, team morale, or a commitment already made to a customer. Use it to structure the debate, not to end it.

Key Takeaways

• RICE score = (Reach × Impact × Confidence) ÷ Effort. Four separate estimates beat one gut call because each one can be challenged on its own.
• Reach is a real number tied to a fixed time window, not a rounded-up total user count — pick a period and use it consistently across every item.
• Impact and Confidence use fixed scales, not free-form guesses, so scoring stays comparable across a whole backlog instead of drifting item to item.
• Effort has to include every function that touches the work — engineering, design, QA, content, support — or the denominator quietly flatters every score.
• Confidence inflation is the most common way RICE gets gamed. If most items sit at 100%, the score has stopped measuring anything real.
• RICE, ICE, and value/effort trade precision for speed differently. Use RICE for a real backlog with usage data, ICE for a fast weekly triage, and a value/effort quadrant for a first-pass workshop conversation.
• The output is a starting order, not a verdict. Use it to make trade-offs explicit, then apply judgment about dependencies and commitments on top.

Frequently Asked Questions

What counts as a good RICE score?

There's no universal good score — RICE scores are only meaningful relative to the other items on the same backlog, scored with the same time window and the same Impact scale. A score of 500 could be the top item on one team's backlog and mid-pack on another's, because Reach and Effort scale to that team's actual user base and capacity. Compare items within one list; don't compare scores across teams or products.

How do I estimate Reach before I have real users?

Substitute the closest proxy you actually have: waitlist signups in the affected segment, interview participants who raised the problem unprompted, or usage from a comparable earlier feature. That's weaker evidence than live product data, so pair it with a lower Confidence score rather than pretending the estimate is solid — that's exactly what the Confidence factor exists to capture.

Is RICE better than ICE?

Neither is universally better; they fit different moments. RICE adds a real Reach number and an Effort denominator, so it's worth the extra time once you have a sizeable backlog and actual usage data to score against. ICE drops Reach for a faster Ease score, which makes it a better fit for a quick weekly triage or an early-stage backlog where usage data doesn't exist yet.

How often should I re-score my backlog?

Re-score at the start of every planning cycle, and immediately any time new evidence changes a Confidence estimate mid-cycle — a completed experiment, a usage spike, a customer conversation that confirms or kills an assumption. Confidence is the factor that should move most often; Reach and Effort usually only need a fresh look when the product or team itself changes significantly.