Ask five product managers which prioritization framework they use and you'll get five answers, usually followed by "but we don't really follow it strictly."
I think that's fine. Frameworks are tools for a particular kind of decision. The mistake is picking one and applying it to everything, including decisions it wasn't built for.
Here's how I think about the common ones, and when I reach for each.
The quick comparison
| Framework | Best for | What it hides | Speed |
|---|---|---|---|
| RICE | Comparing several similar ideas with some data | Dependencies, and the fact that inputs are guesses | Medium |
| ICE | Quick sorting of many small experiments | Reach, so niche ideas can score too high | Fast |
| MoSCoW | Agreeing scope for a fixed release or deadline | Why something is a must, unless you ask | Fast |
| Kano | Understanding which features users expect vs which delight them | Effort and cost entirely | Slow (needs research) |
| Cost of delay | When timing really matters | Hard to estimate without good business data | Medium |
RICE
Reach, Impact, Confidence, Effort. I like it because it makes you write down how many people an idea affects and how sure you are. I wrote a full RICE worked example with a sensitivity check.
Its weakness is that it scores ideas one at a time. It doesn't know that idea B is useless until idea A ships.
ICE
Impact, Confidence, Ease. Basically RICE without reach. It's useful for a growth team running lots of small tests, where speed matters more than precision.
The risk is that without reach, an idea affecting a tiny group can look as good as one affecting everyone.
MoSCoW
Must have, Should have, Could have, Won't have. I use this one to agree what goes into a fixed release more than to rank ideas.
I used something like it during the Travelxp OTT launch, when the date was firm and the question was what had to be in version one. The useful part is the "Won't have" list. Writing it down stops scope from growing quietly.
The trap is that everything becomes a Must. When that happens, I ask: "If this isn't in the release, does the release still make sense?" Usually a few Musts become Shoulds pretty quickly.
Kano
Kano sorts features into basic expectations, performance features, and things that delight. It's based on asking users how they'd feel if a feature were present or absent.
It's good for understanding why users are unhappy even when you ship a lot. Often a basic expectation is broken, like playback that stutters, and no amount of delight features will make up for it. It says nothing about effort, so you'll still need something else to decide what to build first.
Cost of delay
This asks what you lose each week a feature isn't live. It's the right tool when timing really matters, like a partner integration tied to a season or a contractual date.
It needs reasonable business data to estimate, so I use it for a few big decisions rather than the whole backlog.
How I actually choose
I start with the decision, not the framework:
- Many small, similar ideas? ICE or RICE.
- Fixed date, need to agree scope? MoSCoW.
- Not sure what users value? Some Kano-style research first.
- Timing is the whole question? Cost of delay.
- An incident or legal requirement? None of them. Just handle it.
If you want to practise choosing under a capacity limit, Sprint Rush is a small game I built around exactly that. It's a simplified game, but it makes the trade-off feel real quickly.
Whatever you use, write the reason next to the decision. "We chose A over B because B depends on data we don't have yet" is more useful six months later than any score.