Product manager interviews probe product thinking, comfort with metrics, and how you decide what not to build. Below are the most common questions with model answers. Middle: deeper understanding, optimization, and real-world situations.
RICE, ICE or weighted scoring all convert opinion into numbers you can compare. Where they break is that the inputs are estimates and the score inherits their error, so a confident guess about impact beats a cautious one regardless of truth. The value is not the ranking — it is that the disagreement becomes visible, usually on impact, and can be discussed instead of argued.
Being a task in disguise: 'as a user I want a dropdown' names a solution and hides the need. A usable story says who, what they are trying to achieve, and why, with acceptance criteria that make done unambiguous. The other failure is a story too large to finish in a sprint, which is how a board fills with things that are almost complete for weeks.
Segment before theorising: which cohort, which platform, which acquisition source, and when it started. A drop confined to new cohorts is usually onboarding or a change in traffic mix; across all cohorts at once is usually the product or an outage. Check what shipped, and check whether tracking changed — an analytics break looks exactly like a retention drop.
What it costs to acquire a customer, what they pay and for how long, and what it costs to serve them. From those three come payback period and the ratio that decides whether growth funds itself or consumes cash. The number people skip is cost to serve, which for anything with support or infrastructure is not small.
By moving the argument from preference to evidence: which outcome each request serves, what it is worth, and what the cost is. Escalation is a legitimate tool when the disagreement is genuinely about company priorities rather than about product detail. What does not work is building both, which is how a product acquires two half-features and no position.
No. A test costs traffic, time and attention, and some questions are answered more cheaply by looking at existing data or by talking to five users. Test when the decision is expensive to reverse, when the team genuinely disagrees, and when the sample makes a result possible — running a test that cannot reach significance is worse than not running it, because it produces a number people will quote.
The few numbers that would make you act: acquisition, activation, retention, revenue, and the one metric specific to what the product does. Not everything measurable — a dashboard of forty charts is read by nobody and hides the three that matter. Each metric should have an owner and a comparison, because a number without a baseline cannot be interpreted.
At the sample size and duration you fixed before starting. Peeking and stopping the moment it looks significant is how you ship noise — the false positive rate rises the more often you look. Run at least one full weekly cycle so weekday and weekend behaviour are both in there, and decide in advance what result would make you not ship, because a test you would ignore is not worth the traffic.
In rising order of cost: talk to people about the problem without mentioning your solution, show a prototype and watch where they stop, put up a landing page and count who asks for it, then run a concierge version where you do the work manually. Each answers a different question, and none of them is 'would you use this' — everybody says yes to that, which is why the useful signal is what people already do or pay for today.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Product Manager interview →