Product manager behavioural interview questions

As asked

Tell me about a time you pushed back on a designer or PM's decision. What was the disagreement, how did you handle it, and how did it land?

Sample answer outline

Frame it as collaboration, not conflict. Describe the design or product call you disagreed with and why - usually a technical constraint (perf, a11y, browser support) or a UX concern (the design optimises a metric that doesn't help the user). Walk through how you raised it: bringing data or a quick prototype, not just opinions. Show that you listened to their side - sometimes you were partially wrong. Land on the resolution and what you both learned about working together.

Expect these follow-ups

• What if the designer still disagreed after your prototype?
• Have you ever pushed back and been wrong?
• How do you decide what is worth pushing back on vs what to let go?

As asked

Tell me about a feature you championed, shipped, and then killed. Why did you kill it and what did you learn?

Sample answer outline

Pick a real example - the interviewer is testing whether you can recognise sunk cost and write a feature off when it isn't working. Describe the original hypothesis, what metric you set as the kill threshold, and the data that came back. Show that you didn't drag it out by adding features hoping it would catch on. End with the process change: how you now structure features so the kill decision is clearer earlier.

Expect these follow-ups

• What was the politically hardest part of killing it?
• Could you have known earlier that it would fail?
• How did you communicate the kill to the engineers who built it?

As asked

Describe a time you disagreed with an engineering lead on the technical direction of a project. How did it resolve?

Sample answer outline

Set the scene briefly - what the disagreement was about. The strongest version is a real technical tradeoff where the engineer saw cost the PM didn't, and vice versa. Walk through how you both made your case (not 'I won them over'). Show curiosity about the engineering reasoning - the interviewer is testing whether PMs respect engineering judgement. End with what you both agreed and the working relationship that came out of it.

Expect these follow-ups

• What if you had been the engineering lead in this story?
• When does a PM overrule an engineering lead?
• How do you handle disagreements that don't get resolved cleanly?

As asked

You present a roadmap you believe in and a senior stakeholder, say a VP, pushes back hard and wants something different. Walk me through how you handle it in the room and afterwards, without either caving or digging in.

Sample answer outline

First, treat the pushback as information rather than an attack: get specific about what they object to and why, because a VP often has context you lack, a strategic shift, a commitment made elsewhere, a risk you cannot see. Reflect their concern back so they know they were heard, and separate the underlying goal from the specific solution they are proposing, since you may agree on the outcome and differ only on the path. In the room, avoid winning or surrendering on the spot; if it is a genuine data question, agree what evidence would settle it and follow up, rather than litigating opinions live. Afterwards, come back with the analysis, a revised plan that absorbs the valid concerns, and a clear articulation of the tradeoff if you still disagree, so the decision is made on merits. The signal is influence through understanding and evidence, the maturity to change your mind when they are right, and the spine to hold a well-supported position when they are not, all while keeping the relationship intact.

Expect these follow-ups

• How do you separate the stakeholder's goal from their proposed solution?
• What do you do when it comes down to a disagreement about data?
• When do you change your plan versus hold your position?

As asked

Marketing wants dashboards optimised around leads, sales wants pipeline, and customer success wants retention. How do you design a BI reporting suite that supports all three without fragmenting truth?

Sample answer outline

Separate shared company metrics from team-specific operating metrics. Build a small set of certified cross-functional measures, then let each team have dashboards that answer their workflow questions against the same governed dimensions. Facilitate metric definition sessions where tradeoffs are explicit, especially around attribution, ownership, and time windows. Document which dashboard is authoritative for which question, and retire duplicates that disagree. Interviewers want evidence that the BI engineer can mediate ambiguity rather than simply build every requested chart.

Expect these follow-ups

• How do you push back on a VP asking for a misleading metric?
• What makes a dashboard worth retiring?
• How do you measure whether the reporting suite is actually being used well?