How to decide what gets built first: RICE, ICE, MoSCoW, Kano, and Opportunity Scoring, with real examples and a guide on when to use each.
RICEMoSCoWKanoPrioritization
7 min read
Every product team has more good ideas than time to build them. Prioritization is the process of deciding which ideas get built, in what order, and why. Done well, it's the most high-leverage thing a PM does. Done poorly, or not done at all, it produces teams that ship a lot and move nowhere.
The frameworks in this guide don't replace judgment. They make your judgment explicit, defensible, and shared. That's the real goal: not a formula that tells you what to build, but a structure that makes trade-offs visible so the team can debate them before building, not after.
The Problem
Why prioritization is the hardest PM skill
Prioritization is hard for three reasons that compound each other. First, the backlog is infinite: good ideas come from everywhere, and every stakeholder believes theirs is the most important. Second, every "yes" is also a "no" to something else, but the cost of saying no is immediate and the cost of the alternative is hypothetical. Third, the information you'd need to decide with confidence is usually incomplete.
Stakeholder pressure
Sales wants features that close deals. Engineering wants technical debt cleanup. Marketing wants a better landing page. Leadership wants the big bet. All of them are right in their context. The PM must hold the whole.
Opportunity cost is invisible
When you build feature A, you don't see the value of feature B that you didn't build. The cost of a bad prioritization decision is real but unobservable, which makes it easy to rationalize almost any choice.
Uncertainty is irreducible
You never have perfect data on impact before you build. Frameworks don't eliminate uncertainty. They force you to make your estimates explicit so they can be challenged and refined.
The goal of prioritization frameworks is not to produce the right answer. It's to make the reasoning transparent enough that the team can have a productive argument about the trade-offs. A well-reasoned decision you can defend beats an intuitive decision you can't explain.
Framework 1
RICE: the quantified backlog
RICE was developed by Intercom and is the most widely used scoring framework in product management. It calculates a priority score for each initiative based on four factors: Reach, Impact, Confidence, and Effort.
How many users will this affect per quarter? Use real data where possible: active users who hit the relevant flow, not your entire user base. Example: if 2,000 users/month go through the checkout flow, a checkout improvement Reach = 2,000.
Impact
How much will it move the needle for each user it reaches? Use a standard scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal. This is where most of the subjectivity lives. Be conservative and document your reasoning.
Confidence
How confident are you in your Reach and Impact estimates? Express as a percentage: 100% = data-backed, 80% = strong qualitative evidence, 50% = gut feel, 20% = speculation. This prevents overconfident estimates from dominating the backlog.
Effort
How many person-months does this require? Include design, engineering, QA, and PM time. Estimate in half-person-months. A score of 1 = 1 person-month. This is the denominator. High-effort items need proportionally higher impact to rank well.
Example: A checkout flow redesign with Reach = 2,000, Impact = 2, Confidence = 80%, Effort = 3 person-months scores: (2,000 × 2 × 0.8) ÷ 3 = 1,067. Compare this against a small copy change with Reach = 500, Impact = 1, Confidence = 100%, Effort = 0.1, which scores (500 × 1 × 1) ÷ 0.1 = 5,000. The small change scores higher, a useful reality check on the "big project" bias.
Framework 2
ICE: fast triage for large backlogs
ICE is a lighter version of RICE designed for speed. It scores each item on three dimensions (Impact, Confidence, and Ease), each rated 1–10, then multiplies them together. ICE Score = Impact × Confidence × Ease.
Impact (1–10)
How much will this move a key metric? 10 = transformative impact on north star. 1 = negligible. Unlike RICE, this doesn't require a specific unit. It's a relative judgment across the backlog.
Confidence (1–10)
How sure are you of your impact estimate? 10 = we've tested this, data is clear. 1 = pure hypothesis. Low confidence should dampen enthusiasm for high-impact ideas. Score honestly.
Ease (1–10)
How easy is this to implement? 10 = hours of work. 1 = months of work. Note: this is the inverse of Effort in RICE. ICE favors quick wins; RICE explicitly divides by effort to normalize for scale.
ICE is best used when you have a large backlog that needs rapid sorting and you don't have the data for a rigorous RICE analysis. It's also useful in early-stage products where impact estimates are inherently speculative. The precision of RICE would be false precision.
Framework 3
MoSCoW: scoping releases
MoSCoW doesn't produce a ranked list. It produces buckets. Each requirement is categorized as Must have, Should have, Could have, or Won't have (this time). It's designed for release scoping: drawing a clear line between what ships and what doesn't.
Must have
The product fails without this. Not "important," but essential. If this isn't shipped, the release doesn't make sense. The test: if this were cut, would the product still deliver its core promise? If no, it's a Must.
Should have
Important and expected, but the product ships without it. Typically items that would be noticeable by their absence but don't break the core use case. These are the first candidates to defer if the sprint is at risk.
Could have
Nice-to-have if time allows. Low cost to include, low cost to exclude. These can be included as sprint capacity permits. They shouldn't drive planning. If they never get done, that's acceptable.
Won't have (this time)
Explicitly out of scope for this release, not forever. This bucket is critical: it prevents scope creep by making exclusions explicit. Stakeholders who know their request is in "Won't have this time" stop pushing for it to sneak in.
The most common MoSCoW mistake: too many Musts. If everything is a Must, nothing is. A healthy release scope has at most 60% of effort in Must have items. Otherwise you've just renamed your entire backlog.
Framework 4
Kano: understanding what users actually value
The Kano model is unique among prioritization frameworks because it focuses on user satisfaction rather than effort or impact. It categorizes features by how their presence (or absence) affects user satisfaction, which reveals that not all features contribute to satisfaction equally.
Basic Expectations (Must-be)
Users expect these. Their presence doesn't increase satisfaction. Their absence causes strong dissatisfaction. Example: an app that crashes frequently. Fixing it won't delight users; not fixing it will lose them.
Performance Features
More is better. These features increase satisfaction proportionally: the faster the app loads, the better. Investing in these has a clear, linear return. Most roadmap features live here.
Delighters (Attractive)
Users don't expect these. They're surprised and delighted when they exist. Their absence doesn't hurt satisfaction. But when present, they generate disproportionate positive response. The "wow" features that drive word-of-mouth.
Kano is most useful in discovery, before building, to classify user requests. A feature request that sounds exciting might be a Basic Expectation, table stakes that everyone else already has. A small, unexpected feature might be a Delighter with outsized impact on NPS and referral. Kano prevents you from investing disproportionately in features that only bring you to parity.
Framework 5
Opportunity Scoring: finding the gaps
Opportunity Scoring, developed by Tony Ulwick, identifies where users are underserved. For each job-to-be-done or user need, you measure two things: how important the outcome is to users, and how satisfied they currently are with existing solutions. The gap is where the opportunity lives.
High opportunity. Users care about this but existing solutions don't serve them well. This is where innovation produces the most value, and where competitive differentiation is most achievable.
Example: users say "organizing my work tasks" is critically important but are only somewhat satisfied with current tools.
High importance, high satisfaction
Low opportunity. Users care, and they're already well-served. Investing here means fighting on a crowded battlefield. You'd need to be dramatically better to displace what exists.
Example: "sending a message" in a messaging app is important, but Telegram and WhatsApp have it covered.
Decision Guide
Which framework to use, and when
Use RICE when
You have data (or can estimate from data), you need to compare a large number of diverse initiatives, and you want a score you can defend to stakeholders. Best for quarterly roadmap planning with an established product.
Use ICE when
You're in early-stage or need to triage a large backlog quickly without deep analysis. Also useful for growth experiments where speed matters more than precision. Think of it as RICE with training wheels: faster, less rigorous.
Use MoSCoW when
You're scoping a specific release or sprint and need to draw a clear ship/don't-ship line. Particularly useful when stakeholders need to agree on scope before development starts. Pair it with RICE to decide what goes into each bucket.
Use Kano when
You're in discovery and want to understand which user needs are table stakes vs differentiators. Useful before investing in user research synthesis. It frames what you're looking for. Also powerful for competitive analysis.
Use Opportunity Scoring when
You're defining a new product direction and want to identify the jobs-to-be-done that are most underserved. Requires a user survey, but produces the most direct link between user needs and product bets.
No framework survives first contact with organizational politics. The real value of these tools is that they make your reasoning legible. When a stakeholder pushes back, you're not defending your gut: you're explaining why the numbers work out this way, and inviting them to challenge the assumptions, not the conclusion.