Your RICE Score Is a Guess Wearing a Lab Coat

You line up your backlog. You score each idea on impact and effort. You pick the top of the list and call it a roadmap. It feels rigorous. It looks like math. But you built the whole thing on two guesses you are bad at making: how hard the work will be, and how much it will matter. Strip out the honesty about what you actually know, and a prioritization score is just a hunch dressed up in a spreadsheet. The fix is not a better matrix. It is adding confidence, matching the tool to your stage, and sorting by time horizon instead of trusting one tidy number.

The deep cut

• A score without confidence is a guess. Itamar Gilad found at best 1 in 3 tested ideas create any positive result.
• The planning fallacy wrecks both axes. Teams underestimate effort and, per Gourville, overestimate value by a factor of nine.
• Validate cheap before you build big. Smoke tests and fake-door campaigns price an idea before engineering starts.

Why the matrix lies to you

The Impact/Effort matrix is everywhere because it is simple. Plot ideas on two axes, drop the money pits, grab the easy wins. The trouble is that both axes are predictions about the future, and people are terrible at those. Itamar Gilad lays this out plainly: we underestimate effort because of optimism and bad memory, and we overestimate impact because nobody set a success metric up front, so we only remember the wins.

The numbers are humbling. Analyses from Microsoft, Netflix, and Booking.com showed that at best 1 in 3 tested ideas moved a metric in a good direction. A startup is closer to 1 in 10. Gilad points to Gourville's research that companies overestimate a product's value by a factor of nine. So the spot on the matrix you are most likely to land in is not the big win. It is the money pit.

Add the column everyone skips

The missing piece is confidence: how well-grounded your impact and effort guesses actually are. Gilad's fix is to add a column and fold it into the math. Instead of impact over effort, you score impact over effort times confidence, where very low is 0.1 and very high is 0.8. That one move pulls down any big-impact idea you are quietly guessing about and pushes up the ones backed by real evidence.

This is also what RICE already tries to do, and why a SaaS twist like Anup Sheshadri's SU-RICE exists: plain RICE misses signals that matter for subscription products, so you add factors rather than trust one generic score. The lesson holds either way. A framework is only as good as the honesty you feed it. Make the team say out loud how sure they are, and the fake certainty falls away.

Match the question to the framework

Not every prioritization problem is an impact versus effort problem. When the real question is what customers actually feel, you want a different lens. The Kano model, as Meenakshi Uniyal explains it, sorts features by how they hit satisfaction: basic needs you must have, performance needs that scale with quality, and excitement needs that delight. Miss a basic need and users revolt. Add an excitement feature and you stand out.

Christian Watson's customer impact versus expectations grid runs on the same idea with four plain buckets: Wow, Must-have, Neat, and Who Cares. His sharp observation is that Wow features decay into must-haves over time. A touchscreen was once a delight and is now the floor. So the framework you reach for depends on the question you are asking, and a fast Value vs Effort sketch from airfocus is fine for a rough roadmap pass, as long as you do not mistake the sketch for a decision.

Buy confidence before you build

If confidence is the input that fixes your scores, the job becomes raising it cheaply. Gilad lists the moves. Do back-of-the-envelope math on impact, which can expose a two-order-of-magnitude error in two minutes. Use data you already collect from a similar past launch. Run low-cost validation: surveys, user interviews, a fake-door campaign, a thin MVP. And A/B test the real thing, which removes almost all the guesswork.

This matters more now, not less. The Mountain Goat argument that AI changes what makes a backlog valuable holds that when working software gets cheap to produce, the scarce thing is validation, not output. That favors a dynamic Now versus Not-Now view over a frozen ranked list. Decide what you are confident enough to build now, and park the rest until you learn more. The horizon does the sorting, and evidence promotes an idea into the Now column.

Three questions for your team

• Pull your top three backlog items. For each, what is our confidence that the impact is real, on a 0.1 to 0.8 scale, and what evidence backs that number?
• Which of these ideas could we validate this week with a survey, a fake door, or old data before we commit any engineering time?
• Are we ranking one frozen list, or sorting into Now versus Not-Now so new evidence can promote an idea instead of forcing a re-score?