Product Manager Interview Prep
Strategy, prioritisation, stakeholder management, technical fluency.
General tips for this role
- Have one strong product story ready: what you built, why, what you learned.
- Know one framework deeply rather than naming 10. CIRCLES, RICE, AARRR are all good.
- Have opinions about products you use. PM interviews love 'what would you change about app X?' questions.
- Tech fluency matters: be able to read a system architecture diagram. You don't need to code.
- Be data-driven but not data-blind. Sometimes the right call is qualitative.
Why do you want to be a product manager?
Show model answer
Honest + specific. 'I love sitting between engineering, design, and business. I love that PM is the role where you have to be curious about everything — users, tech, market, design. I want to build things people actually want, and that needs all those perspectives.' Avoid generic 'I want to make impact' answers.
Tie it to a specific experience that proves you're suited for it.
How would you improve [a product the company makes, or a popular product like Google Maps]?
Show model answer
Structure beats brilliance. (1) Clarify: who are the users? What is the success metric? (2) Identify pain points — through user types or user journeys. Pick 3-5. (3) Brainstorm solutions for each. (4) Prioritise: impact vs effort matrix. (5) Pick top 2-3. (6) Define success metrics. Always close with: 'I'd validate with users before building.'
Frameworks: CIRCLES, AARM, OKRs. Pick one and use it consistently.
How would you measure success of a new feature?
Show model answer
(1) What is the goal? Engagement, revenue, retention, support reduction? (2) Pick a North Star metric tied to that goal. (3) Pick supporting metrics: adoption (% of users who try it), activation (% who use it successfully), retention (% still using after 30 days). (4) Watch counter-metrics: don't celebrate adoption if churn goes up. (5) Compare to a control group: A/B test the rollout. (6) Set a target before launch. (7) Review at 30 days.
Mention counter-metrics — many PMs forget them.
Your team is behind on a launch. What do you do?
Show model answer
(1) Understand WHY behind. Scope creep? Underestimation? Bugs? Blockers? (2) Talk to the team — get their honest assessment of what's left. (3) Options: cut scope (preferred — ship something smaller on time), delay (next preferred), add resources (worst — adding people slows things down further). (4) Decide WHO needs to be informed and when. (5) Communicate early, before stakeholders ask. (6) Postmortem after: was the original estimate wrong? Why? How do we prevent next time?
Tell me about a time you said no to a stakeholder.
Show model answer
STAR. Show: you considered their request fairly, explained the trade-off clearly, offered an alternative when possible, and the result was good even though they didn't get what they asked for. Good PMs say no constantly. Bad PMs say yes to everyone and ship a bloated product.
Best answer involves a senior stakeholder. Shows backbone.
How do you prioritise your roadmap?
Show model answer
Frameworks: RICE (Reach × Impact × Confidence / Effort), Kano model, MoSCoW. Pick one. Walk through how you applied it on a real project. Show that you involve engineering (for effort estimates), data (for impact estimates), and users (for what to even consider). Roadmap is not a wishlist — it's a forced ranking under constraints.
Concrete examples beat abstract frameworks.
Your CEO wants to add AI to your product. How do you respond?
Show model answer
Don't dismiss. Don't blindly comply. Investigate. (1) What problem is the CEO trying to solve? Differentiation, retention, sales narrative? (2) Where in the product would AI add real user value vs feel like a marketing checkbox? (3) Prototype 2-3 options in a week. (4) Validate with users. (5) Bring data back to the CEO with a recommendation. Frame as 'here's what would actually move metrics' rather than 'no, that's a bad idea'.
Tests whether you push back well or just say yes to executives.
Engineering says a feature will take 6 months. You promised stakeholders 2 months. What do you do?
Show model answer
Don't try to bargain engineering down — they probably have a reason. (1) Understand why 6 months (architecture changes, dependencies?). (2) Can the feature be split? Ship a v1 in 2 months that delivers 60% of value? (3) Are there hidden assumptions (research, design)? (4) Update stakeholders honestly. (5) Lesson: never commit to dates before engineering has scoped. Postmortem your own process.