RICE. ICE. MoSCoW. Kano. Weighted scoring. Story points. Every PM has a framework. Almost nobody has a prioritization practice that actually works. Here's what prioritization actually requires — and why frameworks are only the beginning.
The first time I ran a proper RICE scoring session with a team, I was proud of how organized it felt. We assigned reach, impact, confidence, and effort scores to every item in the backlog. We calculated the numbers. We ranked them. We had a clean, prioritized list that we could present to stakeholders with confidence.
Then the head of sales came to the next planning meeting and asked why the feature her enterprise customer needed wasn't at the top. I showed her the RICE score. She was unimpressed. "The scores are based on our assumptions," she said. "Our assumptions about enterprise customers are wrong because we've never actually talked to enterprise customers in depth."
She was right. The RICE score was a precise number derived from imprecise inputs. Precision is not the same as accuracy. And the false confidence of a scored list can be more dangerous than having no framework at all — because it stops people from questioning the underlying assumptions.
Where the Frameworks Are Actually Useful
RICE (Reach × Impact × Confidence ÷ Effort) is useful for forcing explicit consideration of four dimensions that PMs often weight implicitly. The discipline of assigning rough numbers creates useful conversations — even if the numbers themselves are approximate. Where it breaks down: it treats all four dimensions as equally important and can produce misleading results when the underlying estimates diverge widely from reality.
ICE (Impact × Confidence × Ease) is RICE's simpler cousin. Useful when you need a quick, rough cut at prioritization. Dangerous when used as a substitute for deeper analysis on consequential decisions.
MoSCoW (Must Have, Should Have, Could Have, Won't Have) is useful for aligning teams on what's essential versus nice-to-have, particularly in project contexts with a fixed deadline. Think of it as a conversation starter rather than a prioritization system.
Kano model is the most sophisticated of the standard frameworks. It distinguishes between basic needs (hygiene factors that must exist), performance needs (more is better), and delighters (unexpected features that create disproportionate satisfaction). Genuinely useful for thinking about user psychology, but requires actual user research to apply correctly — not just PM intuition.
The Real Questions That Determine Priority
Real prioritization requires answering four questions before any framework enters the picture:
What is the strategic context right now?
What are we trying to accomplish this quarter? What does success look like for the business and for the user? If you don't have clear answers, any prioritization you do is disconnected from strategy. You're optimizing locally without knowing what the global objective is.
What are we optimizing for in this planning cycle?
Prioritization always involves a trade-off, and different objectives create different rankings. The same backlog looks completely different when you're optimizing for new user acquisition versus retention versus revenue versus engineering health. Before scoring anything, be explicit about the current optimization target.
What do we know, and what are we assuming?
Most prioritization exercises produce rankings that are primarily a function of assumptions. The discipline of separating knowledge from assumption — and being honest about how much of the scoring is informed judgment versus genuine evidence — changes how confident you should be in the output.
What are the dependencies and sequencing constraints?
The highest-priority item might be blocked by infrastructure work that needs to happen first. The second-highest item might unlock three others. Prioritization divorced from sequencing often produces roadmaps that can't actually be executed in the order they're listed.
When to Throw the Framework Out
There are situations where frameworks actively mislead. Here's when to trust judgment over scores:
When the decision is about direction, not optimization. Should we build for enterprise or SMB? Should we invest in a new product line or deepen the core product? These are strategic questions. No scoring system can answer them. They require strategic judgment and organizational alignment.
When the stakes are asymmetric. A feature that has a small chance of being a breakout success versus many features that are safe bets — this is a portfolio question, not a scoring question. Frameworks treat all risks as symmetric. Real product bets often involve asymmetric upside.
When the team already knows what's right. Sometimes the most important thing a prioritization session produces is honest alignment around what everyone already believes. If the team thinks X is the right priority and the RICE score says Y, examine your RICE scores — don't override the team's judgment.
The best prioritization I've seen combines frameworks with something no framework can replace: a clear strategic context, an honest assessment of uncertainty, and the courage to make a real choice instead of a hedged list.
Prioritization not working?
The most common prioritization problem isn't the wrong framework — it's the wrong starting conditions. If your team constantly re-prioritizes or ships things that don't move the needle, the problem is upstream. Let's find it.
Work with Yogesh →