how to approach any pm case study

You are in an interview. The interviewer says: “You have 30 minutes. Improve Swiggy’s retention.”

Your palms sweat. You have used Swiggy. You have opinions about Swiggy. You want to start talking about push notifications and loyalty programs and referral discounts. Every instinct tells you to show how much you know about food delivery.

That instinct will fail you.

I have watched over 10,000 PMs attempt case studies — in interviews, in our training cohorts at Pragmatic Leaders, in take-home assignments. The ones who fail almost always fail for the same reason: they start solving before they understand the problem.

The ones who succeed follow a pattern. It is not complicated. But it requires discipline to follow under pressure.

The four-step framework

Every PM case study, regardless of type, follows this structure:

1. Clarify — What exactly are we solving? 2. Structure — How do we break this into parts? 3. Analyze — What do the parts tell us? 4. Recommend — What should we do, and why?

That is it. Four steps. No acronym. No proprietary model. The power is not in knowing the steps — it is in executing each one well.

Step 1: Clarify

Most candidates skip this. They hear “improve Swiggy’s retention” and start brainstorming features. But that question has at least six ambiguities:

• Which users? New users who never ordered a second time? Power users who churned after 6 months? Users in metros vs tier-2 cities?
• Which retention metric? D7? D30? Monthly order frequency? Reactivation rate?
• What is the current state? Is retention declining, flat, or growing slowly?
• What has already been tried? Have they already launched a loyalty program?
• What constraints exist? Budget? Timeline? Regulatory?
• What is the business context? Is Swiggy optimizing for profitability or growth?

In an interview, you ask these questions out loud. In a take-home, you state your assumptions explicitly. Either way, you are doing two things: narrowing the problem space and showing the interviewer that you think before you act.

Two minutes of clarification just turned a vague question into a specific one: Why do new tier-1 users who order in their first month not order again in month two?

That is a problem you can actually solve.

Step 2: Structure

Structure means decomposing the problem into mutually exclusive, collectively exhaustive (MECE) parts. Not because MECE is a magic word — but because without structure, your analysis will be a scattered list of ideas with no logic connecting them.

For the Swiggy retention case, you might structure it as the user journey:

Or you might structure it by lever:

• Product experience — Was the core value delivered? Speed, accuracy, variety.
• Pricing — Was the total cost (food + delivery + platform fee) competitive?
• Habit formation — Was there a trigger to reorder? Or was the first order a one-off?
• Competitive pull — Did a competitor offer something better in that window?

Either structure works. The point is that you choose one, state it clearly, and use it to organize everything that follows. An interviewer who sees structure sees a PM who can manage complexity.

Step 3: Analyze

This is where most candidates go shallow. They list problems (“delivery was slow”) but do not analyze causes (“Swiggy’s tier-1 delivery fleet is optimized for peak hours, leaving 2-4 PM orders with 45+ minute ETAs — which is when new users are most likely to try the app for the first time”).

Good analysis does three things:

Quantify when possible. “If M1-to-M2 retention is 25%, and Swiggy adds 2 million new users per month in tier-1, that is 1.5 million users lost every month. Even a 5 percentage point improvement is 100,000 retained users — worth roughly 20 crore in annual GMV at average order values.”

Prioritize. Not every problem is equally important. Use a simple impact-vs-effort lens or ask: which of these problems, if solved, would move the retention number the most?

Reference real behavior, not hypotheticals. “In our training cohorts, I have seen PMs at food delivery companies confirm that first-order experience is the strongest predictor of retention — stronger than pricing, stronger than promo codes.” Real evidence beats speculation.

Step 4: Recommend

Your recommendation must follow logically from your analysis. If your analysis says the biggest retention drop comes from bad first-order experience, your recommendation should fix first-order experience — not launch a loyalty program.

A strong recommendation has four parts:

1. What to do — specific, not vague. “Guarantee sub-30-minute delivery for first orders in tier-1 by restricting the restaurant radius to 4 km” — not “improve delivery speed.”
2. Why this and not something else — show you considered alternatives. “A loyalty program addresses repeat behavior but not first-order drop-off, which is our biggest leak.”
3. How to measure success — “Track M1-to-M2 retention for the cohort exposed to the guarantee vs. control. Target: 5 percentage point lift within 60 days.”
4. What could go wrong — “Restaurant selection drops with the 4 km radius. Mitigate by increasing restaurant density through cloud kitchen partnerships.”

When to break the framework

The four-step framework works for 80% of cases. But some cases do not fit templates, and recognizing when to deviate is what separates a trained PM from a framework-memorizer.

Here are the cases that break the standard approach:

The vision case. “Build the next big thing for PhonePe.” This is not about analysis — it is about conviction. Start with a point of view (“PhonePe has 400 million users who trust it with money but use it 3 times a month. The opportunity is daily engagement through commerce, not more financial products.”) Then defend it. The framework still helps — you are still clarifying and structuring — but you lead with the thesis, not the decomposition.

The firefighting case. “Ola’s driver cancellation rate spiked 40% this week. What do you do?” Here, speed matters more than structure. Identify the most likely cause (incentive structure change? competitor poaching? app bug?), propose an immediate investigation plan, and define the escalation criteria. Do not spend 10 minutes drawing a MECE tree while the house is burning.

The estimation case. “How many PhonePe transactions happen during Diwali week?” This requires a different muscle entirely — top-down sizing, assumption calibration, sanity checks. The four-step framework is irrelevant here. What matters is your ability to break a large number into smaller, estimable components and check your math against known benchmarks.

The ethical dilemma. “Your A/B test shows dark patterns increase conversion by 15%. Ship it?” There is no analysis that resolves a values question. State your position, acknowledge the tradeoff, and explain how you would navigate the organizational politics of saying no to a 15% lift.

Case study types: approach variations

Notice that “clarify” appears in every row — but what you do after clarifying changes by case type. A product improvement case needs a funnel. A strategy case needs a market map. An estimation case needs arithmetic. The framework adapts. It does not rigidify.

The mistakes I see repeatedly

After thousands of case study reviews, the failure modes cluster into five patterns:

1. The feature list. The candidate names 8 features in 3 minutes. No prioritization, no analysis, no reasoning for why feature 3 is better than feature 7. This is brainstorming, not product management.

2. The framework recital. The candidate says “Let me use the CIRCLES framework” and then mechanically fills in each letter. The interviewer does not care about CIRCLES. They care about whether you can think. If the framework helps you think, use it silently. If you announce it, you sound like you are following a recipe.

3. The generic answer. “I would do user research, analyze the data, prioritize based on impact, and iterate.” This describes every PM’s job. It says nothing specific about the problem in front of you. Specificity is the difference between a 3 and a 5 on the interview scorecard.

4. The assumption that data exists. “I would look at the cohort retention curves segmented by acquisition channel.” Great — but the interviewer just told you this is a seed-stage startup with 500 users and no analytics. Adapt to the context.

5. The missing tradeoff. Every recommendation has a cost. If you do not name it, the interviewer assumes you have not thought about it. “This will increase retention but reduce new user acquisition because we are reallocating promo budget” — that is a PM talking. “This will increase retention” — that is a student talking.

Test yourself

Where to go next

• Practice specific case types: Product Improvement Cases | Product Design Cases | Growth & Acquisition
• Build your estimation muscle: Estimation Cases
• Understand the Indian market context: Indian Market Cases
• Learn the metrics that drive cases: Metrics & Analytics