RICE & ICE calculator for backlog prioritization

RICE is a prioritization framework described by Sean McBride, a product manager at Intercom. The team needed a way to compare very different ideas — a new feature, a redesign, an integration — without arguing about whose idea mattered more. The score combines four estimates:

• Reach is a real number over a fixed period: “1,800 new users per quarter will see the tour”, “600 customers a month export reports”. Take it from analytics, not from memory.
• Impact uses Intercom’s multiple-choice scale: 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal. The scale is deliberately non-linear: “massive” is three times “medium”, not a couple of points above it.
• Confidence tempers enthusiasm: 100% means quantitative data, 80% means support for one of the estimates, 50% is mostly intuition. Anything below 50% is a moonshot worth validating first.
• Effort is the denominator: the more expensive the item, the lower the score. Count person-months and round to halves; a week of work is roughly 0.25.

The score is “impact per unit of effort”. Its absolute value means nothing: 2,400 is neither good nor bad on its own, only in comparison with items from the same backlog scored with the same reach period.

ICE was popularized by Sean Ellis, who coined the term growth hacking. It is built for a steady stream of growth ideas where there is no time to count reach and person-months. Each idea gets three ratings from 1 to 10:

In “Hacking Growth” Ellis and Brown average the ratings; many teams multiply them instead. The difference is not cosmetic: the product punishes a single low rating much harder. An idea rated 9 · 9 · 1 gets 81 of 1,000 when multiplied and 6.3 of 10 when averaged — so by the mean it beats an even 6 · 6 · 6 (216 and 6). The calculator supports both; choose one and keep it for the whole backlog.

ICE’s main weakness is subjectivity: a “7 out of 10” means different things to different people. Agree on reference examples for each rating and score the backlog together rather than one by one.

• RICE fits a quarterly product backlog: items of different size, analytics for reach and engineering estimates for effort.
• ICE fits a weekly growth meeting: many cheap experiments and a quick decision.
• The Kano model answers a different question — how users will perceive a feature: must-be, performance or delighter. Use it before RICE to estimate impact more honestly; you can analyze a Kano survey in the Kano survey analyzer.
• MoSCoW (must, should, could, won’t) is good for fixing release scope, but it does not rank items within a group.

Common mistakes

• Different reach periods. One item has reach per month, another per year. The second scores twelve times higher for no reason.
• Impact on nothing in particular. “High impact” on what? Pick one goal for the quarter — activation, retention, revenue — and rate impact against it.
• 100% confidence by habit. If no data backs the reach and impact estimates, use 50%. That multiplier is what protects the backlog from pet ideas.
• Following the ranking blindly. The formula ignores dependencies, tech debt, customer commitments and strategy. Use the score as an argument in the discussion, not a verdict.
• Never checking the estimate. After launch, compare the forecast with reality: how many people actually used the feature. The feature adoption calculator helps with that, and the A/B test calculator checks the effect.

1. McBride S. RICE: Simple prioritization for product managers. Intercom Blog — the original description of the method and the impact and confidence scales.
2. Ellis S., Brown M. Hacking Growth: How Today's Fastest-Growing Companies Drive Breakout Success. Crown Business, 2017 — ICE scoring for growth experiments.
3. Cagan M. Inspired: How to Create Tech Products Customers Love. 2nd ed. Wiley, 2017 — value and feasibility risks when choosing what to build.
4. Clegg D., Barker R. Case Method Fast-Track: A RAD Approach. Addison-Wesley, 1994 — origin of the MoSCoW method.