RICE Framework Explained With a Full Worked Example

RICE is a way to decide which feature to build first, by giving each idea a score based on four things: Reach, Impact, Confidence, and Effort. You multiply Reach, Impact, and Confidence together, then divide by Effort, to get one final number for each idea. The higher the number, the higher that idea should be on your priority list. RICE was created at a company called Intercom by Sean McBride, as a way to replace "we prioritize based on whoever argues loudest" with a number everyone on the team can see and question.

Quick facts

• The formula is: RICE score = (Reach × Impact × Confidence) ÷ Effort
• Reach = how many people this will affect in a set period of time, written as a real number (like "800 customers this quarter")
• Impact = how much difference it makes to each person, scored on a simple scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
• Confidence = how sure you are about your Reach and Impact numbers, written as a percentage (100%, 80%, or 50%)
• Effort = how much work it takes to build, measured in person-months (one person working for one month)
• RICE works best when you're comparing several medium-sized feature ideas within the same team's backlog.
• RICE works worst for brand-new products with no usage data yet, or when comparing ideas from teams whose "effort" means very different things.

The formula, explained piece by piece

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

Part of the formula	What it measures	How you score it
Reach	How many people this touches, in a set time period	A real number — customers, users, or sessions per month or quarter
Impact	How much this helps each person it reaches	3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence	How sure you are that your Reach and Impact numbers are accurate	A percentage: 100% = very sure, 80% = fairly sure, 50% = a guess
Effort	How much work it will take the team to build this	A real number, in person-months, estimated by whoever will actually build it

A full worked example

Picture a mid-size business software company that makes an invoicing tool. We'll call it "Ledgerly" (a made-up name, so the numbers are easy to follow). The team is comparing three ideas for what to build next quarter.

Idea A — Let customers export invoices in bulk as a CSV file

• Reach: 1,200 customers per quarter would use this
• Impact: 1 (medium — helpful, but not life-changing for the customer)
• Confidence: 90% (the team understands this well, so there's little guesswork)
• Effort: 1.5 person-months
• RICE score = (1,200 × 1 × 0.9) ÷ 1.5 = 720

Idea B — Use AI to draft reminder emails for unpaid invoices

• Reach: 400 customers per quarter would use this, at first
• Impact: 2 (high — this could reduce how often customers pay late, a common complaint)
• Confidence: 60% (this is new territory, so the team isn't fully sure how well it will work)
• Effort: 3 person-months
• RICE score = (400 × 2 × 0.6) ÷ 3 = 160

Idea C — Support multiple currencies

• Reach: 150 customers per quarter are currently unable to buy the product without this feature
• Impact: 3 (massive for that specific group — without it, they can't use the product at all)
• Confidence: 100% (the sales team has clear records of deals lost because of this exact gap)
• Effort: 4 person-months
• RICE score = (150 × 3 × 1.0) ÷ 4 = 112.5

What this tells us: Based on the RICE score alone, the CSV export (720) wins by a wide margin — it's cheap to build and reaches almost everyone. But a good product manager doesn't stop at the number. Multi-currency support has the lowest score, yet it's the only idea directly blocking new customers from buying at all. If the team only followed the RICE score, they might keep pushing that fix down the list forever, even though it's costing them real revenue. This is exactly why RICE should help you narrow your options — not make the final decision for you.

How to run a RICE scoring session, step by step

1. List every idea you're considering for the time period you're planning — don't mix small quick fixes with huge multi-month projects in the same comparison, since the numbers won't mean the same thing across very different sizes of work.
2. Estimate Reach as a team, using real data from your analytics tool, your sales records, or your support tickets — not a gut feeling.
3. Score Impact using the same fixed scale every time (3, 2, 1, 0.5, or 0.25), so everyone on the team is using the same yardstick.
4. Be honest about Confidence. If you're mostly guessing, say 50%. Don't quietly bump the number up just because you want your favorite idea to win.
5. Ask whoever will actually build it to estimate Effort, in person-months rather than days — days tend to create a false sense of precision.
6. Calculate every score, then rank the ideas — but double-check the ranking against anything the formula can't see, like a blocking bug, a compliance requirement, or a strategic bet, the same way we did with the multi-currency example above.

Where RICE breaks down

• Brand-new products with no users yet. Without real usage data, every Reach number is a guess, which makes the "objective" score misleadingly precise. For an early-stage product, tools like Jobs to Be Done or direct interviews with potential customers work better.
• Important but low-reach work. As the multi-currency example shows, something that blocks a small but important group of customers can lose to an easy win that doesn't really matter. Treat RICE as one input among several, not the only vote that counts.
• Comparing ideas across different teams. "Effort" measured in person-months means something different to a 3-person team than it does to a 30-person team. Don't rank ideas from two different teams on the same RICE list without adjusting for that first.

RICE is just one of several ways to prioritize what to build. See how it compares to MoSCoW, Kano, and ICE scoring in our prioritization frameworks comparison.

Common mistakes teams make when running RICE

• Letting Confidence become a way to sneak a favorite idea to the top. If a team keeps scoring their preferred idea at 100% confidence and everything else lower, the scoring session has stopped being objective — treat unusually high confidence scores as something to double-check, not celebrate.
• Skipping the "sanity check" step at the end. The worked example above showed how the highest RICE score isn't always the right first choice. Teams that treat the ranked list as final, without asking "does this still make sense," end up shipping the cheapest ideas instead of the most important ones.
• Estimating Effort in days instead of person-months. Day-level estimates create a false sense of precision and tend to be wildly optimistic. Person-months force a more honest, higher-level estimate.
• Re-scoring an idea every time someone disagrees with its rank. RICE scores should be revisited when real facts change (new data, a changed deadline), not simply because a stakeholder is unhappy with where their idea landed.

RICE for a real backlog, not just three ideas

In practice, a quarterly planning session usually involves scoring 15 to 30 ideas at once, not three. The mechanics are the same as the worked example above, just repeated for every idea, but two extra habits help at that scale: group similar ideas together before scoring (comparing five small bug-fix-sized ideas against one large multi-month bet on the same list produces misleading rankings), and re-run the scoring exercise as a group discussion rather than everyone scoring alone and averaging the numbers — the conversation that happens while assigning scores is often more valuable than the score itself, because it surfaces disagreements about assumptions early.

FAQ

Who invented the RICE framework? Sean McBride created RICE while working at Intercom, and it became widely used across the product management field after Intercom wrote about it publicly.

What counts as a "good" RICE score? There's no universal good score. A RICE score is only useful when you compare it to the other ideas in the same batch, because Reach and Effort are raw numbers specific to your own product and team size.

What's the difference between RICE and ICE? ICE (Impact, Confidence, Ease) is a simpler, faster three-part version that skips the separate Reach number — good for a quick gut-check. RICE adds Reach as its own factor, which takes longer but gives you a more defensible answer for bigger, cross-team prioritization decisions.

Can RICE be used outside of product management? Yes. Marketing and growth teams, and even some project managers, use RICE or a very similar version of it to decide which campaigns or experiments to run first.

How often should a team re-run RICE scoring? Most teams re-score at the start of each planning cycle, such as every quarter, rather than continuously. Scoring too often wastes time re-litigating decisions before new data has had a chance to come in; scoring too rarely means the backlog stops reflecting what the team has actually learned.

Should RICE scores ever override a direct request from a senior leader? Not automatically, but a RICE score gives you a concrete, evidence-based way to have that conversation instead of just saying yes. If a low-scoring idea still needs to happen for a strategic reason a formula can't capture — like a regulatory deadline — say so explicitly, rather than quietly inflating the score to justify a decision that's already been made.