Getting hired as a product manager is strange because the job description varies wildly from company to company, and the interviews vary just as much. One company will give you a take-home case study. Another will ask you to design a product live on a whiteboard. Another will spend 45 minutes entirely on behavioral questions.
Despite the variation, every PM interview is evaluating the same underlying things. Once you understand what those are, you can prepare for any format.
What Every PM Interview Is Actually Testing
- 1Product sense — Can you think about products clearly? Do you understand users, problems, and trade-offs?
- 2Execution — Can you prioritise, break down work, and drive things to completion?
- 3Analytical thinking — Can you use data to make decisions? Do you understand metrics?
- 4Communication — Can you make complex things clear? Can you influence without authority?
- 5Leadership through ambiguity — When the problem isn't defined, can you define it?
The questions below are grouped by which of these things they're testing.
Product Sense Questions
Q1: "What's a product you think is poorly designed? How would you improve it?"
What they're actually testing
They want to see: Can you identify the root problem (not just surface symptoms)? Do you think about the user's context, not just the interface? Do you prioritise like a PM — understanding that you can't fix everything at once? Strong approach: Pick something you genuinely use. Name the specific friction point and who it affects. Propose one improvement with clear reasoning, not a list of five vague changes. Then explain the trade-off you'd make — what would you NOT fix first, and why?
Q2: "How would you improve [Company's product]?"
This is almost always asked. The trap is to launch immediately into features. The move: start with users.
Strong framework
"Before I suggest improvements, I'd want to understand who's using it and what they're trying to do. From my experience as a user [or from research], the main user types seem to be X and Y. The core job-to-be-done for X is [Z]. The biggest friction point in that job is [specific thing]. If I had to pick one area to improve, I'd focus on [specific thing] because it affects [audience size] users and [impacts core metric]. The improvement I'd explore is [specific change] — and the way I'd validate it is [quick test]."
Q3: "Should we build feature X?"
Strong framework
"I'd think about this across four dimensions: impact on users, impact on the business, technical feasibility, and strategic fit. Impact on users: what problem does this solve, and how many users have it? Impact on business: does it move a metric we care about (retention, revenue, acquisition)? Technical feasibility: what's the rough cost — is this a week or a quarter? Strategic fit: is this aligned with where the company is going in the next 12 months? Based on those four, I'd weight impact and strategy highest, because we can work around feasibility constraints but we can't fix a feature that doesn't solve a real problem."
Metrics and Analytical Questions
Q4: "What metrics would you use to measure the success of [feature/product]?"
Strong approach
Don't go straight to "DAU/MAU" unless you've thought through whether that's the right metric. The best PM answers structure it like this: What's the primary goal of this feature? (Acquire, retain, monetise, or improve experience?) Then: primary metric (the one number that tells us if it's working), secondary metrics (things that might move in service of the primary), and guardrail metrics (things we DON'T want to hurt). A feature designed to improve onboarding might have "7-day activation rate" as primary, "time-to-first-value" as secondary, and "churn at day 30" as a guardrail.
Q5: "Our key metric dropped by 15% last week. How would you investigate?"
Strong framework
"First, I'd verify the data — is this a tracking issue? Then I'd check the time range — did it drop gradually or suddenly? A sudden drop points to a specific event (a deployment, a marketing campaign end). I'd then segment: platform, geography, user cohort. A platform-specific drop points to a bug. A cohort-specific drop might point to an onboarding or acquisition change. Alongside that, I'd check the deploy log — what changed in the days before the drop? I'd also look at correlated metrics — if churn went up and activation went down, the problem is earlier in the funnel than if only churn changed."
Execution and Prioritisation
Q6: "You have 10 feature requests and time to build 3. How do you decide?"
Strong answer
"I'd use a scoring model, but the categories matter: impact on key metrics, confidence in that impact (how much evidence do we have?), effort (dev weeks roughly), and strategic alignment. I'd score each and sort them, then sanity-check the top 3 with engineering and design before committing. The real skill isn't the framework — it's having honest conversations about confidence. Most requests come in with the impact oversold. Good prioritisation means being sceptical and asking 'what would we need to see to believe this will work?'"
Q7: "How do you handle pushback from engineering on your priorities?"
Strong answer
"I try to understand why they're pushing back before I try to convince them. Often the pushback is valid — there's a technical dependency I wasn't aware of, or the estimate was optimistic. When I disagree, I'd share the data or user evidence behind the priority and ask what information would change their view. I've also learned that early collaboration on problem definition (not just solution definition) means engineering teams are more bought in from the start, which reduces late-stage conflict. The goal is to make them feel like co-creators of the roadmap, not executors of someone else's plan."
Behavioural Questions for PMs
Q8: "Tell me about a product you shipped that failed."
This is one of the most revealing questions in PM interviews. What they're looking for is self-awareness, intellectual honesty, and learning. "It didn't fail, it just didn't meet targets" is a yellow flag. "Here's exactly what happened, why it was my call, and what I'd do differently" is the answer that builds trust.
Q9: "Tell me about a time you changed your mind based on data."
Good PMs hold opinions loosely. They form a strong initial hypothesis, commit to measuring it, and update when the data disagrees. If your answer is "the data confirmed what I already thought," that's not a good story. The stories that impress are the ones where your assumption was wrong and you changed course.
Questions to Ask Them
PM interviews almost always include "do you have questions for us?" — and for PM roles, this matters more than in most roles because curiosity and strategic thinking are core competencies.
- "What's the biggest product bet the company is making in the next 12 months?"
- "How does the PM team interact with engineering and design? Is it embed or separate?"
- "What does the decision-making process look like for a major feature — who has the final call?"
- "What's a recent product decision that didn't go the way you expected, and what did you learn?"
- "How do you measure whether a PM is having high impact here?"
The Mindset That Gets PMs Hired
The PMs who get hired don't try to demonstrate that they know all the answers. They demonstrate that they ask the right questions, structure ambiguity well, and can make a clear argument for a decision while holding it loosely. If you've been in product for any length of time, you know that most of the job is exactly that — not being right, but being useful in a situation where nobody is certain.