How to use RICE to prioritize customer feedback
RICE scores a request as reach times impact times confidence, divided by effort. With customer feedback, reach is the number of distinct customers who asked in a fixed period. Use the score to rank features, not to replace judgment.
By Rafael Thayto · Last updated
What RICE means for feedback
RICE is a scoring model with four inputs: Reach, Impact, Confidence and Effort. You multiply the first three, then divide by effort. The result is one number you can sort by, so a long list of requests becomes a ranked list you can defend in a planning meeting.
Customer feedback fits RICE well because part of the input already sits in your inbox. Reach is how many people asked, and confidence is how much evidence you have behind the impact estimate. You still estimate impact and effort yourself.
The formula, written out: RICE score = (Reach x Impact x Confidence) / Effort
Count reach from distinct customers
Reach is the number of distinct customers who would hit the problem in a set period. Pick the period first, for example the last 90 days, and use it for every request so the scores compare.
Count people, not messages. One customer who sends the same request three times counts once. If your items carry an email or an ID, sort by that field in a spreadsheet and count the unique values. If feedback is anonymous, count each message as one person and say so in your notes. The result is then a ceiling, not an exact count.
Reach can also cover people who never wrote. Two customers asking for a change may stand for twenty people who hit the same wall and left quietly. Check your analytics or support tickets when you have them, and adjust the reach number with a note that explains the adjustment.
Score impact and confidence honestly
Impact is how much the change moves your goal for each person it reaches. Use a short scale and write it down before you score anything:
- 3 for massive: the customer cannot finish their work without it.
- 2 for high: a clear, repeated gain in daily use.
- 1 for medium: a noticeable improvement.
- 0.5 for low: a pleasant touch.
- 0.25 for minimal: a cosmetic change.
Confidence measures how much evidence supports your reach and impact numbers. Use 1.0 when you watched several customers struggle with the problem, 0.8 when you have consistent written feedback, and 0.5 when you are mostly guessing. Low confidence is honest, and it lowers the score, which is the point.
Effort is the team time needed to ship the change. Ask the engineer who would build it, and round to the nearest half week. Write the estimate next to the request so the next review starts from the same assumption.
Work through an example
The numbers below are invented for illustration. Your reach counts will come from your own inbox.
| Request | Reach (last 90 days) | Impact | Confidence | Effort (weeks) | Score |
|---|---|---|---|---|---|
| Export to Google Sheets directly | 6 | 2 | 0.5 | 1 | 6.0 |
| Fix slow loading on the invoice page | 3 | 3 | 1.0 | 3 | 3.0 |
| Dark mode for the dashboard | 14 | 0.5 | 0.8 | 2 | 2.8 |
The export row is 6 x 2 x 0.5 = 6, divided by 1, so 6.0. The invoice row is 3 x 3 x 1.0 = 9, divided by 3, so 3.0. The dark mode row is 14 x 0.5 x 0.8 = 5.6, divided by 2, so 2.8.
The dark mode request has the most people behind it, yet it ranks last. That is the model working as intended: many people asked, but the gain per person is small and the team is unsure of it. The invoice page ranks second because each affected customer loses real work. Your ranking will look different, and that difference is the reason to run the model.
Where RICE misleads
RICE rewards whatever is easy to count. A customer who writes often can inflate reach if the rest of your base does not care. Compare the distinct count with the rest of the inbox before you trust a high number.
Bugs do not fit the model well. A crash that blocks checkout has a small reach in the inbox and a huge impact. Score bugs by frequency and severity, as described in how to prioritize bugs by frequency and severity, and keep RICE for features and changes.
Effort estimates drift. Re-score the top ten requests every quarter, because a request that took two weeks last year may take one now, or the reverse.
Run RICE on your Escuta Produto inbox
Escuta Produto does not calculate RICE, and it has no tags for grouping requests. You do the counting with the tools it does have:
- Filter the product inbox to type idea, then search for the words customers use for one request.
- Read each match and note the distinct customers in an internal note on the item, with the date you counted.
- Export the product's feedback as CSV and copy the reach counts into a sheet with one row per request.
- Add impact, confidence and effort columns, then sort by the score.
Reach counts are easier to trust when every item carries an email. The identify call that fills that field is described in the widget docs.
Keep the reach numbers in the same sheet each week so the trend stays visible. For the spreadsheet steps, read how to analyze customer feedback in a spreadsheet. For what happens after the ranking, read how to turn customer feedback into a roadmap.
Frequently asked questions
What does RICE stand for?
RICE stands for Reach, Impact, Confidence and Effort. You multiply reach, impact and confidence, then divide by effort. A higher score means the request ranks higher in the planning discussion.
How do you measure reach from customer feedback?
Count the distinct customers who asked for the same thing within a fixed period, such as the last 90 days. Count people rather than messages, and use the same period for every request so the scores can be compared.
Is RICE better than sorting requests by how many there are?
Usually, yes. Counting requests ignores how much each person gains and how sure you are about it. RICE adds impact, confidence and effort, so a small request from many people does not automatically outrank a high-impact change.
Related
- How to triage customer feedbackA weekly routine for turning raw customer feedback into decisions: statuses, tagging by type, spotting patterns and closing the loop with customers.
- How to apply the Kano model to feature requestsUse the Kano model to sort feature requests into basic, performance, delighter and other groups, and learn when the model stops being useful.
- Prioritize bugs by frequency and severityRank bugs by how often customers hit them and how much damage they cause. A 2x2 grid, a frequency count from feedback and clear rules for what goes first.
- How to build a tagging system for customer feedbackEscuta Produto has no tags, so build a small, stable set of areas in metadata and notes. Define each label, review the list quarterly and keep it short.