You have 100,000 users. Your team can help 10,000 of them today. The interviewer asks who gets help. What they are listening for is whether you can spend a scarce resource on purpose.
This is a common product management prioritization problem: deciding how to allocate limited resources while balancing user impact, urgency, and cost. In product manager interviews, the goal is not just to rank users but to explain why one decision creates more value than another.
The reflex is to sort the queue by whoever is loudest, whoever is easiest, whoever wrote in most recently, or whoever looks largest on a slide by themselves. Those picks are easy to defend in the room. They make a weak policy. Ask a narrower question instead: given what you actually have, where does the next hour create value you would not get from a cheaper path?
Start with what is scarce
Before you rank anyone, name the thing you are short of. It might be engineering time, support seats, inventory, sales coverage, budget, compute, or people who can physically show up. The ranking changes when the bottleneck changes. A team of two engineers and a team with spare capacity are not having the same conversation, even when the user list is identical.
Say the constraint in the first minute. It tells the interviewer you are allocating a resource.
Five questions, then a judgment
Once the constraint is named, walk five questions. You are making the reasoning visible, not building a scoreboard.
Multiply them into a score only when the prompt gives you numbers, or when one comparison is enough to make the choice obvious. In most answers, one of the five is doing the real work. Say which.
A large potential value can still be the wrong call
Take two users and the same hour of specialist time. User A is worth Rs 10,000 if you succeed, and you will succeed about 10 percent of the time. User B is worth Rs 4,000, with about an 80 percent chance. A slide that only shows potential value puts A first. Run the expected value and B wins: about Rs 1,000 for A, about Rs 3,200 for B.
Then subtract the alternative. The figure that matters is what you gain over the next-best cheaper option, not the gross number. A specialist who only does what a help article already does is an expensive way to feel helpful.
Ask which channel earns its cost
Most support problems can be met at more than one altitude. The customer fixes it. A bot or an article gets them there. Someone on the phone closes it. A specialist takes the seat. "Who deserves a specialist?" sounds fair and answers a different question. The product question is: for which users does that specialist change the outcome by more than the seat costs?
If they can solve it, send them to self-service. If a cheap channel will do, use that. Escalate when the extra touch changes the result by more than it costs, and leave it there otherwise.
Worked example: Ten specialists and a Thousand open cases
The interviewer says you run support. Ten specialists, a thousand unresolved cases. Who do they take?
Name the constraint first: specialist hours. Assume, out loud, that a specialist closes about eight cases a day. Arrival order then puts the back of the queue roughly twelve days out. That wait is what the policy is managing.
Pull a case forward when three things are true together. The issue is severe or on a clock, a payroll failure on payday, an admin locked out before a launch. A cheaper channel has already failed, or plainly will not work. And the specialist's chance of actually resolving it is high. A furious enterprise logo with a how-to question the help center already answers stays in the cheap queue. A quieter, smaller account with a broken payment integration, no self-serve path, and money leaking the same day moves up.
Leave account revenue alone as the sort key. It looks rigorous, and it spends the scarce seats on people who already have other ways to get unblocked. Leave pure first-in, first-out alone too. It feels even-handed, and it spends specialists on cases a macro would have closed.
Say the trade-off while you are still in the answer. Some large customers will wait, and some of them will call their account team. Take that heat against a written rule. Try the rule for two weeks on one pod. Watch specialist hours per resolved case, the reopen rate, and the share of severe cases still open after 24 hours. If severe cases age out while easy high-value tickets clear, the rule is wrong: tighten the severity gate. If account teams flood the queue with exceptions, add a separate expedite path with a weekly cap, so the exception does not become the policy.
Establish the Fairness Baseline
Any ranking leans. It leans toward people who write clearly, who are online when you are, who pay more, or who know which alias to escalate to. Before you lock the rule, name who never reaches the top of the queue, and decide whether that is acceptable for this product.
Safety issues, fraud, and anything with a regulatory clock jump the line. They are limits, from the fifth question, and they sit outside the trade-off. Everything else you should be able to explain without flinching.
Critical Failure Points
Revenue-only sorting is the first one. High-value users matter, and they are not the only users the product has promised something to. Clearing the easy tickets so a dashboard moves is the second. The metric looks healthy while the hard cases sit. Forgetting opportunity cost is the third: an hour on one case is an hour you did not give to another. Treating every user as identical is the fourth. A password reset and an outage do not have the same claim on a specialist. Equal treatment and a fitting decision are different jobs.
Say it as an answer, not a framework
When you hear "how would you prioritize?", hold the spreadsheet for a minute. Say what you are trying to increase, what you do not have enough of, and what you will not spend the scarce thing on because a cheaper path exists. Then pick. Offer the assumption you are least sure about, and say what you would change if the interviewer corrects it.
Understanding prioritization frameworks is only the first step. Practice explaining your decisions, defending trade-offs, and adapting when an interviewer challenges your assumptions with a product management mock interview.
https://www.pmmockr.com/
Is a Metric Necessary?
Only if the numbers are in the prompt, or you can estimate one comparison out loud without pretending it is precise. Walk through a single pair, the way User A and User B work above, then commit. A full leaderboard is not the point.
Bottleneck Blindspots
Say the assumption in the first minute. If the interviewer tells you the scarce thing is engineering time rather than support seats, rebuild the policy around that. The miss is recoverable. Defending the original ranking after the constraint has changed is the failure.
RICE, ICE, or Matrix: Pick Your Framework
Use the pieces if they help you keep the five questions in order. Interviewers can hear a framework being recited. They are listening for the constraint, the option you turned down, and what you would do if you were wrong.
Ready to practise your product management interview skills? Work through realistic interview scenarios with PMMockr, explain your reasoning, and prepare to handle follow-up questions.
https://www.pmmockr.com/blogs/how-to-prioritize-growth-bets-in-a-product-strategy-case
https://www.pmmockr.com/blogs/how-to-answer-influence-without-authority-for-product-managers
https://www.pmmockr.com/blogs/how-to-prioritize-product-design-ideas-in-a-pm-case-interview
https://www.pmmockr.com/blogs/how-to-define-milestones-for-a-product-launch-interview-answer