You’re 25 minutes into the interview. You’ve walked through your last project without stumbling. The interviewer nods, closes their notebook, and says, “Great. Let’s try something different.”
This is where the product manager case study interview really begins: no slide deck, no prep time, no answer key, just a problem and someone watching how you think. Many good candidates lose offers here, not for lack of intelligence but because nobody told them what the interviewer is looking for.
Suppose you’re asked: Swiggy orders dropped by 30% in Bangalore. How would you approach this?
Take ten seconds before reading on. Most candidates open with a theory: “Maybe it’s the rain.” That’s a weak start, because you’ve picked an answer before you know what you’re solving. We’ll work this exact question in the RCA section below.
This guide covers the round end to end: the five question types, a framework for each, 56 practice questions and four worked examples. For the broader interview, start with PM interview questions with answers.
Interviewers assess your reasoning, not just the answer. They typically look for four things:
These are habits, and they can be practised.
Each type is a compressed version of something PMs really do. One company can ask all five, so here’s how the first move changes within Swiggy. These examples show the shift; they aren’t taken from any company’s interviews.
| Type | Example question | First move | What the interviewer watches |
|---|---|---|---|
| Guesstimate | How many orders does Swiggy deliver in Bangalore on a weekday? | Pick top-down or bottom-up and state assumptions | Is your logic easy to follow and sanity-checked? |
| Root cause analysis | Orders dropped 30% in Bangalore | Clarify the metric, then find the stage and segment | Do you narrow before you theorise? |
| Product design | Design a way for office teams to order lunch together | Choose one user and name their real problem | Do you understand a person before proposing anything? |
| Product improvement | How would you improve delivery for late-night orders? | Choose which part to improve and say why | Can you pick one thing worth fixing? |
| Metrics | How would you measure a new one-tap reorder feature? | State the goal, then the action, then one metric plus a guardrail | Does your number match your goal? |
Once you can name the type in the first ten seconds, you know which tool to reach for.
The real task: sizing an opportunity before anyone builds anything. These case study questions test whether you can build a number out of stated pieces, like “How many food delivery orders happen in Mumbai on a rainy Friday?” Practise with our guesstimate case studies.
The real task: the red number on a Monday morning dashboard. Interviewers want to see you narrow the problem before you explain it, as in “Swiggy orders dropped by 30% in Bangalore.” Practise with our RCA case studies.
The real task: a brief for something that doesn’t exist yet, like “Design Google Home Mini for blind users.” The case study question is really asking whether you understand a person before you propose anything. Practise with our product design case studies.
The real task: deciding what an existing product should do next quarter, which means picking one thing worth fixing out of the twenty you could name. A typical prompt is “How would you improve YouTube for creators?” Practise with our product improvement case studies.
The real task: deciding how you’ll know a launch worked, before it launches: goal, then action, then a metric with a guardrail. A typical prompt is “What metrics would you use for YouTube’s recommendation algorithm?” Practise with our metrics case studies.
A product manager case study interview framework is a scaffold, not a script. It gives you somewhere to put your thoughts, so you can think about the problem instead of what to say next.
Top-down starts with a large number you roughly know and narrows it. Bottom-up starts with one unit, such as a café, and multiplies up. State your approach before calculating, then cross-check with the other method.
For “How many cups of coffee are sold in Bengaluru each morning?”:
When the two land in the same zone, you can say “I’m fairly confident it’s between 1 and 2 million.” When they don’t, you’ve found the assumption to fix.
Like tracing a leak, investigate the metric, then the stage and segment, before proposing causes.
Example: Swiggy orders dropped 30% in Bangalore.
| Segment | What a difference would suggest |
|---|---|
| Area of Bangalore | A citywide drop points to something global. One or two areas point to a local cause, like an outage, rain or a shutdown. |
| New vs returning customers | New users falling suggests an acquisition problem. Returning users falling suggests a broken experience. |
| Android vs iOS vs web | A drop on one platform suggests a bug in one app version. |
| Payment method | One method failing suggests a payment gateway problem. |
| Lunch vs dinner | A drop at peak hours suggests a delivery capacity limit. |
The standard tool is Lewis C. Lin’s CIRCLES method:
Comprehend the situation, Identify the customer, Report their needs, Cut through prioritisation, List solutions, Evaluate trade-offs and Summarise your recommendation.
The first three letters are where you earn the last four. Spend roughly the first third of your time before you propose a single feature.
For Indian consumer products, the adaptation is to pick one user and be specific: a first-time smartphone owner, a shop owner on a shared phone, a student on a weak connection. “Everyone in India” isn’t a user, and a named user changes the solution: language, price, bandwidth, trust in a payment flow. Say why you chose them, then run the rest of the method on that person only. Product improvement uses the same skeleton, but in “Comprehend” you first choose which part of the product to improve.
There isn’t one universal metrics framework, so this guide uses GAME as a simple teaching tool. In an interview, introduce it as your own structure.
If you can fill in those four sentences, you have a metrics answer.
Here are 56 case study questions for product manager interview practice. Use them like a gym: pick a type, do a set of three, then compare your reasoning with the solved case study. Every question links to one of TPF’s 100+ product management case studies.
Browse every guesstimate case study →
Browse every product design case study →
Browse every product improvement case study →
Browse every metrics case study →
These examples show how to approach RCA, guesstimates, product design and metrics. Adapt them to the information you get; don’t memorise the wording.
“First, I’d check how the average is calculated and whether the rating prompt or data collection changed.
“Assuming the definition is unchanged, I’d split the drop into existing customers rating lower, a change in who is rating, or a change in which restaurants are rated. If the same customers are rating lower, I’d compare ratings for fast and slow deliveries, then investigate packaging and other restaurant-side issues.”
See TPF's Zomato RCA case study.
“I’ll start top-down. Bangalore has around 13 million people. If 35% regularly order online, that’s 4.5 million people. At two orders a week, the whole market gets about 1.3 million orders a day. If Swiggy has half the market, that’s 650,000.
“For a bottom-up check, suppose 20,000 restaurants average 30 Swiggy orders a day each: 600,000. I’d estimate 500,000–700,000 daily orders and validate order frequency and market share.”
The numbers are illustrative, not verified company data. See TPF’s Swiggy guesstimate case study.
See how TPF solved this case study.
“I’d focus on first-time blind users who may struggle with setup, understanding whether commands worked, and discovering the device’s features. I’d prioritise voice-guided setup, since the device is useless if users can’t get started.
I’d also add distinct sounds for successful, ongoing, and failed commands, plus a skippable voice tour. The trade-off is that extra sounds could annoy experienced users, so they should be easy to disable.
I’d measure independent setup completion and the time taken to complete the first successful command.”
See TPF’s Google Home Mini case study.
“The goal is to help people find videos they’re glad they watched. My main metric would be the share of recommended videos watched through, supported by a short survey asking whether the recommendation was worthwhile.
“I’d track discovery of new channels, ‘not interested’ and dislike rates, and repeated recommendations. I’d A/B test the change and check results at seven and 30 days. Watch time alone can be misleading if it rises because content is addictive.”
See TPF’s YouTube metrics case study.
For PM case study round preparation, match your practice to the business:
Practise the target company’s own questions first, then ask people who interviewed there recently. The TPF community is a good place to do that.
Live case: usually 30 to 45 minutes. It tests how you think under pressure, and the interviewer will interrupt and challenge your assumptions. Treat it as a conversation, not a presentation.
Take-home: a few hours to a few days. It tests depth, judgement and polish. Put your recommendation on the first page, state your assumptions, explain your reasoning and keep the document easy to skim. A thin take-home stands out more than a thin live answer, because you had time to do better.
Scoring varies, but common criteria include structure, assumptions, user and business insight, judgement and communication.
| Common mistake | Better approach |
|---|---|
| Jumping to solutions | Name the problem and the user first. |
| Keeping assumptions in your head | Say them out loud so they can be credited or challenged. |
| Listing causes without ranking them | Pick the most likely cause and explain why. |
| Naming a metric with no reason | Say what it proves and what it can’t prove. |
| Ending without a recommendation | Finish with one clear sentence. |
Preparation works best as a routine, not a cram. Each week ends with something you can point to.
| Week | Type | Reps | Review |
|---|---|---|---|
| Week 1 | Guesstimates and RCA | 3 to 5 questions of each | Write a one-page summary of each framework without notes. |
| Week 2 | Product design and improvement | 3 to 5 questions of each | Write one design answer in full, and check you spent the first third on the user. |
| Week 3 | Metrics and mixed practice | 3 to 5 metrics questions with GAME, then a shuffled mix of all five types | Practise naming the type in ten seconds. Add one product teardown. |
| Week 4 | Delivery and portfolio | Timed answers out loud, ideally with a real person listening | Find where you ramble. Then turn practice into portfolio: write up your best 2 or 3 answers as a product manager portfolio piece. |
Don’t memorise frameworks. Learn to recognise the problem, structure your thinking and recommend a next step under pressure. For the wider interview, see how to prepare for a PM interview.
They are short, made-up product problems that let interviewers watch how you think in real time. There are five types: guesstimates, root cause analysis, product design, product improvement and metrics.
If you’re wondering how to prepare for a product management case study interview, follow the four-week plan above: learn one framework per type, practise on real questions, say your answers out loud and compare them with the solved versions.
Live rounds usually run 30 to 45 minutes per question. Take-homes range from a few hours to several days, depending on the company and role.
Yes, particularly at Indian consumer tech and fintech companies, where scale is central to the business. Some companies lean more towards product sense and metrics, but skipping guesstimates is a real risk.
.svg)
.avif)
.avif)
.svg){kind=icon}
.avif)