Your backlog has 40 items and every one of them is "important". Someone has to decide what ships first, and gut feel stops working the moment two people disagree.
So which method should you use? Use value vs effort when your team is small and the backlog is short. Use ICE when you need a fast ranking and you trust your judgment. Use RICE when you have real data on how many customers each item touches. And for a big strategic bet, use none of them.
Here's how each one works, where it breaks, and what happens when you run all three on the same backlog.
What is the difference between RICE, ICE and value vs effort?#
All three rank ideas so you can decide what to build first. They differ in how much data they need and how much false precision they add.
| Method | How it works | Needs | Breaks when |
|---|---|---|---|
| Value vs effort | Plot each idea on a 2x2 grid | Gut sense of value and effort | Everything lands in the same quadrant |
| ICE | Impact x Confidence x Ease | Three 1 to 10 scores per idea | The scores are just opinions |
| RICE | (Reach x Impact x Confidence) / Effort | Real reach data and effort estimates | Reach is guessed, not measured |
There's no best framework. There's the one that fits the evidence you actually have.
Value vs effort: the simplest way to prioritize#
Draw a square. Put value on one axis and effort on the other. Place every idea on it, then build the high value, low effort corner first.
| Low effort | High effort | |
|---|---|---|
| High value | Do first | Plan carefully |
| Low value | Only if there's spare capacity | Probably never |
Fixing a confusing onboarding step is a good example. It might lift activation for a few days of work. Rebuilding your analytics engine could be worth more, but it costs months. The first one wins right now.
I like it because it's hard to fake precision. Nobody argues whether an idea is a 7.3 or a 7.4. They argue about which box it belongs in, and that's the argument you want.
But it breaks in two places. When twelve ideas land in "high value, low effort", the grid has stopped helping and you need a tiebreaker. And "value" means different things to different people. One person means revenue, another means retention. Agree on the definition first, or the grid only looks like agreement.
ICE: fast ranking with three scores#
ICE stands for Impact, Confidence and Ease. Score each from 1 to 10, then multiply.
ICE score = Impact x Confidence x Ease
A signup flow fix might get Impact 7, Confidence 8, Ease 9. That's 7 x 8 x 9 = 504. A higher number means more attention, relative to other ideas scored the same way. It's not a prediction of revenue.
ICE takes minutes, and everyone gets it. That makes it good for a weekly triage or a list of experiments.
It breaks in two places. First, the inputs are opinions. Two people score the same feature 4 and 9, and multiplying hides the disagreement. Second, Ease rewards small things, so a big bet never beats a pile of tweaks.
RICE: ranking with real reach numbers#
RICE adds Reach, how many people the idea affects, and divides by effort. The framework comes from Intercom's product team.
RICE score = (Reach x Impact x Confidence) / Effort
- Reach: how many customers it affects in a set period, like a quarter.
- Impact: how much it moves each of them. Intercom's scale is 3 (massive), 2 (high), 1 (medium), 0.5 (low) and 0.25 (minimal).
- Confidence: how sure you are. 100% is high, 80% medium, 50% low.
- Effort: person-months, in whole numbers with a half month as the minimum.
Reach is what makes RICE better than ICE. A feature that helps 2,000 accounts should beat one that helps 20.
Here's the thing, though. It breaks the moment Reach is invented. If you don't track usage, you'll guess it, and the formula turns that guess into a score that looks scientific. It also pushes down foundational work that matters to your best customers but touches few accounts.
If you can't answer "how many customers asked for this?" from your own data, RICE adds work without adding truth. That's where a feedback board helps. Votes and linked requests give you a Reach number instead of a guess. Votes and linked requests on a FeatureOS feedback board give you a Reach number instead of a guess. For a plain explainer, see RICE scoring. To try all three on your own list, use the free feature prioritization calculator.
What happens when you run all three on the same backlog?#
Let's say you have four ideas. The numbers below are made up for the example, not real product data.
| Idea | Value vs effort | ICE | RICE |
|---|---|---|---|
| Simplify signup | High value, low effort | 7 x 8 x 9 = 504 | (2,000 x 1 x 0.8) / 0.5 = 3,200 |
| Reporting export for one big customer | High value to one account, medium effort | 6 x 9 x 7 = 378 | (40 x 3 x 1.0) / 1 = 120 |
| Dark mode | Low value, low effort | 3 x 8 x 8 = 192 | (1,200 x 0.5 x 0.8) / 1 = 480 |
| New analytics dashboard | High value, high effort | 8 x 5 x 3 = 120 | (600 x 2 x 0.5) / 4 = 150 |
The three methods agree on exactly one thing. Simplify signup goes first.
After that they split. ICE ranks the reporting export second. RICE ranks it last, because only 40 accounts would use it. Neither is wrong. They're measuring different things, and that gap is the finding.
So you ask who the 40 are. If one of them is your largest customer, renewing next quarter, you build the export. A formula can't know that. You can.
Which framework should you use?#
- Small team, short backlog, little data: value vs effort.
- Weekly triage, experiments, speed matters: ICE.
- Reliable reach data and a long backlog: RICE.
- Security, compliance or a major strategic bet: none of them. Gather the evidence, decide, and write down why.
You don't have to pick one forever. Plenty of teams plot ideas on value vs effort to cut the list, then run RICE on the top ten.
What do prioritization scores miss?#
Every method here ranks what's already on your list. None tells you what's missing, and none tells you what to refuse.
A high score doesn't make something worth building. A low score doesn't make a strategic bet wrong. I use the score to start the conversation. When two people score Reach differently, or engineering's effort estimate is double product's, that disagreement is where the real discussion is.
Then someone makes the call, and says no to the rest. I wrote about how to do that in the art of saying no to feature requests. For other ways to structure these decisions, see seven product management frameworks or try MoSCoW prioritization.
If your requests are scattered across Slack, email and support chats, start by getting them in one place. Start a free trial of FeatureOS and see which ones your customers keep asking for.