Field Guide · Product Management

How to solve a product management case study interview

A structured approach to the case study questions that decide product management interviews — built from twenty years of shipping products, from a patented startup to platform strategy at scale.

By Aaron Dey · Senior Product Manager, Berlin

What the interviewer is actually scoring

A product management case study interview is not a test of whether you find the "right" answer. There isn't one. It is a window into how you think under ambiguity: whether you clarify before solving, structure a messy problem, make trade-offs explicitly, and tie everything back to a business outcome.

Interviewers typically score four things: problem framing (did you solve the right problem?), structured thinking (can others follow your logic?), user and business empathy (do you hold both at once?), and communication (would a team want to work through a hard problem with you?). Every step below maps to one of those dimensions.

A four-step approach that works for any case

Whether the prompt is "design a product for travellers" or "our activation rate dropped 20%", the underlying moves are the same.

STEP 01

Clarify before you solve

The most common failure mode in a case study interview is answering the wrong question confidently. Before proposing anything, pin down three things: the actual business goal (revenue, retention, reach, cost), the constraints (time, team, regulation, platform), and what success is measured against. Asking sharp clarifying questions is not a delay — it is the first demonstration of senior thinking.

Say it out loud:

  • ·What does success look like for the business in 6–12 months?
  • ·Which constraint is immovable — budget, timeline, or scope?
  • ·Who is the user, and who is the customer? (They are often not the same in B2B.)

STEP 02

Frame the problem, not the feature

Interviewers are testing whether you jump to solutions. Resist it. Restate the case as a problem statement: who struggles, with what, why it matters now, and what happens if nothing changes. A well-framed problem makes the solution space obvious and shows you can hold ambiguity without flinching.

Say it out loud:

  • ·What job is the user hiring this product to do?
  • ·Why is this problem unsolved today?
  • ·What is the cost of doing nothing?

STEP 03

Structure the solution space

Generate two or three genuinely different directions — not three versions of the same feature. For each, sketch the user journey, the business logic, and the risk. Then pick one and say why. The comparison matters more than the choice: it shows you evaluate trade-offs deliberately rather than falling in love with your first idea.

Say it out loud:

  • ·What is the cheapest version that proves the hypothesis?
  • ·What would make each option fail?
  • ·Which option compounds — builds platform value — rather than just shipping a feature?

STEP 04

Prioritise ruthlessly and define metrics

Every case study ends here: what do you build first, and how will you know it worked? Anchor prioritisation in impact versus effort, and tie metrics to the business goal from step one — one north-star metric, two or three guardrails. Avoid vanity metrics; name a number you would be willing to be wrong about.

Say it out loud:

  • ·What is the one metric that proves this worked?
  • ·What guardrail metrics protect against unintended harm?
  • ·What would you deliberately not build?

The case study questions that come up again and again

Most PM case study interviews draw from a small set of archetypes. Here's how to handle each one.

“Design a product for [a specific user group]”

Start with the user group's context and constraints, not feature lists. Define the core job-to-be-done, then walk through the smallest end-to-end journey that delivers it. Close with how you'd validate demand before scaling.

“How would you improve [a well-known product]?”

Pick one user segment and one friction point — improving everything is a red flag. Diagnose why the friction exists, propose a fix, and define the metric it moves. Bonus: mention what you'd protect while changing it.

“A key metric dropped 20% — what do you do?”

Structure the diagnosis: is it real (data quality), internal (release, pricing, UX change), or external (seasonality, competition, market)? Form hypotheses in that order and describe what data would confirm or kill each one.

“Should we enter this new market or build this new product?”

Treat it as an investment decision: market size and timing, your right to win, cost of entry, and the reversible/irreversible split. Recommend the cheapest experiment that reduces the biggest uncertainty.

“Tell me about a product you shipped that failed”

Own it. State the hypothesis, what actually happened, the signal you misread, and the rule you now apply. Interviewers score the learning loop, not the failure.

“Estimate the market size for [new idea]”

Do the arithmetic out loud, top-down and bottom-up, and sanity-check one against the other. The interviewer cares that your assumptions are stated and falsifiable, not that the number is right.

What separates a senior answer from a junior one

Think in systems, not screens

Junior answers describe UI. Senior answers describe the system behind it: data flows, incentives, second-order effects, and what the feature does to the rest of the product.

Name your trade-offs out loud

Saying 'we'd gain X but risk Y, and I accept that because Z' is worth more than any framework. Unacknowledged trade-offs read as inexperience.

Bring receipts

Abstract answers are forgettable. Anchor at least one answer in something you actually shipped — the churn risk you cut, the onboarding time you compressed from months to days, the migration you saved. Real numbers beat perfect structure.

Show how you work with others

Case studies are solo performances, but product management isn't. Mention where engineering, design, legal, or sales would change your answer — it signals you've actually run the gauntlet.

Know when to stop

A crisp, prioritized answer in 20 minutes beats an exhaustive one in 40. Senior PMs allocate time as deliberately as they allocate roadmap.

A practice case to try on yourself

“A video streaming service sees flat subscriber growth while its biggest B2B platform customers complain that integrating its API takes months. You're the PM. What do you do?”

Work it through the four steps: clarify whether the goal is subscriber growth or B2B retention (they may conflict), frame the real problem (developer onboarding friction as a growth bottleneck), structure options (self-serve docs and SDKs vs. solutions engineering vs. platform redesign), then prioritise by time-to-impact and define the metric — time-to-first-successful- integration is a good north star.

This prompt mirrors a real situation: compressing B2B onboarding from months to days by treating developer experience as a product, not an afterthought. If your answer would survive contact with real engineers and real renewal deadlines, you're ready.

One last thing

Frameworks get you to a competent answer. What gets you the offer is evidence that you've actually done the work — shipped, failed, measured, and learned. Prepare two or three real stories with real numbers, and let the structure serve them, not replace them.

Back to aarondey.com