Product interviews are unusual in that there is rarely a right answer. What is being assessed is how you reason: whether you ask before you answer, whether you can defend a decision, and whether you can say no. Structure matters more here than in any other role.
Last reviewed September 2026
Product manager interviews rarely have right answers. Expect prioritisation, a product critique, a metric question, and a situation where you have to say no to someone. What is assessed is structure: whether you ask about constraints before answering, and whether you can defend a decision you have made.
Asked in almost every product interview. They want a method you actually use, not a framework you have read about.
Name your method, apply it to something real, and be honest about where it breaks down.
I score by impact against effort, but the tie-breaker is confidence, because half our impact estimates were guesses. Where it breaks down is work with no user-facing impact, like paying down debt, so I ring-fence a fixed share of each cycle for it rather than letting it compete.
Tests whether you prepared, and whether you can criticise without being rude.
Show you have used it. Pick one specific thing, say who it hurts, and propose a change. Do not list ten.
I signed up yesterday. The step I struggled with was X, because it was not clear what happened next. If that is common, it costs you people who already wanted the product. I would test showing the result before asking for the commitment.
They want to know whether you investigate or immediately start adding.
Separate the possible causes before choosing a fix. Discovery, comprehension and desire are three different problems.
First, can people find it? Check whether they ever reach the screen. If they reach it and do not use it, it is comprehension or desire. Those need different fixes, and guessing wrong wastes a cycle. Five user calls usually answer it faster than the data will.
The job is largely this. They are listening for whether you say no with a reason or just absorb everything.
Say no to the timing, not the person, and show the tradeoff explicitly.
I show them what it would displace. Usually the conversation stops being about whether their thing is good and starts being about whether it beats the other thing, which is the right conversation. If it does win, it goes in and I tell the other team why.
Tests whether you can find the one number that actually reflects value.
Pick one primary metric, say why, and name a guardrail metric that stops you gaming it.
For this, completed sessions per active user, because it counts the thing people came for rather than logins. The guardrail would be support tickets per session, since you can lift usage by making something confusing enough that people retry.
They want a real one. A disguised humblebrag is obvious and costs you.
Pick something that genuinely failed, say what you misjudged, and what you changed about how you decide.
I pushed a redesign based on complaints from our loudest customers. It tested fine with them and dropped conversion for new users, who were the actual growth. I now check who is complaining before treating it as signal.
Usually asked because a previous PM did it badly.
Talk about bringing problems rather than solutions, and about being available.
I bring the problem and the constraint, not the design. Engineers usually find a cheaper path than the one I had in mind when they know what actually matters. And I try to be easy to interrupt, because a blocked engineer waiting on me is the most expensive thing in the process.
Tests commercial judgement, which many product candidates lack.
Tie it to whether the thing is core to your differentiation.
If it is what customers choose us for, build it. If it is necessary but nobody picks us because of it, buy it, because our version will be worse and cost more. Ignore is underused: plenty of requests are real but not worth what they cost.
A reasoning test. Nobody expects the right number, they want to see the workings.
Say your assumptions out loud, build up from a population, and sanity check the result.
I would start from the number of people in the role, estimate what share hit this problem often enough to pay, and multiply by a plausible price. Then check it against something known, because if my number is larger than an established company in the space, an assumption is wrong.
For product roles this is genuinely part of the assessment. Your questions reveal how you think.
Ask about how decisions get made, which tells you more than any answer about strategy.
How does something get onto the roadmap here, and who can take it off? And what is the last thing you decided not to build?
InvisiHire listens to your call and drafts what you could say next, using your own resume. Free to start, no card needed. Check your employer's or your institution's rules on assistance before you use it.
Start free See how it works