Roadmap Prioritization: RICE vs Kano vs Opportunity Solution Tree

I've watched a team RICE-score themselves into a year of dead features. Fifteen items, all carefully ranked, all shipped on schedule. Activation didn't move. Retention didn't move. Revenue per account stayed flat. The CEO finally asked the question every PM dreads: "What did we actually learn?" Nobody had a good answer, because the framework had never been about learning. It was about defending the order of a list.

That's the thing about prioritization frameworks. Most PMs use RICE because Intercom blogged it in 2017 and it spread like a virus through every product org with a Notion subscription. It looks rigorous. It produces a number. Stakeholders nod when they see the spreadsheet. But the framework isn't the answer to your roadmap problem. The framework is a forcing function for the conversation your team is avoiding. Pick the one that forces the right conversation, and you'll ship better. Pick the wrong one, and you'll ship a lot.

So let's talk about the three you'll actually be asked to defend, what each one is good at, where each one breaks, and when you should stack them.

RICE math, with real numbers

RICE stands for Reach, Impact, Confidence, Effort. The formula is straightforward:

Score = (Reach × Impact × Confidence) / Effort

• Reach: how many users this affects in a given period. Usually monthly. Be honest about what "affects" means.
• Impact: how much it moves your target metric per affected user. The original Intercom rubric uses 3 / 2 / 1 / 0.5 / 0.25 for massive / high / medium / low / minimal. It's coarse on purpose.
• Confidence: a percentage. 100% means you have data. 80% means you have evidence. 50% means you're guessing.
• Effort: person-months across product, design, and engineering combined.

A real example. Imagine a B2B SaaS with 4,000 monthly active accounts and you're scoring three roadmap candidates for next quarter:

Bulk import wins by a wide margin. And honestly, on this scoring, it should. You've got high confidence, decent reach, and low effort. RICE is doing exactly what it's built to do: surfacing the obvious cheap-and-effective bet.

When RICE genuinely works:

• Mature products with clear KPIs. You know what activation, retention, and conversion look like. You can predict impact within a reasonable range.
• Large teams shipping in parallel. When five squads need to coordinate sequencing, a shared scoring rubric is faster than ten meetings.
• Defending trade-offs to a finance-minded exec. A CFO can read a RICE table. They cannot read a customer journey map.

Where RICE breaks:

• Early products. Reach is a guess because you don't know your real audience yet. Impact is wishful thinking because you don't know what success looks like.
• Discovery-stage bets. RICE penalizes uncertainty through the Confidence multiplier, which means anything genuinely new gets crushed by anything incremental. Your roadmap fills with bulk-import features and never with the bet that could actually change the trajectory.
• Strategic bets. "Should we expand to mid-market?" doesn't fit on a RICE table. Don't try.

The honest critique: RICE optimizes for what you can measure, not for what matters. Use it where measurement is easy, ignore it where it isn't.

Kano model, with a survey question that actually works

The Kano model is older and weirder than RICE. Noriaki Kano built it in the 1980s to explain why some features customers love and some they barely notice. There are five categories, but you only need three for prioritization:

• Basic (Must-have): customers don't notice when it's there, they're furious when it's missing. Two-factor auth. Export to CSV. Decent search. Building these doesn't make them love you. Skipping them makes them leave.
• Performance (More is better): linear satisfaction. Faster page loads, more integrations, better uptime. Worth investing in proportionally to cost.
• Excitement (Delighters): customers don't expect it, can't ask for it, but love it when they get it. The thing that makes the demo close. Slack threads, Linear's keyboard shortcuts, Figma's multiplayer cursors when they launched.

The other two categories (Indifferent and Reverse) are where you cut features. Indifferent means nobody cares. Reverse means some people actively dislike it (think aggressive AI suggestions in a calm productivity tool).

Here's the survey question template I actually use, two questions per feature:

1. How would you feel if the product had this feature?
2. How would you feel if the product did not have this feature?

Both answered on a 5-point scale: I like it / I expect it / I'm neutral / I can tolerate it / I dislike it.

The cross-tab tells you the category. "Like it / dislike not having it" = Performance. "Neutral / dislike not having it" = Basic. "Like it / neutral about not having it" = Excitement. Run this on 50-100 customers per segment and you have signal worth defending.

When Kano wins:

• Feature parity decisions. "Competitor X just shipped Y. Do we need it?" Kano tells you whether Y is Basic (yes, ship it now), Performance (yes, but on schedule), or Excitement (only if it differentiates).
• Cutting scope. When eng tells you the spec is six weeks and you have four, Kano tells you what to drop. Cut Excitement first if Basics aren't done.
• "Should we even build this?" calls. If a feature scores Indifferent, the data tells you to walk away.

The trap: Kano needs real customer data, not a PM's gut sort. I've seen entire roadmaps justified by a Kano analysis that was three people in a conference room arguing about which column to put bulk delete in. That's not Kano. That's a PM laundering opinions through a framework name.

Opportunity Solution Tree, when it wins

Teresa Torres built the Opportunity Solution Tree (OST) for teams doing continuous discovery. The structure:

                  Outcome
                     |
       -----------------------------
       |             |             |
  Opportunity   Opportunity   Opportunity
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
 Solution Solution Solution ... Solution
   |
Experiment

You start with one Outcome (a measurable business result, like "increase trial-to-paid conversion by 15%"). You map Opportunities (customer pain points, unmet needs, friction moments) gathered from weekly customer interviews. Under each opportunity you brainstorm multiple Solutions. Under each promising solution, you design an Experiment to validate before you build.

The genius is that it forces a hierarchy. You cannot prioritize a solution against a solution. You can only prioritize opportunities, then pick the best solution for the chosen opportunity.

When OST wins:

• Continuous discovery teams. Teams running weekly customer touchpoints and doing prototype testing. The tree updates as discovery surfaces new opportunities.
• Outcome-driven orgs. Where leadership sets goals as outcomes, not feature lists. OST translates outcomes into a discovery-and-build pipeline.
• Avoiding feature factory mode. OST's killer move is making it visible when a solution doesn't ladder up to an opportunity that ladders up to the outcome. If it doesn't connect, don't build it.

Where OST fails:

• Orgs where "discovery" means one user interview a quarter. OST is a continuous-discovery operating system. Without the discovery cadence, the tree is decorative. You'll fill it with opportunities you assumed instead of opportunities you found.
• Teams without research access. If your PM has to fight to get five customer calls a month, OST is aspirational, not operational.
• Pure execution quarters. Sometimes you have to ship the renewal-blocking thing. OST won't help you sequence eight known features.

"Now, next, later" and why it's RICE in a trench coat

Most "now / next / later" roadmaps are RICE rankings with the numbers hidden. The PM scored everything, the top of the list went into Now, the middle into Next, the bottom into Later. The format pretends to be flexible but the prioritization is identical to a sorted spreadsheet.

The format actually means something when each bucket has a different epistemic standard:

• Now: high confidence, scoped, committed. You will ship this. The team owns the outcome.
• Next: medium confidence, problem validated, solution still in discovery. You believe this matters. You haven't proven the solution works.
• Later: opportunities, not solutions. Things you've heard from customers that haven't earned a slot yet.

If your "Later" bucket has feature names with effort estimates, you're doing RICE in a trench coat. If your "Later" bucket has customer problems with open questions, you're doing it right.

Confidence, the input nobody scores honestly

Every PM I've ever met inflates confidence on their pet feature. The person who built the framework's confidence column expecting it to be a calibration tool watches it become a vibes column.

The fix: a confidence rubric tied to evidence, not feelings.

Anything below 60% should not be in your Now column under any framework. Anything below 40% should be an Opportunity in your OST, not a feature on your roadmap. If you can't get to 60% confidence on something that's been on the roadmap for two quarters, kill it. The cost of leaving it there is the appearance of progress without the actual progress.

Why your stakeholders hate RICE

This is the diagnostic conversation I have with every team that says "RICE isn't working for us." It's almost never the framework. It's the translation layer.

Sales hates RICE because customer asks score low on Reach. Sales is bringing you the deal-blocking ask from the prospect that pays $80K. Reach for that customer is one. The RICE score is fractional. Sales reads this as "PM doesn't care about revenue." Translate: pull deal-blocking asks out of RICE entirely. Maintain a separate "deal blockers" lane sized to your win rate impact. Tell sales the lane exists.

CS hates RICE because retention bets score low on Impact. Retention features rarely show short-term metric movement. They prevent churn that would happen six months out. RICE Impact is forward-looking, but most PMs score it as quarter-over-quarter. Translate: separate retention bets and score Impact as annualized churn-rate movement, not quarterly activation.

Eng hates RICE because Effort is your guess, not theirs. PMs estimate effort based on similar past features. Eng knows the codebase has three landmines. Translate: never publish a RICE score with your own effort number. Use ranges (1-2 PM-months, 3-5 PM-months, 6+) and let eng tighten them after a brief scoping pass. The PM owns Reach, Impact, Confidence. Eng owns Effort.

The pattern: RICE gives one number, but the four inputs come from four different stakeholders. When you publish a single score and don't show your work, every stakeholder reads the input they care about and disagrees with it. Show the inputs. Argue about Reach with marketing, Impact with the data team, Confidence with research, Effort with eng. The score is the output of those four conversations, not a substitute for them.

When to mix all three

Here's the stack I actually run:

1. Use OST to find the right opportunity. Map outcomes to customer opportunities through continuous discovery. Pick the opportunity that has the strongest evidence and the highest potential outcome impact. Skip this layer if you already know the problem cold (mature features, well-understood domain). Don't skip it if your team is shipping features nobody asked for.

2. Use Kano to classify the solution. Once you've picked an opportunity and have two or three candidate solutions, run Kano on the candidates with real customer data. Skip this layer if the solution is obviously Basic (auth, export, accessibility). Don't skip it if you're choosing between "make existing feature faster" and "add a delight moment" and you can't tell which one customers will actually value.

3. Use RICE to sequence the build. Once you've chosen which opportunities and solutions to build, RICE sequences them across the quarter. Effort, dependencies, capacity. RICE is a sequencing tool, not a discovery tool. That's where it earns its keep.

The full stack is overkill for most teams most of the time. A team shipping incremental improvements to a mature CRM doesn't need OST every quarter — they need RICE on a clean backlog. A pre-product-market-fit startup doesn't need RICE — they need OST and a willingness to throw away half the roadmap. Match the framework depth to the actual epistemic situation. Forcing OST on a team with no research access is theater. Forcing RICE on a team that doesn't know its KPIs is precision without accuracy.

The framework isn't the answer. Pick the one that forces the conversation your team is avoiding. If your team is avoiding customer contact, run OST. If your team is avoiding cutting scope, run Kano. If your team is avoiding sequencing trade-offs, run RICE. And if your team is avoiding all three, the problem isn't the framework. The problem is that nobody wants to make a real decision, and no spreadsheet is going to fix that.

Learn More

• Product Manager JD (companion)
• Continuous Discovery Habits for PMs
• Writing PRDs Engineers Don't Hate
• Quarterly Planning with Eng + Design