In this article
Before you start
Prioritisation questions come up across program manager interview questions. If you also prepare for adjacent roles, the project manager questions cover scope and schedule trade-offs from the same angle.
Why interviewers ask this
Prioritisation questions test whether you can say no with a reason. Program roles carry more requests than capacity, so the question shows how you turn a pile of requests into an order that people accept.
A weak answer names a favourite framework and describes its letters. A strong answer starts from the situation: is the date fixed, are the ideas comparable, does waiting cost money, and who must agree? It then picks a framework for that situation and says what the framework cannot see. A Staff-level answer adds that every score is an input to a conversation, not a verdict, and shows which assumption would change the order.
Prioritisation frameworks from first principles
- MoSCoW
- MoSCoW is a prioritisation technique that sorts work into Must Have, Should Have, Could Have and Won't Have this time, so a team with a fixed date can see what must ship and what can move. The letters stand for the four tiers, and the two lowercase o's only make the name pronounceable.
- Weighted Shortest Job First (WSJF)
- Weighted Shortest Job First is a prioritisation model that sequences work by dividing its relative cost of delay by its relative job duration, so work that is valuable and quick goes first. Both parts are relative scores, not money or calendar time, so it only compares items scored on the same scale.
In plain words
Imagine packing a small suitcase for a trip with a fixed departure time. You first pick what you cannot travel without. Then you compare the optional items by how much use they give for the space they take. Last, you decide which task to do first because waiting makes it more costly. Those are three different questions, and each has its own tool.
The analogy breaks in one place. A suitcase has a hard physical limit, while a team's capacity and the value of each idea are estimates that can be wrong.
In one precise sentence, a prioritisation framework is a repeatable way to turn estimates of value, size and urgency into an order, and each framework fixes a different question to answer.
Step 1: MoSCoW fits scope against a fixed date
MoSCoW fits scope against a fixed date. The Agile Business Consortium explains that in a Dynamic Systems Development Method (DSDM) project where time has been fixed, it is vital to understand the relative importance of the work to make progress and keep to deadlines.
A Must Have needs a hard test. The same page lists "Not legal without it", "Unsafe without it" and "Cannot deliver a viable solution without it". If a manual, painful workaround exists, the item is a Should Have or a Could Have, as Wishkit reports from the same guidance. That report says the guidance caps Must Haves at 60% of the effort in a timebox and puts Could Haves at about 20%. For a ten person-week timebox, that cap is 6 person-weeks.1
Won't Have means not in this timeframe, and the items are recorded to clarify scope. Many teams run these timeboxes as sprints, so sorting first and sizing the Musts carries into sprint planning.
Step 2: RICE ranks comparable ideas by value per person-month
RICE ranks comparable ideas by value per person-month. ProductPlan describes it as a framework with four factors: reach, impact, confidence and effort, developed by Intercom for its own decisions. Sources disagree on when it appeared: OpinionX dates Intercom's blog post to January 2018, while whichframework.org says 2016.
Reach is a count of people in a defined period. Effort is person-months, and as reported anything under one month is scored 0.5. Impact uses a fixed scale from 0.25 (minimal) to 3 (massive), per LogRocket. Confidence is 100%, 80% or 50%, so teams do not argue over exact percentages.
Whichframework notes that scores are comparable only within one list scored the same way, and that RICE is a practitioner heuristic, not a researched method. Treat the output as a conversation starter.
Step 3: WSJF divides cost of delay by job size
WSJF sequences work by cost of delay divided by job size. Cost of delay is the economic loss from finishing a piece of work later, and in the Scaled Agile Framework (SAFe) it is a relative score, not a money figure. SAFe's page names its parts as relative user and business value, time criticality, and risk reduction or opportunity enablement. Agility at Scale adds a modified Fibonacci scale of 1, 2, 3, 5, 8, 13 and 20.
Take two example epics from that page. The portal redesign has Cost of Delay 13 + 3 + 2 = 18 and duration 3, so WSJF is 6.00. The compliance migration has 8 + 13 + 5 = 26 and duration 5, so WSJF is 5.20.1 The migration has the higher cost of delay, yet the portal goes first.
Dividing by job size lets a smaller job outrank one with a higher cost of delay. The partner application programming interface (API) has the largest cost of delay, 29, yet scores only 3.63 and ranks third.1
Step 4: Kano describes how customers perceive features
The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Noriaki Kano, and Wikipedia summarises it as five categories of customer preference. Its roots are the 1984 paper by Kano, Seraku, Takahashi and Tsuji, "Attractive Quality and Must-Be Quality", in Hinshitsu (Journal of the Japanese Society for Quality Control), which the Wikipedia article cites. Kano describes how customers perceive features, and it uses a survey that asks a functional and a dysfunctional question about each feature. In the must-be category, doing it well leaves customers neutral, but doing it badly makes them very dissatisfied.
Step-by-step description
- MoSCoW protects scope against a fixed date.
- RICE ranks comparable ideas.
- WSJF sequences by delay cost over size.
- Kano describes customer perception.
- MoSCoW fits scope against a fixed date.
- RICE ranks comparable ideas by value per person-month.
- WSJF sequences work by cost of delay divided by job size.
- Kano describes how customers perceive features.
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
The numbers below mix a sourced WSJF example with invented RICE and MoSCoW inputs. The WSJF Cost of Delay totals and job sizes come from the Agility at Scale example; the RICE and timebox inputs are illustrative.1
| Quantity | Inputs | Result |
|---|---|---|
| WSJF, portal redesign | 18 / 3 | 6.00 |
| WSJF, compliance migration | 26 / 5 | 5.20 |
| WSJF, partner API | 29 / 8 | 3.63 |
| WSJF, internal tool automation | 16 / 8 | 2.00 |
| RICE, idea A (illustrative) | 2,000 × 1 × 80% / 2 | 800 |
| RICE, idea B (illustrative) | 500 × 3 × 50% / 1 | 750 |
| RICE, idea B at 80% confidence | 500 × 3 × 80% / 1 | 1,200 |
| MoSCoW, Must Have cap in a 10 person-week timebox | 60% of 10 | 6 person-weeks |
Text description of the diagram
- The portal redesign scores 6.00 and the compliance migration scores 5.20.
- Dividing by job size lets a smaller job outrank one with a higher cost of delay.
The portal redesign scores 6.00 and the compliance migration scores 5.20.1 The partner API scores 3.63 and the internal tool automation scores 2.00. A TPM still flags that a legal deadline on the migration may change the story, because time criticality is only one of three inputs.
For RICE, idea A has reach 2,000 people per quarter (illustrative), impact 1, confidence 80% and effort 2 person-months, so its score is 800. Idea B has reach 500, impact 3, confidence 50% and effort 1, so its score is 750. As scored, idea A is 800 and idea B is 750. At 80% confidence idea B rises to 1,200.1
Text description of the diagram
- As scored, idea A is 800 and idea B is 750.
- At 80% confidence idea B rises to 1,200.
Tempo says a low confidence score signals that a team needs more research and does not by itself kill an idea. So the TPM move is to name the assumption behind the 50%, find the cheapest way to test it, and rescore.
Trade-offs and edge cases
Each framework hides something. Check these before you pick one.
| Framework | Fits when | Blind spot |
|---|---|---|
| MoSCoW | the date is fixed | no value-per-effort ranking inside a tier |
| RICE | ideas are comparable | guesses for impact and confidence |
| WSJF | delay is costly | relative scores, not money |
| Kano | customer perception is unknown | needs a survey, no effort term |
Edge cases to name aloud:
- Dependencies. None of the formulas has a term for work that blocks other teams. A TPM adds that view by hand.
- Scores across lists. RICE scores only compare inside one list scored the same way.
- Everything is a Must. If Musts exceed the 60% guidance, the timebox is not credible, and the conversation is about scope or date.
- Sunk cost. WSJF ignores what has already been spent, so a half-done project gets no credit for the past.
- False precision. A decimal in a score implies accuracy the estimates do not have.
Reported practice varies on how strictly teams hold the 60% figure, and the percentage comes from secondary reports of the guidance, so state it as guidance.
Choosing a framework by context
A TPM chooses the framework by the constraint, not by habit. Use MoSCoW when the date is fixed, RICE when ideas are comparable and measurable, WSJF when delay is costly and work competes for the same capacity, and Kano when the open question is customer perception. Umbrex describes WSJF as stronger when time sensitivity and cost of delay matter, especially in portfolio settings. A mixed answer is normal: sort scope with MoSCoW, then score the Should Haves with RICE, and say which input you trust least. Name the constraint first, because the constraint decides which question the score has to answer. For requirement work behind these choices, see business analyst interview questions.
How a TPM layers dependencies and the critical path on a score
A TPM adds the order of work on top of the score. A dependency is a piece of work that must finish before another team can start its own, and the critical path is the longest chain of such dependent work, which sets the earliest date the program can finish. A framework score ranks each item alone, so it cannot see that a low-scoring enabler, such as a shared platform change, blocks three teams. That item can go first, because delaying it delays everything behind it.
A TPM also checks what the formulas leave out: whether the teams that share capacity can really run the top items at once, whether to start the riskiest unknown early so surprises appear while there is time to react, and whether the order serves the organisation's goals and the stakeholders who must agree to it. Say the score, then say what you changed and why. More role-specific practice is in the technical program manager interview questions.
How to answer it in an interview
How do you prioritise work as a technical program manager?
I pick the framework by the question. If the date is fixed, I use MoSCoW: we agree what is a Must, keep Musts at or below sixty percent of the effort, and say what is Won't Have this time. If I am comparing similar ideas, I use RICE, but I treat impact and confidence as guesses and show which guess changes the order. If delay is costly and teams share capacity, I use WSJF, dividing cost of delay by job size. I then reorder for dependencies, since a blocker for three teams can go first despite a lower score. Then I put the assumptions in front of stakeholders, so we argue about inputs, not rankings.
The spoken structure: name the situation, pick the framework, say what it cannot see, then say how you share the assumptions.
Common mistakes
- "I always use RICE." (wrong) It has no date or dependency term. (right) "I choose by situation: MoSCoW for fixed dates, RICE for comparable ideas, WSJF for delay cost."
- "Everything important is a Must." (wrong) A Must is something with no workaround, and Musts should stay at or below the 60% guidance. (right) "I test each Must against legal, safety and viability."
- "Won't Have means never." (wrong) It means not in this timeframe. (right) "It is recorded so scope stays clear, and it can return next time."
- "WSJF means do the biggest job first." (wrong) It divides by size. (right) "Short jobs with a high cost of delay go first."
- "The RICE score is objective." (wrong) Impact and confidence are guesses. (right) "It is a heuristic; I show the assumptions."
Follow-up questions
How do you prioritise as a technical program manager?
Name the constraint first: a fixed date, a shared team, a measurable metric or a customer question. Then choose the matching framework, and share the assumptions with stakeholders.
What is the difference between MoSCoW and RICE?
MoSCoW sorts work into tiers against a fixed timebox and answers what must ship. RICE gives each idea a number and answers which idea gives the most impact per person-month. MoSCoW has no value-per-effort ranking inside a tier, and RICE has no notion of a deadline.
When would you use WSJF instead of RICE?
Use WSJF when waiting has a cost and several jobs compete for the same capacity, especially in portfolio settings. Its cost of delay includes time criticality and risk reduction, which RICE lacks.
What do you do when a RICE score has low confidence?
Do not drop the idea. Find the cheapest research that would raise confidence, then rescore, because the confidence factor only discounts the score.
How do you prioritise when stakeholders disagree?
Make the inputs visible: show each score's reach, value, size and confidence, and ask which number each person disputes. The disagreement is then about an estimate. For the conversation itself, see how to answer stakeholder and leadership communication questions.
How do dependencies change your prioritisation order?
Dependencies can override the framework score. Work that blocks other teams sits on the critical path, so a low-scoring enabler may go first because delaying it delays everything behind it.
- Name the question first; the framework follows from it.
- MoSCoW protects a fixed date, and Musts stay at or below 60% of effort.
- RICE ranks comparable ideas, and its impact and confidence are guesses.
- WSJF divides cost of delay by job size, so a smaller job can outrank one with a higher cost of delay.
- Show the assumptions, because they matter more than the final number.
Sources
- Weighted Shortest Job First - Scaled Agile Framework — Scaled Agile, Inc., 26 Oct 2026
- What is MoSCoW Prioritization? — Agile Business Consortium, 26 Oct 2026
- RICE Scoring Model — ProductPlan, 26 Oct 2026
- RICE Score: Quantitative Feature Prioritization — whichframework.org, 26 Oct 2026
- RICE feature prioritization model — Think Insights, 26 Oct 2026
- RICE framework: prioritization made simple — LogRocket, 26 Oct 2026
- Calculating impact in RICE scoring — OpinionX, 26 Oct 2026
- RICE score prioritization framework — Tempo, 26 Oct 2026
- MoSCoW prioritization — Wishkit, 26 Oct 2026
- WSJF: Weighted Shortest Job First — Agility at Scale, 26 Oct 2026
- Weighted Shortest Job First — Umbrex, 26 Oct 2026
- Kano model — Wikipedia, 26 Oct 2026
