RICE, MoSCoW and Kano: Prioritization Frameworks for PM Interviews

Every product manager has more ideas than time. That’s why “you have three features and room for one, which do you build?” is a favourite PM interview question, and why prioritisation frameworks exist. RICE, MoSCoW and Kano are the three you’re most likely to hear about. This guide explains each one with a worked example, compares them, and gives you a structure for answering prioritisation questions out loud.

The short answer: the three most common prioritization frameworks are:

1. RICE: score each idea by Reach × Impact × Confidence ÷ Effort, then rank by score. Best for comparing many ideas with some data behind them.
2. MoSCoW: sort requirements into Must have, Should have, Could have and Won’t have (this time). Best for agreeing scope against a fixed deadline.
3. Kano: group features by how they affect customer satisfaction: basic expectations, performance features and delighters. Best for understanding what customers expect versus what will surprise them.

In interviews, the framework matters less than how you apply it: clarify the goal, use the framework on the real options, then sanity-check the answer.

Why frameworks matter (and where they don’t)

A framework does three useful things:

• Makes your reasoning visible, so others can challenge the inputs rather than argue about opinions.
• Forces you to think about cost, not just value. Exciting ideas often turn out to be expensive.
• Makes decisions repeatable, so the backlog isn’t driven by whoever spoke last.

But frameworks aren’t a substitute for judgement. A score can’t see strategy, dependencies, legal deadlines or the fact that the CEO promised a customer something. Good PMs use the framework to start the conversation, not end it.

RICE

What it is

RICE was developed at Intercom and shared by product manager Sean McBride in 2016. You score each idea on four factors:

Factor	Question	Typical scale
Reach	How many people will this affect in a set period?	A real number, e.g. users per quarter
Impact	How much will it affect each person?	3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence	How sure are you of these estimates?	100% = high, 80% = medium, 50% = low
Effort	How much work will it take?	Person-months (or person-weeks)

RICE score = (Reach × Impact × Confidence) ÷ Effort

Worked example

You’re the PM for a fitness app. Three ideas are competing for next quarter:

Idea	Reach (users/quarter)	Impact	Confidence	Effort (person-months)	RICE score
Simplify onboarding from 6 steps to 3	40,000 (all new users)	1	80%	2	16,000
Add Apple Watch workout sync	8,000	2	50%	4	2,000
Social challenges with friends	20,000	2	50%	6	3,333

Onboarding wins comfortably. It’s not the most exciting idea, but it reaches every new user, the team is fairly confident about it, and it’s cheap. That’s exactly the kind of result RICE is good at surfacing.

Strengths and weaknesses

Strengths: forces you to think about reach and effort, works for comparing many ideas, and makes confidence explicit so wild guesses get discounted.

Weaknesses: impact and confidence are still judgement calls; it ignores strategic fit and dependencies; and it favours small, safe improvements over big bets that are hard to estimate.

When to use RICE

When you have a long backlog of independent ideas, some data on usage, and a team that needs a transparent way to rank them.

MoSCoW

What it is

MoSCoW was created by Dai Clegg in the 1990s and became popular in agile project methods. You sort every requirement into one of four buckets:

• Must have: without it, the release fails or isn’t legal, safe or usable. If you’d delay the launch rather than ship without it, it’s a must.
• Should have: important and valuable, but the release still works without it, perhaps with a workaround.
• Could have: nice to have; included if there’s time.
• Won’t have (this time): explicitly out of scope for now. Writing these down is just as important as the musts.

A common guideline is that musts shouldn’t take up more than about 60% of the available effort, so there’s room to absorb surprises.

Worked example

You’re launching a first version of a restaurant booking feature in four weeks.

• Must have: pick a date, time and party size; confirmation email; restaurant can see bookings; cancel a booking.
• Should have: reminder 24 hours before; edit a booking.
• Could have: special requests field; add to calendar button.
• Won’t have (this time): deposits and payments; waitlist; table selection on a floor map.

Now everyone, from engineers to sales, knows exactly what’s in version one and what isn’t.

Strengths and weaknesses

Strengths: simple, fast and easy for non-technical stakeholders to understand; great for fixed deadlines; the “won’t have” list prevents scope creep.

Weaknesses: doesn’t rank items within a bucket; everything tends to drift into “must” without discipline; no built-in consideration of effort.

When to use MoSCoW

When the deadline is fixed and you need to agree on scope with stakeholders, such as an MVP, a release or a client project. It pairs naturally with defining an MVP and writing a product requirement document.

Kano

What it is

The Kano model was developed by Professor Noriaki Kano in the 1980s. Instead of scoring ideas, it classifies features by how they affect customer satisfaction:

• Basic (must-be) features: customers expect them. Having them doesn’t impress anyone, but missing them causes real frustration. A hotel room with clean sheets.
• Performance features: the better they are, the happier customers get, roughly in proportion. Faster Wi-Fi, a bigger room.
• Delighters (attractive features): unexpected extras that create delight; their absence isn’t noticed. A handwritten welcome note and free late checkout.
• Indifferent features: customers don’t care either way.
• Reverse features: some customers actively dislike them. An automated wake-up call nobody asked for.

An important twist: delighters become expectations over time. Free Wi-Fi in hotels was once a delighter; now it’s basic.

How it’s measured

Kano uses a survey with paired questions for each feature:

• “How would you feel if the product had this feature?”
• “How would you feel if the product did not have this feature?”

Answers (I like it, I expect it, I’m neutral, I can tolerate it, I dislike it) are combined to place each feature in a category.

Worked example

For a food delivery app:

Feature	Kano category
Accurate delivery time estimate	Basic
Live order tracking on a map	Performance
Faster delivery	Performance
A free dessert on your birthday	Delighter
Cooking videos in the app	Indifferent

The lesson: fix any missing basics first, invest in the performance features that matter most to your users, and add a delighter or two to stand out.

Strengths and weaknesses

Strengths: grounded in customer research; shows that not all features add satisfaction in the same way; great for product strategy and positioning.

Weaknesses: surveys take time; it doesn’t account for effort or cost; categories shift over time and between customer segments.

When to use Kano

When you’re deciding what kind of product to build, refreshing a product’s feature set, or trying to explain to stakeholders why a “boring” feature matters more than a shiny one.

RICE vs MoSCoW vs Kano: comparison

	RICE	MoSCoW	Kano
Type	Numeric scoring	Categorising by necessity	Categorising by customer satisfaction
Best for	Ranking a long backlog	Agreeing release scope	Understanding customer expectations
Considers effort?	Yes	Not directly	No
Needs data?	Usage estimates	Stakeholder agreement	Customer survey
Speed	Medium	Fast	Slow
Main risk	False precision	Everything becomes a “must”	Ignores cost

Using the three frameworks together

They aren’t rivals. In practice, many teams use them at different stages of the same decision:

1. Kano to understand. Run a quick Kano survey or use support data to learn which features customers see as basic, which as performance and which as delighters. Any missing basics jump the queue.
2. RICE to rank. Score the remaining ideas so the team can compare them on reach, impact, confidence and effort.
3. MoSCoW to commit. Once the quarter’s or release’s theme is chosen, sort the detailed requirements into must, should, could and won’t so everyone knows what’s in scope.

For example, a banking app might learn through Kano that instant transfer notifications are now a basic expectation (customers are frustrated without them), while spending insights are a performance feature and a savings round-up game is a delighter. Notifications get built first, regardless of score. Then RICE compares spending insights against other performance work. Finally, MoSCoW sets the scope for the version that ships this quarter.

Common prioritisation mistakes

• Trusting the score blindly. A RICE score of 16,000 vs 15,500 isn’t a meaningful difference. Treat close scores as a tie and use judgement.
• Inflating impact and confidence. Everyone’s pet idea is “massive impact, high confidence”. Ask for evidence: data, research or a past result.
• Ignoring effort until too late. Ask engineering for rough sizing early, even if it’s just small, medium or large.
• Forgetting dependencies. A high-scoring idea that needs another team’s work first may not be possible this quarter.
• Prioritising features instead of problems. Rank the problems first; the best solution to the top problem may not be on the list yet.
• Never saying no. A prioritised list that doesn’t drop anything isn’t prioritised. The “won’t have” list is where focus comes from.

Other frameworks worth knowing

• Value vs effort matrix: plot ideas on a 2×2 grid. Quick wins (high value, low effort) go first; time sinks (low value, high effort) get dropped.
• ICE: Impact × Confidence × Ease, a lighter version of RICE popular with growth teams.
• Weighted scoring: score ideas against several criteria with weights that reflect strategy.
• Opportunity scoring: ask customers how important an outcome is and how satisfied they are today; big gaps are opportunities.
• Cost of delay / WSJF: prioritise by how much value you lose for every week something isn’t shipped.

How to answer prioritization questions in a PM interview

Typical prompts: “You have these three features. Which do you build first?”, “How do you prioritise your roadmap?”, “Engineering can only do one of these this quarter.”

A six-step structure

1. Clarify the goal. “What’s the company trying to achieve this quarter: growth, retention or revenue?” The right answer depends on it.
2. Clarify constraints. Team size, deadline, dependencies, anything already promised.
3. List the options, and suggest one the interviewer didn’t mention if it’s obviously better.
4. Pick a framework and say why. “Since we’re comparing independent ideas and we have some usage data, I’ll use a quick RICE.”
5. Apply it with rough numbers, out loud. Rough is fine; showing the reasoning is the point.
6. Sanity-check and recommend. “RICE favours onboarding. That also fits our retention goal and doesn’t depend on any other team. I’d build it first. I’d revisit if we learned that the watch sync was blocking a big partnership.”

What interviewers listen for

• You tie the decision to a goal, not to personal preference.
• You consider cost, not just value.
• You’re honest about uncertainty.
• You end with a clear recommendation rather than “it depends”.
• You know when a framework’s answer should be overridden, and say why.

For the rest of the PM vocabulary, see 10 terms you should know before a product management interview, and for the metrics side, what are KPIs.

Prioritise your job applications the same way

RICE works on a job search too. Reach is how well a role matches your experience, impact is how much you want it, confidence is how likely you are to get an interview, and effort is how much work the application takes. High-fit, high-want roles deserve a carefully tailored resume and a cover letter, not a one-click apply.

Tailr brings the effort down: the Chrome extension tailors your resume to the job listing you’re viewing, drafts a matching cover letter and tracks each application, so you can give more roles the full treatment.

Try Tailr

Related guides

• What Is a Product Roadmap? Types, Examples and How to Build One
• Product Sense Interview Questions: How to Answer With Examples

Conclusion

RICE ranks ideas with numbers, MoSCoW agrees scope against a deadline, and Kano explains how features affect customer satisfaction. Learn one worked example for each, know when you’d pick it, and in interviews always start from the goal and finish with a clear recommendation. The framework is your scaffolding; the judgement is what gets you the offer.