🪜Prioritization Frameworks
RICE, ICE, MoSCoW, Kano — the frameworks every PM has heard of, and the one that actually matters most.
Prioritization is the central act of product management. Frameworks help, but most PMs use them as theater. The skill is knowing which framework to reach for, when, and when to throw the framework away and just decide.
Prioritization frameworks are scaffolding for thinking, not algorithms for deciding. Use them to surface assumptions and force trade-off conversations. The right framework depends on context: ICE for fast triage, RICE for cross-functional bets, MoSCoW for stakeholder negotiation, Kano for feature-vs-feature decisions, Opportunity Solution Trees for end-to-end strategy.
The frameworks in 30 seconds each
RICE. Reach × Impact × Confidence ÷ Effort. Output is a relative score. Great for cross-team backlogs where you need a defensible ranking. Weakness: assigns false precision to subjective estimates.
ICE. Impact × Confidence × Ease. Simpler than RICE, faster to apply. Good for solo PM triage. Weakness: same as RICE.
MoSCoW. Must / Should / Could / Won't. Categorical, not numeric. Great for stakeholder negotiations — forces explicit 'won't.' Weakness: doesn't help you decide between two 'Musts.'
Kano Model. Classifies features into Basic (expected, no thrill if present), Performance (linear value), Delighters (surprise and delight), Indifferent, and Reverse. Useful for type of investment, not just ranking. Weakness: doesn't tell you absolute priority.
Opportunity Solution Tree (Teresa Torres). Maps outcomes → opportunities → solutions → tests. Best for strategic prioritization across a quarter; you choose the opportunity to attack, then explore solutions. Weakness: takes longer to set up.
Cost of Delay. What does it cost the business per week to NOT have this? Forces you to think about urgency, not just value. Powerful for cross-functional debates.
Which to use when
- Engineering backlog of 50 small items: ICE for fast triage.
- Cross-team annual planning: RICE or Opportunity Trees.
- Stakeholders asking for 12 features: MoSCoW to force the 'won't' conversation.
- 'Should we add a delight feature or fix a basic gap?': Kano.
- 'How do we justify the platform investment vs sales-driven features?': Cost of Delay.
The framework trap
Most PMs run RICE on every decision, fill in plausible-looking numbers, and treat the output as truth. The output is the same as the input — your priors, dressed up.
The senior move: use the framework to force conversation, not to produce an answer. When the team scores a feature low, ask 'what would have to be true for this to score high?' That conversation surfaces assumptions you can then test. The score itself is secondary.
The fallback when frameworks fail
Sometimes you're paralyzed by analysis. The move: timebox the analysis (1 day max), then decide based on judgment. Note your reasoning. Commit. If you were wrong, the metric will tell you in 4-6 weeks and you can adjust. Indecision is more expensive than imperfect decisions.
Key frameworks
Reach × Impact × Confidence ÷ Effort. Best for backlog ranking.
Basic / Performance / Delighter / Indifferent / Reverse. Best for feature-type strategy.
Outcome → Opportunities → Solutions → Tests. Best for end-to-end strategy.
Weekly business cost of not having a feature. Best for urgency debates.
Real-world examples
Intercom's product team developed and shared RICE in 2016. It became the default backlog-ranking framework across SaaS, partly because Intercom's PMs published their playbook openly.
Common pitfalls
- ⚠Running the framework on every decision instead of using judgment for small calls.
- ⚠Treating the framework output as ground truth.
- ⚠Skipping the 'force the conversation' step that's the actual value.
Go deeper — recommended reading
Interview questions (2)
Q1What prioritization framework do you use, and why?executionmid▼
I don't use one framework for everything — the framework should match the decision.
For small backlog triage I use ICE (Impact × Confidence × Ease) — it's fast and good enough.
For cross-team annual planning I use RICE or an Opportunity Solution Tree. RICE forces explicit confidence and effort estimates; Opportunity Trees keep the team focused on outcomes rather than features.
For stakeholder negotiations I use MoSCoW — Must / Should / Could / Won't. The 'Won't' column forces the hard trade-offs that otherwise get glossed over.
The non-obvious thing: frameworks are scaffolding for conversation, not algorithms for deciding. The value is in the debate that surfaces assumptions, not the score that comes out. When my team scores a feature low, I ask 'what would have to be true for this to score high?' That's where the real product judgment happens.
Q2Your team's backlog has 200 items. The CEO is asking for a roadmap. Walk me through your approach.strategysenior▼
Five-step plan:
- Cluster. Group the 200 items into 8-12 themes. Most backlogs collapse this much when you group by user-job or by metric-impact.
- Strategic filter. What's the company's strategy this year? Drop themes that don't ladder up.
- Outcome assignment. For each remaining theme, what business metric would it move? If you can't answer, the theme isn't well-defined yet.
- RICE or Cost of Delay across themes. Force trade-offs at the theme level, not the item level. Item-level prioritization at 200 scale is theater.
- Pick 3-5 themes for the quarter. Everything else is explicitly 'not now.' Publish the rationale.
The CEO doesn't want 200 items prioritized. They want clarity: 'these 3 themes are what we're betting on this quarter, here's why, here's what we'd hit, here's what we're explicitly choosing not to do.' That's the roadmap.