To use RICE prioritization, compare initiatives against one goal, measure reach over the same period, estimate impact and confidence, then divide by total team effort. The arithmetic is straightforward. The useful work is deciding which assumptions deserve the numbers and which constraints override the ranking.
This example follows an equipment-rental service choosing its next improvement to the journey from reservation to pickup. It produces a short, defensible order of work rather than a list of scores that nobody trusts. Use it alongside your product roadmap planning: the score informs a decision; the roadmap explains the intended outcome and sequence.
Start with the formula and consistent units
RICE stands for reach, impact, confidence and effort. The formula is (reach × impact × confidence) ÷ effort. Enter confidence as a fraction: 80% becomes 0.8.
In Intercom's original RICE method, reach counts affected people or events within a fixed period; impact uses a shared relative scale; confidence discounts uncertain estimates; and effort covers work across the team. Its suggested impact scale is 3, 2, 1, 0.5 and 0.25, with confidence levels of 100%, 80% and 50%. The method also allows dependencies and essential work to take precedence over score order.
Before entering numbers, write a one-line comparison rule. For this example: Compare improvements that help existing renters complete an equipment rental from reservation through pickup during the next quarter. Reach means distinct renter accounts exposed to the change, not page views. Effort means person-months across product, design and engineering, not calendar months. Use the same outcome when judging impact: a completed pickup, whether the improvement removes a reservation obstacle or a later collection obstacle.
This rule excludes an unrelated acquisition campaign. It also prevents an initiative with 20,000 impressions from being compared directly with one used by 400 customers. If a proposal serves a different goal, assess it in a separate decision rather than making the figures look comparable.
A worked RICE example with three initiatives
The following figures are hypothetical planning inputs. They show how a team could reason about the rental journey; they are not Mockitt customer results or predicted conversion lifts.
| Initiative | Reach per quarter | Impact | Confidence | Effort | Score |
|---|---|---|---|---|---|
| Reuse saved renter details | 1,200 accounts | 2 | 80% | 2.5 person-months | 768 |
| Show an availability calendar | 800 accounts | 2 | 50% | 4 person-months | 200 |
| Send clearer pickup reminders | 600 accounts | 0.5 | 100% | 1 person-month | 300 |
The first calculation is 1,200 × 2 × 0.8 ÷ 2.5 = 768. Saved details ranks above reminders, which ranks above the availability calendar. That is the initial order, before examining constraints and uncertainty.
For a team discussion, put the three initiative cards beside one another on a shared design canvas, with the inputs and evidence notes visible. The example below is a manually arranged planning artifact; the scores come from the calculation above.
Each row still needs an evidence note. The team might obtain saved-details reach from accounts that repeatedly enter the same information. The calendar estimate might come from visits to unavailable items, but that does not establish how many customers would finish a reservation if a calendar existed. A high-confidence reach estimate can coexist with a weak impact estimate.
Effort also needs a scope boundary. “Saved details” could mean prefilled name and contact information, or a larger identity-verification project. These are different proposals. Score the smallest coherent version that creates the intended outcome, and explicitly list work left outside it.
Make the evidence visible before debating the score
For each initiative, retain the observation, its source and the assumption connecting it to the outcome. This prevents an attractive number from concealing a weak causal story.
- Saved details: returning renters repeat contact fields. The assumption is that repetition contributes to abandonment, rather than the price or deposit shown later.
- Availability calendar: renters encounter unavailable items. The assumption is that alternative dates are useful; some renters may need equipment for one fixed event.
- Pickup reminders: customers ask support where and when to collect equipment. The assumption is that clearer instructions improve completion of the reservation journey.
A support request is evidence of a problem, not a reach count on its own. Ten messages from one renter do not represent ten affected accounts. Equally, silence does not establish that the rest of the audience has no difficulty. Combine qualitative evidence with the measurement relevant to your chosen unit.
If requests are still duplicated or mixed with bugs, complete feature-request triage before scoring. Prioritizing three differently worded versions of the same problem makes the list longer without creating more choices.
Use a prototype to investigate the uncertain claim
The top-scoring initiative should not jump straight from a spreadsheet to implementation. For saved renter details, sketch the current form, a prefilled version and a review screen. A renter must be able to notice outdated information and correct it before confirming the reservation.
In Mockitt's interactive prototype editor, the team can represent those screens and the edit-and-return path. Keep the example focused on the assumption being investigated: whether people understand the reused information and can fix it. The prototype does not verify identity storage, security or the production checkout backend.
Use a task such as: “Reserve the drill for Friday. Your phone number has changed since your last rental.” Observe where the participant looks, whether they notice the old number, and whether they return to the reservation after editing. Do not announce that saved details is the new feature being evaluated.
A successful walkthrough can reduce uncertainty about comprehension and the correction path. It cannot establish the eventual conversion lift or the number of accounts reached. Update only the estimates supported by the new evidence. If the test exposes confusing review behavior, change the design before giving the initiative a stronger confidence score.
Check what would change the ranking
A single score hides a range of plausible estimates. Use a small sensitivity check instead of adding decimal places to weak inputs.
If the availability calendar's confidence rises from 50% to 80% while effort stays at four person-months, its score becomes 320. It passes reminders but remains below saved details. If a technical investigation also reduces calendar effort to two person-months, the score becomes 640. The initiative is now closer to the leader, but still not automatically first.
Conversely, suppose the saved-details proposal grows from 2.5 to five person-months because it requires account recovery and verification work. Its score falls from 768 to 384. The result is a reason to revisit scope, not to hide the new effort estimate.
Ask one practical question: What uncertainty could reverse our next decision? Investigate that uncertainty first. There is little value in refining the reach estimate for a low-ranked option when even a generous estimate would leave it far behind the current choice.
Separate score order from delivery order
A high score does not cancel dependencies, accessibility defects or necessary operational work. If saved details depends on fixing a broken account lookup, record that dependency and include its effort in the decision. Do not rank the prerequisite as an optional standalone feature and then forget it.
Some work does not belong in this comparison at all. An urgent production failure needs its incident process. A committed contractual requirement needs an explicit delivery decision. Label these reasons clearly rather than awarding an artificial impact score high enough to force the desired result.
A useful decision record might read: “Start saved renter details after account-lookup repair. Validate the correction flow before development. Investigate calendar feasibility this quarter; do not commit to the full calendar yet.” This preserves what the team learned from the scores and what it deliberately chose outside them.
Turn the ranking into a releasable slice
Assign an owner, an outcome to observe and a review point to the chosen initiative. For saved details, the first slice could cover returning renters with an existing verified account, with editing and a clear fallback when details cannot be retrieved. Guest checkout remains available rather than becoming an accidental casualty of the change.
A user story map of the first release helps expose missing steps that the scoring row cannot show. A feature that prepopulates fields but prevents correction is not a complete slice.
After release, compare the observed behavior with the assumptions recorded before it. Investigate a weak result: perhaps the issue was price, the audience definition was wrong, or the implementation introduced a new obstacle. RICE is most useful when the team learns which estimates were wrong, then carries that learning into its next decision.