Master Your Backlog: Why RICE Beats Gut Feel
Every product team has the same problem: more feature requests than time to build them. Someone in sales wants a custom export. Your biggest customer wants SSO. Support keeps flagging a confusing onboarding step. All of it feels important, and without a shared method for weighing these against each other, prioritization quietly turns into "whoever asked most recently" or "whoever shouts loudest."
The RICE framework fixes this by forcing every idea through the same four questions before it earns a spot on your roadmap:
- Reach — how many people will this affect in a given period?
- Impact — how much will it move the needle for each of them?
- Confidence — how sure are you about your Reach and Impact estimates?
- Effort — how much work will it take to ship?
Run those four numbers through a simple formula and you get a single, comparable score for every item in your backlog — which means "the SSO request" and "the onboarding fix" can finally be judged on the same scale instead of on whichever one feels more urgent today.
RICE won't tell you which features to build. It will tell you which ones deserve the conversation first — and that alone eliminates most roadmap arguments before they start.
This post walks through the framework itself, how to build a working RICE tracker in Notion in about ten minutes, and — because every spreadsheet-based system eventually hits a wall — what to do when your backlog outgrows a table of rows and columns.
The Framework: Reach, Impact, Confidence, Effort
RICE was developed by Sean McBride on Intercom's growth team, who needed a way to compare wildly different project ideas against a single goal without the debate collapsing into opinion. Intercom published the framework publicly, and it's since become one of the most widely used prioritization models in product management, alongside frameworks like MoSCoW and Kano.
The formula is:
RICE Score = (Reach × Impact × Confidence) ÷ Effort
Here's what each input actually measures, and how Intercom's own team scores it:
Reach — the number of people or accounts a feature will affect within a fixed time window (per month or per quarter is typical). This should be an actual number, not a vibe: "active users who hit this screen in the last 30 days," not "a lot of people." Reach keeps you honest about niche requests that feel loud but touch almost no one.
Impact — how much the feature moves your target metric for each person it reaches. Because impact is inherently fuzzy, Intercom uses a non-linear multiple-choice scale rather than an open number:
| Impact level | Score |
|---|---|
| Massive impact | 3 |
| High impact | 2 |
| Medium impact | 1 |
| Low impact | 0.5 |
| Minimal impact | 0.25 |
The scale is deliberately non-linear — a "massive" win should be worth several "low" wins stacked together, not just double.
Confidence — a percentage that discounts your score based on how much evidence backs your Reach and Impact numbers. It's the safety valve that stops enthusiasm from masquerading as data:
| Confidence level | Percentage | Basis |
|---|---|---|
| High confidence | 100% | Quantitative data — usage numbers, test results |
| Medium confidence | 80% | Some qualitative support, not fully proven |
| Low confidence | 50% | Gut feeling, thin evidence |
If your confidence would score below 50%, Intercom's advice is blunt: don't bother scoring it yet — go get more data first.
Effort — the total person-time required, usually estimated in person-months, that includes not just engineering but design, QA, and any other function that has to touch the work. Effort is the denominator, so bigger effort actively drags the score down — which is exactly the point.
Put together, a feature reaching 500 users/month, with high impact (2), high confidence (100%), and one month of effort scores (500 × 2 × 1.0) ÷ 1 = 1000. A feature reaching only 50 users but requiring the same effort scores a tenth of that. The framework doesn't decide for you — but it makes the tradeoff impossible to ignore.
FAQs
Do all four RICE inputs need to be exact numbers?
No. Reach and Effort should be as concrete as you can make them (real user counts, real time estimates), but Impact and Confidence are intentionally scored on fixed scales rather than precise figures — the goal is a consistent, comparable estimate, not false precision.
Is RICE better than other prioritization frameworks like MoSCoW or Kano?
Not universally — it's better suited to comparing many disparate feature ideas against one goal using quantifiable estimates. MoSCoW works well for scoping a single release, and Kano is stronger for understanding customer delight versus expectation. Many teams use RICE for backlog-wide prioritization and a second framework for release-level scoping.
The Tutorial: Build a RICE Tracker in Notion in 10 Minutes
You don't need a template file to start using RICE today — you need a table with the right columns and a formula. Here's how to set it up from scratch in Notion:
- Create a new page and add a Table (database) view. Give it a name like "Feature Prioritization — RICE."
- Add these columns:
Feature(Title — the default column)Reach(Number)Impact(Select, with options: 3 – Massive, 2 – High, 1 – Medium, 0.5 – Low, 0.25 – Minimal)Confidence(Select, with options: 100% – High, 80% – Medium, 50% – Low)Effort(Number, in person-months)RICE Score(Formula)Status(Select: Backlog, Considering, Planned, Shipped)
- Set up the Impact and Confidence selects to output numbers. Since Notion Select options are text, you'll reference them inside the formula rather than doing math directly on the select value — see the formula below.
- Write the RICE Score formula. In the formula field, something like this works (adjust option names to match exactly what you typed in step 2):
(prop("Reach") * if(prop("Impact") == "3 - Massive", 3, if(prop("Impact") == "2 - High", 2, if(prop("Impact") == "1 - Medium", 1, if(prop("Impact") == "0.5 - Low", 0.5, 0.25)))) * if(prop("Confidence") == "100% - High", 1, if(prop("Confidence") == "80% - Medium", 0.8, 0.5)) ) / prop("Effort")
- Sort the table view by RICE Score, descending. This is the whole point — the highest-scoring ideas now float to the top automatically as you add or edit rows.
- Add a Board view grouped by Status so you can drag features from Backlog into Planned once they clear a score threshold your team agrees on.
That's the entire template. It takes longer to read this paragraph than to build it — and because you built it yourself, you understand every formula in it, which matters the first time a teammate asks "wait, why did this one score higher?"
Tip: seed the table with 5-10 real requests from your backlog before your next planning meeting. Scoring real ideas together, out loud, does more to align a team than any framework explanation.
FAQs
Can I use a spreadsheet like Google Sheets instead of Notion?
Yes — the same columns and formula logic (Reach × Impact × Confidence ÷ Effort) work identically in Sheets or Excel using lookup tables for the Impact and Confidence scales. Notion is a common choice because product teams often already keep specs and docs there, but the underlying method isn't Notion-specific.
What Effort unit should I use if my team is small?
Person-months is standard, but for smaller teams person-weeks or even person-days often produce more useful granularity — as long as you use the same unit for every feature in the table, the relative scores still work.
Worked Example: Scoring Four Real Feature Requests
Numbers are easier to trust once you've seen them applied. Here's a sample backlog for a mid-size SaaS product, scored side by side:
| Feature | Reach (users/mo) | Impact | Confidence | Effort (person-months) | RICE Score |
|---|---|---|---|---|---|
| Dark mode | 1,200 | 0.5 (Low) | 100% | 0.5 | 1,200 |
| SSO / SAML login | 80 | 2 (High) | 80% | 2 | 64 |
| In-app onboarding checklist | 900 | 1 (Medium) | 80% | 1 | 720 |
| Bulk CSV export | 300 | 1 (Medium) | 50% | 0.5 | 300 |
A few things this table makes visible that a gut-feel debate never would:
- Dark mode edges out the onboarding checklist purely because it's so cheap to ship, even though its per-user impact is low. That's a legitimate quick win — not a distraction, as some teams instinctively assume.
- SSO scores lowest, despite being a common enterprise ask, because it reaches relatively few accounts and takes real engineering time. That doesn't mean don't build it — it might be a hard requirement to close a specific enterprise deal, which RICE doesn't capture on its own. It means: don't let SSO block your whole roadmap just because it's the loudest request in the room.
- CSV export's low confidence (50%) pulls its score down even though Reach and Impact look decent — a reminder that untested assumptions should cost you something in the ranking.
RICE scores are inputs to a prioritization conversation, not a verdict. A low-scoring feature tied to a strategic partnership or a compliance requirement can still jump the queue — RICE just makes sure that decision is made consciously, not by default.
Run your own backlog through the same table and you'll usually find at least one surprise — a request everyone assumed was top priority slips, and a cheap, boring fix rises.
Common Mistakes Teams Make with RICE
RICE is simple to learn and easy to misuse. The most frequent failure modes:
- Guessing Reach instead of measuring it. "A lot of users" is not a Reach number. If you don't have analytics to back it up, that's a signal to lower your Confidence score, not to invent a Reach figure that feels right.
- Treating Impact as a straight multiplier of team enthusiasm. Impact should reflect the effect on the metric you actually care about (activation, retention, revenue), not how excited the team is to build it.
- Skipping Confidence entirely by always scoring 100%. This defeats the entire purpose of the framework — Confidence exists specifically to punish untested assumptions.
- Underestimating Effort by only counting engineering time. Design, QA, docs, and support enablement are real effort too, and leaving them out systematically inflates scores for anything involving other functions.
- Treating the score as final rather than as a ranking aid. RICE compresses four dimensions into one number; it will never capture strategic bets, competitive pressure, or a single enterprise deal riding on one feature. Use it to sort your options, then apply judgment on top.
The fix for most of these is the same: score as a team, out loud, with the reasoning for each number written next to it. A RICE score without a rationale is just a made-up number with extra steps.
The Evolution: Why Spreadsheets Eventually Break
A Notion table is genuinely the right tool for RICE scoring when you're a small team with a backlog you can hold in your head. It breaks down in a handful of predictable ways as a product and its user base grow:
- Reach becomes a guess again. Early on you can eyeball "about 1,200 users hit this flow." Once you have thousands of users across multiple plans, segments, and use cases, an accurate Reach number requires real usage data — which a static table can't pull in on its own.
- The requests stop being internal. RICE works cleanly when your inputs come from your own team's judgment. It gets harder the moment feature requests start arriving directly from customers — each with their own upvotes, comments, and urgency — because now Reach and Impact are things your users are telling you, not things you're estimating alone in a doc.
- Nobody outside the core team can see the backlog. A Notion database is easy to lose track of. Customers who asked for a feature six months ago have no way to check if it's been scored, planned, or shipped — so they ask again, in a different channel, and your Reach data fragments across Slack, email, and support tickets.
- Duplicate requests silently inflate or deflate scores. Three customers asking for the same thing in three different words looks like three separate low-Reach ideas instead of one high-Reach one, unless someone manually merges them.
This is the point where dedicated feedback and roadmapping software earns its keep. UpVote — an embeddable feedback widget and public voting board — solves the exact gap a spreadsheet can't: customers submit and upvote feature requests directly, so Reach is no longer an estimate, it's a real vote count you can see updating in real time. Duplicate ideas get merged instead of double-counted, your team can layer effort and impact scoring on top of that real demand signal, and the roadmap itself is visible to the customers who asked for it — closing the loop instead of leaving requests to rot in a Notion page only your team can see.
You don't need to migrate the day you build your first RICE tracker. But once "how many people actually want this" stops being something you can estimate from memory, that's the signal it's time to let your users answer the Reach question directly instead of guessing on their behalf.
FAQs
At what team or user size does a spreadsheet stop working for prioritization?
There's no fixed number — the signal is qualitative, not quantitative. It's usually when you can no longer confidently estimate Reach from memory, when the same request starts arriving through multiple untracked channels, or when customers start asking about the status of something they requested and nobody has a clean answer.
Does using UpVote mean we stop using the RICE framework?
No — RICE is a scoring method, not a piece of software, and it works just as well on top of real vote and comment data as it does on top of guesses. The framework doesn't change; what changes is where your Reach and Impact evidence comes from.
Getting Started This Week
You don't need to overhaul your process to start using RICE. A practical rollout looks like this:
- Build the Notion table from the steps above — ten minutes, no dependencies.
- Pick 10-15 real backlog items and score them as a team in one sitting. Expect disagreement on Impact and Confidence — that disagreement is useful, not a problem to route around.
- Sort by score and sanity-check the top five. If the ranking feels obviously wrong, that usually means an Effort or Reach number was guessed rather than measured — go fix the input, not the score.
- Revisit scores monthly, not once and never again. Reach and Effort estimates go stale as usage patterns shift and as you learn more about what a feature actually takes to build.
- Watch for the spreadsheet's limits described above. When Reach stops being something you can estimate and starts being something your customers should be telling you directly, that's the cue to look at dedicated tooling.
RICE won't make prioritization painless — nothing does, because prioritization is fundamentally about saying no to good ideas in favor of better ones. What it will do is make every "no" defensible, consistent, and fast to explain the next time someone asks why their favorite feature isn't next on the roadmap.