indian market cases

Every PM case study book you have read was written for San Francisco. The examples are Spotify, Airbnb, Slack. The frameworks assume users with $100+ ARPU, reliable 4G, a single language, and a credit card on file.

None of that applies to India.

India has 750 million internet users, most of whom came online after 2016 via Jio’s pricing demolition of the telecom market. They transact on UPI — zero-fee, instant, government-backed rails that process 12 billion transactions per month. They speak 22 official languages. They are brutally price-sensitive but will pay for genuine value. And they live in a market where the difference between tier-1 and tier-3 is not just income — it is infrastructure, trust patterns, and daily life.

If you want to build products for this market, you need case studies from this market. Here are five.

Case 1: Swiggy’s three-sided pricing problem

Swiggy is not a food delivery app. It is a three-sided marketplace: customers, restaurants, and delivery partners. Each side has a different relationship with price.

Zomato charges restaurants roughly 10% commission. Swiggy charges 18-25%. Yet restaurants stay on Swiggy. Why?

Because Swiggy brings volume. It is value-based pricing, not competitive pricing. Restaurants do not compare commission rates in isolation — they compare total profit per month across channels. A 25% commission on 500 orders beats 10% commission on 100 orders.

The PM lesson: In a multi-sided marketplace, price perception differs by stakeholder. Do not react to competitor pricing moves until you understand which side of the marketplace is actually affected — and whether price is the real variable. Swiggy’s moat was delivery speed and order volume. Competing on commission rate would have destroyed unit economics without solving the actual problem.

India-specific context: The Indian food delivery market has a peculiar dynamic — average order values hover around Rs 250-350. At that price point, a Rs 30 delivery fee is 10% of the order. Customers notice. This is why Swiggy Super (subscription for free delivery) became a retention weapon. It converts a per-transaction cost into a sunk cost — and sunk costs change behavior.

Case 2: CRED — building a luxury product in a price-sensitive market

CRED should not work. It is a credit card bill payment app in a country where only 3-4% of the population has a credit card. It targeted only users with a credit score above 750 — deliberately excluding 96% of India. And it spent lavishly on advertising with no clear revenue model for years.

Yet CRED is valued at over $6 billion. The PM lesson here is about market selection, not market size.

CRED’s product strategy, deconstructed:

1. Purpose: Incentivize timely credit card payments by rewarding users with exclusive perks. Sounds simple. The insight is deeper — CRED is a trust signal aggregator. A high credit score is a proxy for financial discipline, which is a proxy for purchasing power and reliability.

2. Target: Not “Indian consumers.” Not even “credit card holders.” Specifically: high-score credit card holders who pay on time. This is ~30 million people in a country of 1.4 billion. Tiny segment. But this segment has massive purchasing power and is chronically underserved by apps designed for the mass market.

3. Monetization path: CRED did not monetize users directly. It monetized access to those users. Brands pay CRED to put offers in front of a pre-qualified, high-intent, high-spending audience. The bill payment is the hook. The audience is the product.

The PM lesson: Total addressable market is not the only way to size an opportunity. CRED proved that a small, high-value segment can support a massive business if the product is designed around that segment’s identity — not just their utility needs. The rewards are almost secondary. The real value is belonging to a club that signals financial discipline.

India-specific context: India’s credit card penetration is 5% of the population but growing 20%+ year-on-year. CRED bet on the trajectory, not the snapshot. They also exploited a uniquely Indian behavior — the monthly bill payment ritual. In the US, credit card payments are automated. In India, many users manually pay each month. CRED turned this friction into a feature.

Case 3: Flipkart vs Amazon India — logistics as product

The Flipkart vs Amazon India battle is not about app UX or product selection. It is about logistics. Specifically: who can deliver a Rs 299 phone case to a customer in Ranchi within 3 days without losing Rs 200 on shipping?

Flipkart built eKart, its own logistics arm, in 2009 — years before Amazon India launched. This was not a supply chain decision. It was a product decision. When you control delivery, you control the customer experience.

Flipkart’s critical early decision: cash on delivery. In 2010, online payment penetration in India was negligible. Less than 2% of e-commerce transactions used credit cards. Flipkart’s founders — both ex-Amazon employees — understood that the Western assumption of “payment first, delivery later” would kill e-commerce in India. So they flipped it. Deliver first, collect cash at the door.

This single product decision required building an entirely different logistics stack — one where delivery partners carried cash, reconciled daily, and handled returns at the doorstep. It was operationally brutal. It also unlocked the Indian market.

The PM lesson: In India, logistics is not a back-end concern — it is the product. Your delivery promise, payment options, and returns process are features. The app UI matters, but a customer in Jamshedpur does not care about your beautiful product page if the delivery takes 10 days and there is no way to return a wrong-sized shirt.

India-specific context: Cash on delivery still accounts for 40%+ of Indian e-commerce orders in tier-2 and tier-3 cities, even with UPI adoption. Trust is the variable. First-time online shoppers do not trust paying before seeing the product. This is not irrational — it is a learned behavior from decades of unreliable delivery infrastructure. Your product must account for trust deficits that do not exist in Western markets.

Case 4: PhonePe — UPI as a platform play

PhonePe processed 48% of all UPI transactions in India in 2024. That is 5+ billion transactions per month on a zero-revenue product. UPI is free. No MDR (merchant discount rate). No transaction fees. The government mandated this.

So how does a payments company make money when the core product is free?

PhonePe’s answer: payments are distribution. Every UPI transaction is a touchpoint. Every touchpoint is an opportunity to cross-sell insurance, mutual funds, lending, and commerce.

The product architecture reflects this:

1. Layer 1 — Payments (free): Bill payments, P2P transfers, merchant payments. Zero revenue. Maximum frequency. The average PhonePe user transacts 8-10 times per month.
2. Layer 2 — Financial services (revenue): Insurance, mutual funds, gold, lending. This is where the money is. PhonePe sells ~Rs 1,500 crore of insurance annually.
3. Layer 3 — Commerce (emerging): Pincode (hyperlocal delivery), Indus Appstore (app distribution). Bets on owning the next layer of the stack.

The PM challenge at PhonePe is not building payment flows — UPI handles that via NPCI rails. The challenge is converting a 30-second payment interaction into a 5-minute engagement session where users discover financial products.

The PM lesson: When your core product is free (or near-free), product management is really about designing transitions — from the free action to the revenue action. The transition must feel natural, not interruptive. PhonePe’s insight was that a payment receipt is a moment of financial awareness. People just spent money. That is the moment to offer protection, savings, or investments — not when they are browsing an app home screen.

India-specific context: UPI changed India’s product landscape permanently. 300 million Indians who never had a bank relationship now transact digitally. But “digitally transacting” is not the same as “financially literate.” The PM job in Indian fintech is bridging that gap — designing products for users who can make a UPI payment in 10 seconds but have never heard of term insurance. The product is also the education.

Case 5: Jio — pricing as a weapon of mass adoption

Reliance Jio did not enter the telecom market. It detonated it.

In September 2016, Jio launched with free 4G data for every user. Not a trial. Not a limited offer. Free, unlimited 4G data for six months. In a market where Airtel charged Rs 250 for 1GB of 3G data.

The result: 100 million subscribers in 170 days. No telecom company in history had scaled that fast.

The product decision was not “offer cheap data.” The product decision was “make data free, let an entire country come online, then monetize the behaviors that connectivity creates.” Jio was not a telecom play. It was a platform seed.

Jio’s pricing destroyed Vodafone India and Idea Cellular (they merged in desperation). Airtel survived because it had deep enough pockets to match prices. Everyone else died. This was not an accident — it was a calculated move to consolidate the market.

The PM lesson: Pricing is not a feature. It is a strategy. Jio did not compete on network quality (their 4G speeds were inconsistent, worse than Airtel in many areas). They competed on access. When your pricing makes an entire user segment possible — people who literally could not afford to be online — you are not optimizing a market. You are creating one.

India-specific context: The tier-2 and tier-3 explosion that every Indian startup now rides — Meesho, ShareChat, Koo, Josh — happened because Jio put data into the hands of 500 million people who could not afford it before. If you are building for “Bharat” (the non-metro market), your product exists because of a pricing decision that one company made in 2016. Understand that history. It shapes every assumption you make about your users.

The India product playbook — what these cases share

Five cases, one pattern. Indian market products succeed when they respect five realities:

1. Price sensitivity is structural, not cultural. Indians are not “cheap.” They earn in a market with low per-capita income and high variance. A Rs 30 fee that is irrelevant in Mumbai is a decision in Lucknow. Design pricing for the median, not the mean.

2. Trust must be earned at every transaction. Cash on delivery, OTP verification on every login, return-at-doorstep — these exist because trust in digital systems is still being built. Do not mistake this for friction to be eliminated. It is friction that enables adoption.

3. Language is a product feature, not a setting. 11 languages is not localization. It is market access. The user in Coimbatore who switches to Tamil is not making a preference choice — they literally cannot use your product in English. If you support only English, you have excluded 70% of India.

4. Infrastructure is variable. Your product must work on Rs 8,000 Android phones on 3G connections with intermittent connectivity. If it doesn’t, you have built a product for 100 million people, not 750 million.

5. Free is a strategy, not a failure. UPI is free. Jio started free. WhatsApp is free. The Indian market rewards products that are free at the base and monetize at the edges — through cross-sell, through data, through premium tiers. If your business model requires every user to pay on day one, you will fail here.

Where to go next

• Apply pricing frameworks from these cases: Pricing and Monetization Cases
• Practice market sizing for Indian markets: Estimation and Market Sizing
• Growth strategies that work in India: Growth and Acquisition Cases
• Understand product strategy fundamentals: Product Thinking