Product manager interview questions — why "how would you improve this product" has no right answer
PM interviews look unstructured compared to engineering rounds, but they're scored just as precisely. Here's what the classic prompts are actually checking, and where most candidates lose points without realizing it.
Engineering interviews have a visible rubric — the code either works or it doesn't. PM interviews feel looser, which leads a lot of candidates to prepare loosely too. That's a mistake: PM rounds are scored just as precisely, on a rubric that's simply less visible from the candidate's chair.
"How would you improve [product]?"
What most candidates do: jump straight to feature ideas. "I'd add a dark mode, a recommendation feed, better notifications."
What's actually being scored: whether you pick a direction before generating ideas. A strong answer starts by naming who the product serves and what they're currently failing to do — "let's assume we're optimizing for retention among users in their second week" — and then proposes ideas that follow from that framing. Skipping straight to features signals you'd do the same thing on the job: ship ideas without a stated goal they're supposed to move.
"Tell me about a product decision you disagreed with."
What most candidates do: describe the disagreement and how it was resolved, ending on a diplomatic note.
What's actually being scored: whether you can describe the other side's reasoning fairly before explaining why you still disagreed. A candidate who can only describe their own logic, and characterizes the other side as simply wrong, reads as someone who'll struggle to build consensus with engineering and design later. The strongest answers name the real trade-off the other side was optimizing for, and explain specifically why they weighted it differently.
"How do you prioritize a roadmap with limited engineering capacity?"
What most candidates do: name a framework — RICE, MoSCoW, value vs. effort — and stop there.
What's actually being scored: whether you can apply the framework to a specific, messy case rather than recite it. The interviewer usually follows up with a scenario designed to break a purely mechanical application of the framework — a low-scoring feature that a major customer is blocking a renewal over, say — to see whether you treat the framework as a tool or as gospel.
"Walk me through how you'd measure success for a feature you just launched."
What most candidates do: name a metric — engagement, conversion, retention — and move on.
What's actually being scored: whether you can name the metric's failure mode before someone else points it out. A metric like "time spent in app" can go up because the product got better, or because it got more confusing and users are struggling to complete a task. A strong answer names the counter-metric that would catch the difference.
"Tell me about a time you were wrong about what users wanted."
What most candidates do: describe a small miss, softened to sound minor.
What's actually being scored: whether you'll admit a real mistake, and more specifically, how you found out you were wrong. "We looked at the data and it wasn't working" is weaker than a story that names the specific signal that caught it — a support ticket pattern, a drop in a leading indicator, a user interview that contradicted the assumption. The signal is the part that shows real product instinct.
The pattern underneath all five
None of these questions have a single correct answer, which is exactly why they're hard to fake. What's being scored every time is whether your reasoning is visible and defensible — not whether you landed on the "right" feature, framework, or metric, but whether another PM listening could follow your logic and trust it under pressure.
Prepair asks PM questions scoped to your level and scores whether your reasoning held up, not just whether you named the right framework. Try a free interview — 3 a month, no signup required to start.