RICE Scoring Model: How to Prioritize Features With Feedback

Author: Inputly

What is the RICE scoring model?

RICE is a prioritization framework that turns every idea in your backlog into one comparable number. You estimate four inputs, reach, impact, confidence and effort, multiply the first three and divide by the fourth, then rank the list by the result. The whole formula is:

RICE = (Reach x Impact x Confidence) / Effort

RICE does not tell you what customers want. That comes from product feedback collected in interviews, surveys and votes. RICE answers the second question, which is what to do first once you already have a list of things people asked for and can only build some of them.

How is a RICE score calculated?

| Input | What it measures | How teams usually scale it | | --- | --- | --- | | Reach | How many people the idea affects in a fixed window | Users per quarter | | Impact | How much it moves one metric for each of those people | 3 huge, 2 high, 1 medium, 0.5 low | | Confidence | How strong the evidence behind reach and impact is | 100, 80, 50 percent | | Effort | Work to ship it and keep it running | Person-months |

Two habits make the output usable. First, freeze the window: reach per quarter, effort per person-month, so you are never comparing a weekly number with a monthly one. Second, use the same scale for every item, because a score only means something next to the other scores in the same list.

Here is a small worked example with invented inputs, to show the arithmetic rather than to suggest what your numbers should be:

| Idea | Reach | Impact | Confidence | Effort | Score | | --- | --- | --- | --- | --- | --- | | Saved views for power users | 60 | 2 | 100% | 1 | 120 | | Bulk export | 300 | 1 | 80% | 3 | 80 | | Mobile push alerts | 400 | 0.5 | 50% | 4 | 25 |

The idea with the smallest reach wins, because the evidence behind it is complete and the cost is low.

Where should each number come from?

• Reach from your own analytics, not from ambition. Count how many accounts performed the relevant action in the window, then discount for the share who would actually use the new thing.
• Impact from one metric you already report on, such as activation, retention or support tickets. Decide in advance which metric an idea has to move, otherwise impact becomes a mood.
• Confidence from the evidence you hold. A repeated pattern across many conversations and votes is high confidence. One passionate account and no data is low confidence.
• Effort from the engineers, and include maintenance, not just the first release. A feature that needs someone on call forever is more expensive than its build estimate suggests.

Confidence is the input teams fudge most, and it is the one that carries the most meaning, because it is the only input that describes how much you actually know.

Why does confidence change the ranking so much?

Take an idea with a reach of 300, an impact of 1 and an effort of 3. At full confidence it scores 100. At 50 percent confidence it scores 50 and drops below smaller, better-evidenced work. That is not a flaw, it is the point: RICE rewards knowing over wanting.

There are two honest ways to raise confidence. One is to gather evidence, with a quick pulse survey, a round of user interviews, or time on a feature voting board where customers rank requests themselves. The other is to cut the scope: a smaller version usually reaches fewer people but costs far less, and both changes push the score up. What does not work is nudging the percentage to make a favourite idea win. If the number moves for political reasons, the list stops being worth reading.

What are the most common RICE mistakes?

• Inflating reach with the total user base instead of the accounts the idea actually affects.
• Letting the loudest customer set impact, which is how feedback volume gets confused with feedback weight, the same trap that makes prioritizing feature requests hard.
• Ignoring maintenance in effort and then wondering why the roadmap slipped.
• Comparing scores across teams that used different scales, windows or units.
• Treating the number as the decision rather than a shortlist. The top five still deserve a conversation.
• Scoring a hundred items, which spends a week producing a ranking nobody reads.

How does RICE compare with other prioritization methods?

| Method | What it optimizes for | When to reach for it | | --- | --- | --- | | RICE | A defensible ranking across many ideas | Long backlog, several stakeholders | | Kano model | Classifying must-haves against delighters | When you need to know which of two feelings a feature creates | | Feature voting | Demand signals from customers | When you want users to rank requests and see the outcome | | Weighted value vs effort | A quick trade-off | Small teams, few items | | Fixed scope by deadline | Agreement on a release | Launches with an external date |

RICE and voting work well together: votes supply a reach and confidence input, RICE orders the result, and a public roadmap shows customers where their request landed. Without that last step, a scoring exercise looks like a black box to the people who asked.

When should you not use RICE?

Skip it when the answer is already obvious, which is most incidents, broken flows and anything regulated. Skip it during early product discovery, when you have too little evidence for confidence to mean anything and the honest move is to learn before scoring. And skip it when scoring becomes the game: if the session is longer than the decision it informs, pick the top few items, argue them properly, and use saying no as the other half of the process.

For the sessions worth running, keep the list short, score it live with product and engineering in the room, and write the assumptions next to every score, so a changed score always has a visible reason. Then build.

Frequently Asked Questions

1. Do I need a tool for RICE? No. A spreadsheet with five columns covers it. What matters is that the scores and the assumptions behind them live somewhere the whole team can see.
2. What if two ideas score the same? Break the tie by the cheaper item first, or by dependency, since shipping the smaller one often unlocks the larger one.
3. Can impact be negative? Some teams use a negative value for ideas that protect a metric, such as reducing noise. If you do this, say so in the notes, because a negative score reads as a bad idea to everyone else.
4. Does RICE work for internal or HR work? Yes, if reach means employees rather than customers. Use headcount per quarter, a pulse survey-style impact, and the same confidence rules.
5. How does it connect to what we ship? Scores feed the shortlist, the shortlist feeds the plan, and the plan should reach customers through a changelog so they can see their request move.

Score the backlog, then answer it in public. Collect requests, let customers vote and track what shipped on Inputly.