RICE Prioritisation with Votes and Revenue: A Worked Example

RICE is the prioritisation framework people reach for when a backlog gets too long to sort by feel. It gives every request a score, and the score is easy to explain. The catch is that two of its four inputs are judgement calls. This guide shows how to anchor them in data you can collect from your own users: votes for reach, and the revenue behind each request to inform impact.

The example uses Trailmate, a fictional hiking app, and five of its open requests. For how RICE compares with other approaches, see the overview of prioritisation frameworks.

The short version

• RICE score = Reach × Impact × Confidence ÷ Effort.
• Use votes in a fixed period as reach. Merge duplicates before you count.
• Set impact from what the feature does for users, then adjust it using revenue per voter. Do not use total MRR as impact, because it already contains reach.
• Small, certain work tends to win. When a big request loses, try scoping it down before you drop it.

Where RICE comes from

RICE was developed at Intercom. Sean McBride described it in RICE: Simple prioritization for product managers, and the scales below are the ones from that article:

• Reach: how many people the feature affects in a period, such as customers per quarter.
• Impact: how much it moves the needle for each of them: 3 for massive, 2 high, 1 medium, 0.5 low, 0.25 minimal.
• Confidence: how sure you are of the other numbers: 100% high, 80% medium, 50% low.
• Effort: person-months of work across design, engineering and everyone else involved.

The result reads as impact delivered per unit of work. Higher is better.

Reach: start from votes

Votes are the closest thing most app teams have to a measured reach. A vote is a user telling you, in your own app, that a request affects them. Use the same window for every request, for example votes in the last quarter, so an old request does not win on age alone.

Three cautions apply:

• Votes are a sample. Many users never vote. That is fine for ranking, because you are comparing requests with each other rather than predicting an exact audience.
• Duplicates split the count. "Offline maps", "Download trails" and "Maps without signal" are one request. Merge them so each voter is counted once.
• Keep units consistent. If one request's reach is votes, all of them must be votes. Do not mix in estimates from other sources for a few of them.

Impact: let revenue inform it

Impact is the input most likely to be pure opinion. Revenue gives it something to push against. If your app records each user's monthly recurring revenue (MRR), you can see how much MRR sits behind each request.

Here is the trap: total MRR grows with the number of voters. If you use it to set impact, you count reach twice, and popular requests win by a landslide. Divide instead. Revenue per voter tells you how valuable the people asking are, independent of how many of them there are.

A simple method:

1. Set a base impact from what the feature does for the user, on the Intercom scale.
2. Work out the average MRR per voter across the requests you are scoring.
3. Move impact up one step if a request's MRR per voter is well above the average, and down one step if it is well below.

Trailmate's five requests have 561 votes and $9,930 of MRR behind them, an average of $17.70 per voter.

Offline maps starts at 3 because a map that fails without signal fails at the moment a hiker needs it most. The filter and the elevation profile start at medium, and move up because the people asking for them pay more than average. Sharing a hike moves down: lots of free users want it, which may matter for growth, but RICE is not the place to hide a growth bet. Score that separately.

Confidence and effort

Confidence is about the evidence for your reach, impact and effort numbers. Trailmate gives the elevation profile 100% because the trail data already includes elevation and the design is simple. Offline maps gets 80%, because the scope is large and download sizes are still unknown. Share a hike gets 50%: nobody is sure what "share" should mean.

Effort comes from the people building it, in person-months. Trailmate's estimates: offline maps 4, difficulty filter 1, elevation profile 1, share a hike 0.5, trail notes 2 (notes need syncing and storage on the device).

The worked table

Reading the result

The most-voted request comes third. That is not a bug in RICE. It is RICE doing its job: the filter and the elevation profile together take half the effort of offline maps and score more than twice as much.

Before you accept that, test the big one. Offline maps scored low because of its effort and its uncertainty. If Trailmate scopes it down to saved trails, leaving whole-region downloads for later, the estimate falls to 3 person-months and confidence rises to 100%. The score becomes 248 × 3 × 1.0 ÷ 3 = 248, and it moves to the top. Scoping is how big requests survive RICE, and the MoSCoW guide shows how to cut that scope for a single release.

A second check is to score with revenue as reach. Use MRR behind each request as reach and the base impact, before the revenue adjustment, so revenue is not counted twice. Offline maps scores 2,472, the filter 2,296 and the elevation profile 1,940. The top three are the same requests, in a slightly different order. When two reasonable versions agree on the top three, you can trust the shortlist. When they disagree on the order, that is the conversation to have as a team.

Common mistakes

• Treating the score as precise. 209.6 and 174 are close. Scores tell you which group a request belongs to, not a strict order.
• Inflating confidence. If you have not talked to a user or looked at the code, confidence is 50%.
• Forgetting effort beyond engineering. Design, testing, App Store review and support all count.
• Scoring once. Votes and revenue change every week. Re-score the top of the list before each planning cycle.

If you want a faster, more visual pass at the same backlog, the impact/effort matrix uses the same inputs on a two-by-two grid.

How FeedbackKit fits in

FeedbackKit gives you the two numbers RICE needs from users. Your users vote and comment on requests inside your app through the Swift SDK, and a new request starts with its submitter's vote. On every plan, your app passes each user's MRR through the SDK, and in the native admin apps for iPhone, iPad and Mac you can sort requests by the total MRR of the users behind them. Merge duplicate requests and each voter is counted once, so reach is not split.

When the scores are in, the statuses record the decision: Pending, Approved, In Progress, TestFlight, Completed and Rejected. Voting stops at Completed and Rejected. On Pro and up, an approved request can go to an issue tracker such as GitHub or Linear (see integrations and pricing).

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

RICE is worth the effort when its inputs come from real users rather than a meeting room. To collect votes and revenue against every request in your own app, start free.