product design cases

“Design a product for X” is the hardest category of PM case study. There is no existing product to analyze. No metrics to anchor on. No funnel to decompose. You are staring at a blank sheet.

And that is exactly why interviewers love it.

The product design case tests three things simultaneously: can you identify a real user need (not a hypothetical one), can you scope ruthlessly (not design an entire platform in 30 minutes), and can you make trade-offs that reveal judgment (not just creativity).

I have seen thousands of candidates attempt these in Pragmatic Leaders cohorts. The failure mode is always the same: they design for themselves, they scope too wide, and they present a feature list where there should be a user story. The candidates who succeed start with a person, not a product.

The framework for product design cases

Product design is different from product improvement. When you improve Netflix, Netflix already exists — you diagnose what is broken. When you design a new product, nothing exists — you must justify why it should.

Notice the split: steps 1-4 take almost half your time, and none of them involve designing anything. You are building the foundation before you touch the solution. Most candidates invert this — they spend 80% of their time on step 5 and rush through everything else.

The interviewer has seen a hundred product specs. They have not seen enough candidates who can articulate why a product should exist before describing what it does.

Case 1: Design a health insurance product for gig workers in India

User segments

Blue-collar gig workers are not one group. Their insurance needs differ by risk profile:

1. Delivery riders (Swiggy, Zomato, Zepto) — High accident risk. On the road 8-10 hours daily. Income: 15,000-25,000/month. Their biggest health fear is a road injury that puts them off work for weeks.
2. Cab drivers (Ola, Uber) — Moderate accident risk. Sedentary for long hours. Income: 20,000-35,000/month. Chronic issues like back pain and diabetes are more common than acute injuries.
3. Home service professionals (Urban Company, NoBroker) — Electricians, plumbers, beauticians. Low accident risk but inconsistent income. Their problem is not one big medical bill — it is the steady drain of small expenses (a child’s fever, a spouse’s dental issue) with no employer to cover it.
4. Construction day laborers — Highest risk, lowest income, most transient. Not reachable through apps. A different distribution problem entirely.

Which segment to pick: Segment 1 — delivery riders. Three reasons. First, the pain is acute and specific: a single accident can eliminate income for 4-8 weeks, which is financially catastrophic when you have no savings buffer. Second, they are reachable through a single distribution channel (the delivery apps). Third, their risk is quantifiable — road accidents have data, unlike the diffuse health needs of segment 3.

Unmet needs

I would talk to 20 delivery riders in Bangalore and Delhi. Based on what we have seen in our training cohorts — where PMs from Swiggy, Ola, and Urban Company have shared their field research — the top needs cluster around three problems:

1. Income protection, not just medical coverage. Traditional insurance pays the hospital. But the rider’s real fear is the 6 weeks of zero income while recovering. No existing insurance product covers lost gig income.
2. Instant, zero-friction claims. Riders do not have HR departments. They cannot navigate a 12-step claims process with document uploads. If the claim takes 3 weeks, they are already broke.
3. Affordable daily pricing. A rider earning 800 rupees a day will not pay 8,000 rupees upfront for annual coverage. The premium must feel like a daily expense — chai money, not rent money.

Core value proposition

One sentence: If you get hurt and cannot ride, we pay your daily income until you recover — and we pay it within 24 hours.

This is not traditional health insurance. It is income insurance triggered by a health event. That reframe is the entire product thesis.

Solution design

The product: SafeRide (working name)

User flow — enrollment:

1. Rider opens the app. Sees a single screen: “Protect your income. Rs 15/day. Cancel anytime.”
2. Taps “Start.” Enters UPI ID (for payout) and Aadhaar number (for KYC). No address, no medical history, no 4-page form.
3. Daily premium of Rs 15 auto-debits via UPI autopay. No annual commitment.

User flow — claim:

1. Rider has an accident. Opens the app. Taps “I got hurt.”
2. Takes a photo of the injury or hospital admission paper. The app uses OCR to extract key details.
3. The platform cross-references with the rider’s delivery app data (GPS shows the rider stopped working on a specific date — this is the injury timestamp).
4. Within 24 hours: Rs 500/day (roughly 60% of average daily income) deposited to the rider’s UPI ID. Payments continue for up to 30 days per claim.

What happens behind the scenes:

• The product is underwritten by an insurance partner (Digit, Acko — companies already doing sachet insurance in India). SafeRide is the distribution and claims layer, not the underwriter.
• Delivery app API integration provides a behavioral proof layer: if the rider’s GPS and order data show they stopped working, it corroborates the claim without requiring hospital paperwork.
• Fraud detection is built on the same data — a rider who stops taking orders but is still moving around the city gets flagged for manual review.

Deliberately excluded from V1: Hospital bill coverage, family coverage, dental, chronic conditions, coverage for non-work injuries. All of these are real needs. None of them are the wedge. The wedge is income protection for work-related injuries — simple, specific, sellable.

Go-to-market

First 1,000 users: Partner with one delivery platform (start with Zepto — they are the most aggressive on rider welfare as a competitive differentiator against Swiggy/Zomato). Zepto subsidizes the first 30 days of coverage for new riders as a rider acquisition incentive. The rider sees: “Free income protection for your first month.”

Why this works: You are not asking riders to discover a new app. You are embedding in the flow they already use. The delivery platform gets a rider retention lever. The rider gets tangible proof of value before paying anything.

Expansion: After proving the model with one platform, offer to others. Eventually, the rider downloads SafeRide directly because they switch between platforms but want continuous coverage.

Success metrics

Primary: Claims paid within 24 hours (target: 90%). This is the core promise. If you break it, trust collapses, and gig workers talk — word of mouth in rider communities is fast and brutal.

Guardrail: Fraud rate below 5% of total claims. Too low means your detection is too aggressive and rejecting legitimate claims. Too high means you are hemorrhaging money.

Leading indicator: Day-15 renewal rate. If a rider who got a free month chooses to keep paying Rs 15/day, the product has earned trust.

Trade-offs

The key insight for the interviewer: You did not design “an insurance app.” You identified a specific user (delivery riders), a specific fear (income loss, not hospital bills), a specific mechanism (UPI daily debit + delivery app data for claims), and a specific distribution channel (embedded in the gig platform). Every design decision traces back to the user’s reality, not to what insurance products traditionally look like.

Case 2: Design a product to help kirana store owners manage inventory

Clarifying the problem

“Design for kirana stores” is dangerously broad. Kirana stores have problems with inventory, billing, credit (khata), supplier management, digital payments, competition from quick commerce, and footfall decline. You cannot solve all of these.

For this case: inventory management — specifically, the problem of stockouts and overstock. A kirana owner loses 3-5% of daily revenue to stockouts (customer wanted Parle-G, shelf was empty, customer went next door) and ties up 10-15% of working capital in overstock (bought too much Surf Excel because the distributor offered a deal).

User segments

1. Micro kirana (monthly revenue under 1 lakh) — Run by one person. No staff. No smartphone comfort. Inventory is tracked in their head. They will not adopt any tool that takes more than 10 seconds per interaction.
2. Small kirana (1-5 lakh/month) — Usually a family operation. The owner uses WhatsApp fluently. Has a billing machine or uses Khatabook. Open to tools that save time but deeply skeptical of anything that costs money monthly.
3. Medium kirana (5-15 lakh/month) — Multiple staff. Already using some POS system. Their problem is not basic inventory — it is demand forecasting and supplier negotiation. They want analytics, not tracking.

Which segment to pick: Segment 2 — small kirana owners. The micro segment will not adopt any digital tool (the overhead exceeds the value). The medium segment already has solutions. Segment 2 is the sweet spot: they feel the pain of stockouts, they have the digital literacy to use a simple tool, and there are over 8 million of them in India.

User needs

Based on field research patterns from our training cohorts (PMs from JioMart, Udaan, and ElasticRun have shared extensively):

1. Know what is running low before it runs out. The owner currently realizes they are out of Amul butter when a customer asks for it. By then, the sale is lost.
2. Reorder without calling 5 distributors. The current process: call the Britannia distributor, then the HUL distributor, then the local dairy distributor, then the beverage distributor. Each has a different order process. Some only take orders on WhatsApp. Some need a phone call. It is a 30-minute daily chore.
3. Do not change how I work. Kirana owners hate learning new software. Any tool that requires them to scan every product or manually enter stock counts will be abandoned within a week. The tool must fit into their existing workflow, not replace it.

Core value proposition

One sentence: We tell you what to order before you run out, and let you place the order in one tap.

Not inventory management. Not ERP. Not analytics. Just: never run out of your top sellers, and spend 2 minutes on reordering instead of 30.

Solution design

The product: ReStock (working name)

How inventory tracking works — without manual entry:

• The owner already has a billing machine (90%+ of segment 2 stores use some form of billing). ReStock connects to common billing formats (Marg ERP, Tally, even a simple CSV from the billing printer).
• Every sale automatically decrements the virtual inventory. No scanning. No manual counting.
• For items not billed (loose items sold by weight, single cigarettes), the owner does a weekly “walk the shelf” — a 5-minute guided flow where the app shows photos of the top 50 SKUs and the owner taps “low / ok / plenty.” Three taps per item. Done in under 5 minutes.

How reordering works:

• Each morning, the app shows a screen: “Today’s reorder list.” It is pre-populated based on depletion rate and a 3-day demand forecast (built on the store’s own sales data — no need for fancy ML at first, a moving average works).
• The owner reviews the list. Removes items they do not want. Taps “Order.”
• The order is split and sent to the relevant distributors via WhatsApp API. The distributor receives a formatted message: “Order from Sharma General Store: Amul Butter 500g x 10, Parle-G x 20, Surf Excel 1kg x 5.” The distributor replies with confirmation or substitution.

Why WhatsApp, not a distributor app: Distributors in India do not adopt new software. Their salespeople take orders on WhatsApp already. ReStock does not ask the distributor to change anything — it sends a cleaner version of what the distributor already receives. Zero adoption cost on the supply side.

Go-to-market

First 1,000 stores: Partner with one FMCG distributor in one city (pick Bangalore — high smartphone penetration, dense kirana network). The distributor recommends ReStock to their retailers because it means cleaner, more predictable orders and fewer last-minute calls. The distributor is the sales channel.

Pricing: Free for the kirana owner. Monetize through the distributor: charge a small per-order processing fee (Rs 5-10 per order) in exchange for guaranteed, predictable order flow.

Success metrics

Primary: Stockout reduction rate — measured by tracking how often a top-50 SKU hits zero before a reorder arrives. Target: 40% reduction in stockouts within 90 days of adoption.

Guardrail: App opens per week. If the owner stops opening the app, the reorder list is not being reviewed, and the tool is not being used. Target: 5+ opens per week (roughly once per working day).

Trade-offs

Case 3: Design a safety product for women commuters in Indian cities

Clarifying the prompt

Women’s safety in urban India is a real, urgent problem — but “design a safety product” can go in twenty directions: hardware devices, SOS apps, ride-sharing features, community networks, surveillance systems. The solution space is enormous, and most of it has been tried.

The constraint I will set: a software product (no hardware), integrated with existing ride-hailing or public transport, focused on the commute — the most predictable and repeated high-risk moment in a woman’s day.

User segments

1. Women using ride-hailing apps (Ola, Uber) — Already have some in-app safety features (SOS button, ride sharing with contacts). Their pain is that existing features are reactive (you press SOS after something goes wrong) and socially awkward (“share your ride” implies you do not trust the driver, which creates tension).
2. Women using public transport (metro, bus, auto) — No in-app safety net. No ride tracking. No SOS button. The commute is a black box between leaving home and reaching destination.
3. Women walking the last mile — From the metro station to home. From the bus stop to office. This is where most harassment incidents happen, and there is zero product coverage for this segment.

Which segment to pick: Segment 3 — last-mile walkers. Ride-hailing apps already have safety features (imperfect, but they exist). Metro and buses have CCTV and some degree of crowd safety. But the 10-minute walk from the metro station to your apartment at 9 PM — that is where the product gap is widest and the anxiety is highest.

The pain point

I will be specific. A woman exits Huda City Centre metro station in Gurgaon at 9:15 PM. She walks 800 meters to her apartment through a poorly lit stretch with minimal foot traffic. Every day she does this walk with her phone in hand, earphones out, keys between her fingers. She has no way to signal distress that is faster than unlocking her phone, opening an app, and pressing a button — a process that takes 15-20 seconds under stress.

Her need is not an SOS button. She already has a phone. Her need is passive safety that does not require an action at the moment of crisis — because in a crisis, fine motor actions fail.

Core value proposition

One sentence: Your phone knows you are walking home, knows your usual route and pace, and alerts your emergency contacts automatically if something seems wrong — without you pressing anything.

Solution design

The product: WalkWith (working name, integrated as a feature into Google Maps or a standalone app)

How it works:

1. Learn the routine. The app learns your regular commute patterns — the usual metro exit time, the usual walking route home, the usual pace, the usual arrival time. After a week of passive observation, it builds a “normal commute” profile.

2. Passive monitoring on the walk. When you start your last-mile walk (triggered by exiting the metro station geofence), the app enters “walk mode.” It monitors three signals:

   • Route deviation — you left your usual path.
   • Pace anomaly — you suddenly started running, or you stopped moving entirely.
   • Arrival delay — you have not reached home within the expected window (e.g., usual 12-minute walk has taken 25 minutes).

3. Graduated alert system:

   • Soft check (1 anomaly): The phone vibrates with a discreet prompt: “Everything okay? Tap to confirm.” If you tap, nothing happens. If you do not tap within 60 seconds, it escalates.
   • Alert (no response or 2+ anomalies): Your live location is shared with your emergency contacts via SMS. The message: “Priya has not responded to a safety check on her usual route home. Live location: [link].”
   • Emergency (no response after 3 minutes): Automatic call to local police control room with your GPS coordinates.

4. The hardware-free panic trigger. If you are in danger and cannot use your screen, squeeze your phone (on phones with squeeze gestures) or shake it in a specific pattern (three sharp shakes). This immediately triggers the emergency level — no screen, no unlock, no app navigation.

Deliberately excluded from V1: Social features (community walks, “who else is walking nearby”), crowdsourced danger maps (data quality is poor and creates false sense of security), physical panic buttons (hardware is a different product and distribution challenge).

Go-to-market

First 1,000 users: Partner with one women’s college or IT park in Gurgaon. Install the app as part of the campus safety initiative. The institution endorses it, which builds trust. Every woman walking from the metro to the campus uses it daily — a captive, high-frequency use case.

Why not launch on the Play Store broadly? Because safety apps face a cold-start trust problem. A woman will not trust an unknown app with her location and emergency contacts. Institutional endorsement solves the trust problem. Once 1,000 women are using it and sharing their experience, organic word-of-mouth in peer groups drives adoption.

Success metrics

Primary: False negative rate — the percentage of actual incidents where the system failed to trigger an alert. Target: below 2%. A safety product that misses real events is worse than no product at all.

Guardrail: False positive rate — the percentage of alerts sent to emergency contacts when nothing was wrong. Target: below 10%. Too many false alarms and contacts stop taking the alerts seriously. The boy who cried wolf problem will kill this product faster than any competitor.

Trade-offs

The five mistakes that kill product design answers

After reviewing thousands of product design cases in Pragmatic Leaders cohorts, the same patterns of failure show up again and again.

1. Designing for yourself.

“I would love a feature that…” is the opening line of a bad product design answer. You are not the user. A 26-year-old PM in Bangalore is not a delivery rider in Indore. A Bain consultant is not a kirana store owner in Madurai. The first discipline of product design is to set aside your own preferences and start with the user’s reality — their income, their phone, their daily routine, their fears. If you have not spoken to the target user (or at least read detailed research about them), you are guessing.

2. Solving too many problems at once.

“Our app will handle inventory, billing, credit management, loyalty programs, and supplier payments.” That is not a product — that is a roadmap for 3 years. A product design case asks you to identify the wedge — the single problem that is painful enough to drive adoption, specific enough to build in 3 months, and expandable enough to grow into a business. One problem. One user. One solution.

3. Ignoring distribution.

The graveyard of Indian startups is full of beautiful products that no one could distribute. “We will put it on the Play Store” is not a distribution strategy. How does the user discover this product? Why do they trust it? What is the activation moment that converts a download into a habit? In India especially, distribution through existing networks (employers, kirana distributors, gig platforms, self-help groups) beats consumer marketing almost every time.

4. Describing features instead of user flows.

“The app will have a dashboard, a notifications tab, and a settings page.” That is a wireframe description, not a product design. The interviewer wants to hear: “The rider opens the app at 6 AM, sees one number — how much coverage they have accumulated this month — and a single button: ‘I got hurt.’ That is the entire screen.” Show the experience, not the architecture.

5. Skipping the ‘why not’ question.

Every design case should end with what you deliberately left out and why. “I excluded family coverage from V1 because adding dependents triples the underwriting complexity and delays launch by 6 months. We can add it after proving the core model.” That sentence tells the interviewer you understand scope, sequencing, and trade-offs — which is most of the PM job.

Where to go next

• Master the general framework: How to Approach Any PM Case Study
• Practice improvement cases: Product Improvement Cases
• Sharpen your metrics thinking: Metrics & Analytics Cases
• Try India-specific challenges: Indian Market Cases