In this article
Before you start
This page sits inside the product manager interview guide.
Why interviewers ask this
Prioritization questions are commonly reported by candidates in PM rounds, in forms such as "you have five features and one team; what do you build first?" The question tests whether you can turn a messy list into a defensible order and say what would change your mind.
A weak answer names a framework and recites its letters. A strong answer states the goal first, picks a framework because it fits that goal, shows the ranking, and says where the estimates are weakest. A Staff-level answer adds that the score is an input to a decision, names a case where the framework would mislead, and says how the team would find out cheaply. The AI product manager questions page shows the same pattern with machine learning features.
Execution / prioritization frameworks from first principles
- Prioritization framework
- A prioritization framework is a repeatable method that scores or sorts candidate work against stated criteria, so a team can explain why one item comes before another instead of relying on opinion alone.
- Cost of delay
- Cost of delay is the value lost for each unit of time that a piece of work is not yet delivered, so it measures how much waiting hurts.
In plain words
Imagine packing for a trip with a small suitcase. You cannot take everything. So you rank items by how much you need them and how much room they take. A framework is a written version of that ranking. Someone else can then check your reasoning. The analogy breaks in one place. A suitcase has one clear limit. A product team has several: people, time and risk. The frameworks below each focus on a different limit.
In one precise sentence: a prioritization framework turns estimates into an order. The order is only as good as the estimates and the goal behind them.
What "execution" means in a PM interview
Execution questions in a PM interview test whether you can turn a goal into shipped work and make trade-off calls along the way. Prioritization is one form: choosing what to build first with limited people and time. Other forms ask you to set a goal and a success measure, to choose between two metrics that pull against each other, or to explain what you would do when a metric drops; the metrics interviews page covers that last variant. What they share is a spoken, defensible decision under constraints. The frameworks on this page are tools for the prioritization form, and the goal you state first decides which tool fits.
Step 1: Write the goal and the candidate list
The goal and the constraint come before any score. Write one sentence for each, such as "raise week-one activation this quarter with one team of five". List the candidates as features with one line each. Without the goal, "impact" has no meaning, because the same feature can be high value for retention and worthless for activation.
Input: an open-ended request. Output: a goal, a constraint and a list of candidates. A strong candidate says these aloud and asks the interviewer to correct them. You now have the frame that every framework needs, and the next step chooses among them.
Step 2: Match the framework to what you are optimizing
A framework must optimize what the goal names, and the common frameworks optimize different things. In the worked example below, single sign-on ranks last on RICE and first on WSJF because a signed deal waits on it.
- RICE (Reach, Impact, Confidence, Effort) scores each feature as reach times impact times confidence divided by effort, as described by Intercom. RICE ranks value per unit of effort.
- ICE (Impact, Confidence, Ease) is a lighter relative: ICE rates three things on a small scale and combines them, which is quick but rougher.
- Weighted Shortest Job First (WSJF) is the ratio of cost of delay to job size; the Scaled Agile Framework builds cost of delay from user-business value, time criticality, and risk reduction or opportunity enablement. WSJF sequences work by economics and timing.
- MoSCoW, short for Must have, Should have, Could have and Won't have this time, is a method from the Dynamic Systems Development Method (DSDM), maintained by the Agile Business Consortium, that sorts scope into four buckets for a fixed deadline.
- The Kano model is a method from Kano et al. (1984) that sorts features by how they affect satisfaction: must-be basics, one-dimensional (performance) features and attractive delighters, plus indifferent and reverse features.
RICE ignores timing, so a deadline-bound item can look weak. WSJF captures timing but has no separate reach term. Choosing the wrong one is the error.
Step 3: Score the candidates with RICE
RICE needs four inputs per feature. Reach is how many users the feature touches in a period. Impact is how much it moves the goal for each of them, taken from a small fixed scale you write down. Confidence is how sure you are of those numbers, as a percentage. Effort is the work in person-months. The formula is reach times impact times confidence, divided by effort.
Input: the candidate list and four estimates each. Output: one number per feature and a ranking. The scale is a team choice, so state yours before you score. Because every input is an estimate, the ranking is a hypothesis. A strong answer then asks which single estimate, if wrong, would change the top item. The worked example below runs five features through RICE, ICE and WSJF.
Step 4: Treat the score as an input and decide aloud
The decision is spoken aloud with its assumptions. After the ranking, look at where confidence is lowest and where the score and your judgment disagree. Name one thing you would do cheaply to check the weakest estimate, such as a fake-door test (a button that measures interest before anything is built) or five customer calls.
Then state the decision in one sentence: what you build first, what you defer and why. If the score and your instinct disagree, say so and explain which you trust and what evidence would settle it. Interviewers hear this as ownership. A framework gives you a shared language; it does not take responsibility for the call, and the interviewer wants to hear you take it.
Step-by-step description
- Write the goal and the candidates.
- Match the framework to the goal.
- Score and rank the candidates.
- State the decision aloud.
- The goal and the constraint come before any score.
- A framework must optimize what the goal names.
- The decision is spoken aloud with its assumptions.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Five features compete for one team's quarter. All numbers below are illustrative, invented for this page; they are not data from any company.1 The features are saved searches, an onboarding checklist, team workspaces, single sign-on (SSO) and dark mode.
RICE gives the onboarding checklist the top score: a reach of 9,000 per quarter, impact 0.5, confidence 0.9 and effort 1.5 person-months give 2,700.1 Dark mode scores 1,750, saved searches 1,600 and team workspaces 375.1 SSO has the lowest score, 320.1
| Feature | RICE score | ICE score | WSJF score |
|---|---|---|---|
| Saved searches | 1,600 | 288 | 6.00 |
| Onboarding checklist | 2,700 | 360 | 5.00 |
| Team workspaces | 375 | 90 | 2.38 |
| SSO | 320 | 224 | 7.33 |
| Dark mode | 1,750 | 180 | 4.00 |
For WSJF, rate each feature on an illustrative 1–10 relative scale for value, time criticality and risk reduction, add them for the cost of delay, and divide by job size.1 SSO rates 8, 9 and 5, a cost of delay of 22, and a job size of 3, so its WSJF score is 7.33.1 The reason is the scenario: a signed deal waits on SSO, which raises time criticality. RICE cannot see that, because it has no timing input.
Sensitivity matters too. If the onboarding checklist effort is really 3 person-months instead of 1.5, its RICE score halves to 1,350 and it falls from first to third.1 One doubled estimate reorders the list, which is why you say where confidence is weakest.
Text description of the diagram
- RICE gives the onboarding checklist the top score, 2,700.
- SSO has the lowest score, 320.
Trade-offs and edge cases
Every framework is a model, and each fails in a known way. Scores hide estimate error: the illustrative 2,700 comes from four guesses. Scores can be gamed, because people who want a feature can nudge reach or impact upward. Anchoring is a risk too: the first number spoken in a meeting pulls the others toward it.
Frameworks also answer different questions, so mixing them can help. A common pattern is to use RICE to rank a backlog, WSJF to sequence work with deadlines or dependencies, MoSCoW to cut scope for a fixed date, and the Kano model to check that you are not shipping only basics. The table below summarizes what each one optimizes.
Text description of the diagram
- RICE ranks value per unit of effort.
- MoSCoW sorts scope into four buckets.
Edge cases: a regulatory or security fix often ranks low on reach and impact yet must ship, so treat it as a constraint, not a candidate. Effort is not impact: a cheap feature is not valuable merely because it is cheap. With no data at all, use rough ordinal scales, say they are guesses, and plan a test. For a related judgment skill, see product sense questions; metrics interviews cover choosing the goal metric, and strategy and go-to-market questions cover the bigger bets.
How to answer it in an interview
You have five features and one team. How do you decide what to build first?
I start by stating the goal and the constraint, because a framework only means something against a goal. Say the goal is activation this quarter. I list the candidates and score them with RICE: reach times impact times confidence, divided by effort, so I get value per unit of effort. If one item has a deadline or a blocked customer, I check it with cost of delay, because RICE ignores timing. Then I treat the ranking as an input: I name my weakest estimate, say what would change the order, and recommend one thing to build first.
The spoken structure: goal and constraint, framework and why, the ranking, the weakest estimate, then the decision. A strong answer takes about a minute and leaves room for the interviewer to push back.
Common mistakes
- "RICE says feature B wins, so we build B." (wrong) The score is not the decision. (right) "RICE ranks B first; my weakest estimate is its effort, so I would verify that before committing."
- "I always use RICE." (wrong) One framework cannot see timing or scope limits. (right) "RICE for value per effort, WSJF when timing matters, MoSCoW when the date is fixed."
- "I scored impact on a different scale for each feature." (wrong) The scores stop being comparable. (right) "I fix one impact scale before scoring and use it for every feature."
- "I did not state a goal; I just scored." (wrong) Scores are meaningless without a goal. (right) "The goal is activation, so impact means movement in week-one activation."
- "The stakeholder wants it, so it ranks first." (wrong) Opinion replaces the framework silently. (right) "I add the stakeholder's evidence to the estimates and rescore openly."
Follow-up questions
What is the best prioritization framework for product managers?
No single framework is best for every goal; the best one optimizes what the goal names. Use RICE to rank by value per unit of effort, WSJF when delay has a real cost such as a deadline or a blocked customer, and MoSCoW when a date fixes the scope (it sorts into buckets and has no formula).
What is the RICE framework?
The RICE framework scores a feature as reach times impact times confidence, divided by effort, so it ranks features by value per unit of effort. Its inputs are estimates, so treat the score as a starting point for discussion, not the decision.
How do you prioritize features in a PM interview?
State the goal and the constraint, list the candidates, pick a framework that fits the goal, score and rank, then name your weakest estimate. Finish by saying aloud what you build first and what you defer.
How do you prioritize when everything is urgent?
Ask what is lost per week of delay for each item and by whom; that is cost of delay in plain words. Items with the largest loss per unit of effort go first, and "urgent" items with no stated loss move down.
What do you do when a stakeholder disagrees with the score?
Ask which input they dispute, reach, impact, confidence or effort, and rescore with their evidence in the open. If the disagreement stays, propose a small test that would settle the disputed estimate. PM behavioral questions often probe this kind of conflict.
How do you prioritize with no data?
Use coarse scales, label every input a guess, and rank by confidence as well as by value. Then pick the cheapest experiment, such as customer calls or a fake-door test, to improve the weakest guess. More PM practice questions are in the product manager question guide.
- Execution / prioritization frameworks turn estimates into an order; the goal comes first.
- RICE ranks value per unit of effort, WSJF sequences by cost of delay, MoSCoW sorts scope, and Kano sorts satisfaction types.
- The same features can rank differently under different frameworks.
- Every score rests on estimates, so name the weakest one and how to test it.
- State the decision aloud; the score is an input, not the decision.
Sources
- RICE: Simple prioritization for product managers — Intercom (accessed 2026-10-26), 26 Oct 2026
- Weighted Shortest Job First (WSJF) — Scaled Agile Framework (accessed 2026-10-26), 26 Oct 2026
- MoSCoW Prioritisation — Agile Business Consortium (accessed 2026-10-26), 26 Oct 2026
- Attractive Quality and Must-Be Quality (Hinshitsu 14(2), doi:10.20684/quality.14.2_147) — Japanese Society for Quality Control (Kano et al.), 1 Apr 1984