Product manager interview questions

As asked

Pick any product Google ships. Tell me how you would improve it. We're going to spend most of the conversation here.

Sample answer outline

Pick a clear user segment (e.g. cyclists in dense cities, not 'all users'). State what the current product does well and what it falls short on for that segment. Identify the underlying user need (e.g. cyclists don't want the shortest route, they want the safest route on a given day given traffic and weather). Propose 2-3 concrete improvements and explicitly trade them off. Pick one. State how you'd measure success and what could go wrong. The strong answer is opinionated, structured, and grounded in user empathy - not a feature list.

Expect these follow-ups

• Why this user segment over others?
• What metric would you NOT use?
• What would make you kill this feature six months in?

As asked

Pick an app you use often and tell me one thing you would improve about it. Walk me through who it helps and why it matters.

Sample answer outline

The early-career version rewards structure over polish. Pick one product and one clear user group, describe a specific frustration that group has, and propose one focused improvement rather than a list. Then say how you would know it worked, even a simple metric like more people completing the task. The interviewer wants to see that you start from a real user need, can be specific instead of vague, and can connect a change to an outcome. You do not need to weigh several options against each other yet; one well-reasoned idea grounded in a user problem is enough.

Expect these follow-ups

• Who exactly benefits from this change?
• How would you know if the improvement worked?
• Why this improvement rather than something else?

As asked

Before launching an A/B test, a PM asks how long it needs to run. Walk me through how you size it: what inputs you need, what the minimum detectable effect means, and the traps that make people stop too early.

Sample answer outline

Sizing comes from four inputs: the baseline rate of the metric, the minimum detectable effect you care about, the significance level, and the desired power. The minimum detectable effect is the smallest true change worth detecting, and smaller effects need dramatically larger samples, which is the lever most people underestimate. From those you compute the sample per arm, then divide by daily eligible traffic to get duration, and round up to whole weeks so weekday and weekend behaviour are represented rather than over-weighting whichever days you happened to catch. The trap is peeking and stopping the moment significance appears, which inflates false positives because you gave yourself many chances to cross the line; commit to the planned horizon, or use a sequential method designed for valid early stopping. Also resist declaring a flat result a win for the control too soon if the test was underpowered to begin with. The signal is treating duration as the output of a power calculation, not a guess.

Expect these follow-ups

• Why do smaller detectable effects need so much more traffic?
• Why round the duration to whole weeks?
• What is wrong with stopping as soon as the result looks significant?

As asked

A PM says activation is low and asks you to run user interviews. How do you decide whether interviews, usability tests, surveys, or product analytics are the right method?

Sample answer outline

Clarify the decision the research must inform before choosing a method. If the team does not know why users fail, start with analytics to locate drop-off and usability tests to observe the flow. Interviews help understand motivation and context, but they are weak evidence for measuring prevalence. Surveys can quantify patterns after qualitative work has generated good hypotheses. A strong researcher pushes back on 'run interviews' as a pre-selected method and builds a mixed plan that matches the risk, timeline, and confidence needed.

Expect these follow-ups

• What would you do if the PM needs an answer in three days?
• How do you avoid turning a usability test into a feature-request session?
• What decision would make a survey the wrong tool here?

As asked

A strategic customer says, 'We need a dashboard for operations', but cannot describe the workflow clearly. How do you get from that request to a useful shipped solution?

Sample answer outline

A strong forward-deployed engineer starts by observing the actual work, not collecting a feature wishlist. They identify the users, decisions, source systems, failure modes, and business metric the workflow should improve. The first version should be narrow enough to ship quickly, usually a thin vertical slice with real data and a clear owner on the customer side. The candidate should discuss expectation management, security review, data access, and how the learning feeds back into the core product. A common mistake is becoming a bespoke consultant and building a one-off surface that cannot be maintained.

Expect these follow-ups

• How do you tell whether this should become core product?
• What do you do when the executive buyer and daily users disagree?
• How do you avoid committing to a custom roadmap in the room?

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?