Prioritizing Customer Feedback: RICE vs. Impact-Effort

A backlog has no inherent order. You have to give it one you can defend.

Picture a common situation. This is a hypothetical, not a real backlog: fifty open requests, a few from your loudest customer, one that sounds urgent, and a planning meeting this week. Prioritization is the step that turns that pile into an order you can defend. This guide covers two scoring methods that work for small product teams: RICE and impact-effort. It defines every input, works three examples end to end, and gives you a spreadsheet to run your own.

If you are still collecting the feedback in the first place, start with our guide to website feedback widgets or the comparison of reaction widgets vs. feedback forms.

Prioritization is not triage

These two jobs get merged by accident. Keep them apart.

Triage answers: does this need a human right now? A broken checkout, a data-loss report, or a login outage is an incident. It does not get a score. It gets an owner and a response today.

Prioritization answers: of the feature work worth doing, what should we build next? This is scored, comparative, and slow by design.

Savio's guide to triaging customer feedback frames triage around three questions: can you imagine solving this one day, does the request make sense, and which feature request it connects to. Two of those steps, asking for clarification and linking feedback to a feature request, are the routing layer. Once a request survives triage and is linked, it enters the scored backlog this article is about.

So the first rule: pull incidents out before you score anything. A score applied to a production outage hides the outage behind an average.

Pick one horizon and keep it

Every scoring method compares things over a time window. RICE calls this "reach per period." Choose one period and use it for every row in a given comparison.

Pick a quarter. Or a month. Do not mix them. A reach of 40 users per month and a reach of 40 users per quarter describe the same number and completely different value. The most common scoring mistake is not bad arithmetic. It is an inconsistent horizon between row one and row four.

Write the horizon at the top of your sheet. Something like: "Reach = users affected per quarter, next 90 days." Now every reader knows what the numbers mean.

RICE: reach, impact, confidence, effort

RICE scores each item on four factors and combines them into one number. Intercom developed the model to improve its own roadmap decisions, and ProductPlan documents it in their RICE scoring model glossary entry. The method is well documented and free to use; credit goes to Intercom.

The four factors:

Reach: how many users this affects in your chosen period. This is a count, not a rating. "40 users per quarter," not "4 out of 5."
Impact: how much this moves the goal for each user who touches it. Intercom's scale is 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal).
Confidence: how sure you are about the other three numbers. Intercom's tiers are 100% (high), 80% (medium), 50% (low). Below 50% is a moonshot, not a priority.
Effort: the cost to ship, measured in person-months across design, engineering, and testing. Anything under a month, score as 0.5.

The formula:

RICE = (Reach × Impact × Confidence) / Effort

Reach, impact, and confidence multiply into the numerator. Effort divides. A feature that reaches many people, matters a lot, and is cheap to build wins. Confidence keeps a guess from scoring as if it were a fact.

The confidence field is the one teams skip. Do not skip it. If reach is a real number and impact is a hunch, confidence is where you say so.

Three worked rows

The three items below are fictional and illustrative. They are not real customer records. They all use one horizon: reach measured per quarter.

Feature	Reach	Impact	Confidence	Effort	RICE
Bulk-edit selected feedback rows	50	1	0.8	1.0	40.0
Saved views per team member	30	2	0.5	3.0	10.0
Native CSV export of the current filter	80	0.5	1.0	2.0	20.0

Show the arithmetic, so nobody has to trust the total:

Bulk-edit: (50 × 1 × 0.8) / 1.0 = 40.0 / 1.0 = 40.0
Saved views: (30 × 2 × 0.5) / 3.0 = 30.0 / 3.0 = 10.0
CSV export: (80 × 0.5 × 1.0) / 2.0 = 40.0 / 2.0 = 20.0

Ranked: bulk-edit (40.0), CSV export (20.0), saved views (10.0).

Read that again, because it is the point of the whole method. The CSV export reaches the most users, 80 against 50. Its reach is the highest. It still loses, because its impact per user is low (0.5) and its effort is higher (2.0 person-months). Raw reach is not a priority. Reach times confidence divided by effort is.

The saved views row is the other lesson. It has the highest impact, 2. But reach is lower and confidence is only 50%, and effort is the largest at 3.0 person-months. It lands last. High impact on a small, uncertain group is not a top priority yet.

What RICE is bad at

RICE produces a number that looks objective. It is not. Every input is an estimate. Two people scoring the same item will disagree on impact and effort, and both are "right."

Treat the score as a ranking aid, not a verdict. When two items land within a few points of each other, the score has told you everything it can. Decide those by judgment.

Impact-effort: when a matrix beats a score

RICE is overkill for a short list. If you have fewer than ten candidate items and no time to debate reach and confidence, an impact-effort matrix is faster and honest about its roughness.

Score two things, each on a 1-5 scale. Fix the anchors before you start so two people score the same item the same way.

Impact: how much value this creates for users if shipped. 1 = marginal, 3 = a noticeable improvement for the users who touch it, 5 = changes whether they keep using the product.
Effort: how much work to build. 1 = under a day, 2 = a few days, 3 = about a week, 4 = a few weeks, 5 = a month or more of team time.

Set a cutoff for high and low. One simple rule: impact 3 or higher is high, below 3 is low; effort 3 or higher is high, below 3 is low. Then place each item in one of four quadrants.

High impact, low effort (quick wins): do these next.
High impact, high effort (big bets): plan these; they need a real slot.
Low impact, low effort (fill-ins): do these when a slot opens.
Low impact, high effort (time sinks): say no, or defer without guilt.

The scales are a rough judgment, not a precise measurement. The cutoff makes the labels reproducible for a given team; it does not make the inputs objective. The quadrant label comes from the cutoff, not from the ratio below.

Same three fictional items, scored on this scale:

Feature	Impact (1-5)	Effort (1-5)	Quadrant
Bulk-edit selected feedback rows	3	2	Quick win
Saved views per team member	4	4	Big bet
Native CSV export of the current filter	2	2	Fill-in

Impact divided by effort gives a rough ratio: 1.50, 1.00, and 1.00. The bulk-edit item still leads, which is a useful cross-check: both methods agreed on the top item here. When two methods disagree, that is your signal to slow down and ask why.

Confidence fits here too, as a multiplier or a separate risk column. A big bet at low confidence is a research task, not a build task.

Which method to use

Use RICE when you have more than about ten items, when reach can be estimated from real usage data, and when you need to defend the order to stakeholders who were not in the room.
Use impact-effort when the list is short, the team is small, and speed matters more than precision.
Use both when the stakes are high. Score with RICE, spot-check the top of the list with a matrix. Where they agree, move on. Where they disagree, that item needs a conversation, not a number.

Do not run both on everything. That doubles the busywork for no added signal.

The scoring spreadsheet

The workbook below has two sheets: one for RICE and one for impact-effort. It ships with the three fictional rows above already filled in, plus blank rows. The blank rows carry formulas that stay empty until you enter a value in every input cell, so they never show errors.

RICE sheet columns: feature, reach, impact, confidence, effort, rice_score, notes.
The rice_score column holds the formula, not a typed number, so editing any input recalculates the score.
The impact-effort sheet holds feature, impact, effort, and a quadrant column you assign by hand from the cutoff rule above; the sheet's formula only computes the impact/effort ratio.

Download it and replace the fictional rows with your own:

Download prioritization workbook (Excel)

If you prefer plain text, a static-value mirror of the same rows is here: Download prioritization data (CSV). The CSV stores numbers only; it does not recalculate. To rebuild the score in the XLSX RICE sheet, use:

=IF(AND(ISNUMBER(B2),ISNUMBER(C2),ISNUMBER(D2),ISNUMBER(E2),E2<>0),(B2*C2*D2)/E2,"")

with reach in column B, impact in C, confidence as a decimal in D, and effort in E. The XLSX blank rows already carry this formula, so an unused row stays blank instead of showing an error. To rebuild the score in the CSV layout instead, note the RICE rows put reach in column C, impact in D, confidence in E, and effort in F, so the equivalent formula there is =(C2*D2*E2)/F2.

Two columns in this sheet are ours, not a product feature. An owner column and a priority column belong to your team's process. The spreadsheet is where you keep them.

A weekly prioritization pass

A short weekly pass keeps the order current. Run it in this order.

Clear the incident lane first. Anything that is broken in production leaves the scored backlog and gets an owner.
Bring in new items. Each new request that survived triage gets a row. Do not score it yet.
Re-check the horizon. Confirm every reach number still means the same period.
Score the new rows. Fill reach, impact, confidence, and effort. Let the formula compute the total.
Sort and look for movement. An item that jumped into the top three is a decision for the next planning slot.
Write one sentence per top item. Why is it here? That sentence is what you bring to the roadmap meeting.

If you use FeedValue to collect the feedback, the dashboard already gives you the raw inputs this pass needs. The FeedValue feedback documentation describes a submission as carrying an AI category (bug_report, feature_request, praise, complaint, question, or general), an AI sentiment (positive, neutral, negative), a status (new, read, resolved, archived), and the source URL, browser, device, and any custom fields you configured. Categorized feedback tells you where your requests are coming from; it does not rank them for you. The scoring in this article is your process, applied by hand or in the sheet.

The statuses are also a rough audit signal. The FeedValue feedback documentation lists new as "just submitted, not yet reviewed" and read as "viewed by a team member." A request that still shows new long after it arrived may mean it never entered triage, but the status alone does not prove whether a separate scoring step happened. Treat it as a prompt to look, not a verdict.

Start scoring, not guessing

A ranking you can defend beats a gut feeling you can't. Pick a horizon, score the next ten items, and let the top of the list change your mind when the numbers say so.

You can collect the feedback these scores are built on with one script tag. Create a free FeedValue account and see responses land in a dashboard with categories, sentiment, and status on every submission.

Keep reading

Set up a feedback tracker — a spreadsheet with fields for owner, status, duplicates, and next action.
Categorize customer feedback — six categories, sentiment, and human priority.
Write feedback widget copy — ready-to-copy prompt and label pairs.
Close the feedback loop — acknowledgement, decision, and follow-up.

Templates you can use today: the feature request template, feedback checklist, feedback emails, and meeting agenda.

Prioritizing customer feedback: RICE vs. impact-effort