Multi-Sided Marketplace Operating Rules
In a three-sided marketplace, OKRs and A/B tests break — establish stability, name your primary customer, then bet.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 93%
Rathi's hard-won rules from building Swiggy's real-time, three-sided, hyperlocal marketplace: complexity doesn't add, it multiplies, and the standard product toolkit fails. OKRs put the sides into permanent conflict; A/B tests are corrupted by network effects; empathy has to be held for three parties at once. What works instead: guarantee the marketplace is stable on every side, explicitly name which customer you serve when forced to choose, and drive change through big bets that move multiple levers together as one coherent story.
Origin
Rathi's own synthesis from seven years at Swiggy (consumer, delivery executive, restaurant partner), contrasted against the customer-centric stance of Amazon and the seller-centric stance of Alibaba/Taobao ('create life-changing experiences for 10 million Chinese sellers').
Core principles
- 01Marketplace complexity multiplies — a three-sided marketplace is a plane going into three dimensions.
- 02OKRs fail because they assume one kind of user you can divide and conquer; with three, the goals are permanently in conflict.
- 03A/B tests fail because network effects leak between the treatment and control halves of a side.
- 04Stability first: every side must be stable enough that it isn't going to leave.
- 05Then, and only then, name the primary customer — and derive it from the company vision.
- 06Every PM must champion the other sides, not just their own.
- 07Liquidity is a single pot: incentivising the demand side and the supply side compete for the same money.
How to run it
- 1
Stop using OKRs as the coordination mechanism
Recognise that with three user types, every goal you set on one side stretches the other two in the wrong direction — consumer delivery fees vs restaurant commissions vs delivery partner earnings. They are not independent levers, and you cannot model the second-order effects.
Watch out Rathi has seen OKRs fail multiple times in this setting — it's not a tuning problem, it's a structural mismatch.
- 2
Use big bets that move levers together as one story
Replace divide-and-conquer goals with a coherent bet: 'let's make this profitable by raising the delivery fee, but NOT touching earnings per hour and NOT touching restaurant commissions.' The bet names which levers move and which are frozen.
Pro tip This is where the PRFAQ earns its place — the bet needs everyone signed up in writing.
- 3
Distrust A/B tests on a networked side
If you split drivers 50/50 into A and B, the network effect between them contaminates the result. Marketplace experiments don't 'not work' — they don't work in the way you'd expect.
Pro tip Liquidity decisions (incentivise riders vs incentivise first-time users out of one limited pot) often require pulling the lever completely to one side rather than splitting.
Watch out Reading marketplace A/B results as if they were single-sided results will systematically mislead you.
- 4
Establish marketplace stability as the precondition
Before any prioritisation debate, confirm all sides are stable enough that they will not leave. Only from a stable marketplace can you meaningfully ask who you prioritise.
Watch out Marketplaces habitually squeeze supply to serve demand — Uber drivers, Airbnb hosts, delivery riders. That's what destabilises a side.
- 5
Name the primary customer, and make it unambiguous in your values
Derive the answer from the company's vision. Amazon is customer-centric (sellers matter, customers matter slightly more). Alibaba/Taobao build from the seller's point of view. Swiggy had to change its value from 'customer comes first' to 'consumer comes first', because in a marketplace everyone is a customer.
Pro tip Reframe the other sides as co-servants of the end consumer: 'Swiggy and the delivery partner — we are both in the service of the customer.' That perspective then shapes the partner apps too.
Watch out 'Customer comes first' is a dangerously ambiguous value in a marketplace — restaurants are customers too.
- 6
Make every PM manage multiple empathies
The delivery-executive PM must also be a champion of the consumer, and vice versa. Plot the simultaneous journeys and emotional states across the 30-minute delivery window.
Pro tip Pair this with the Show Don't Tell wall — the parallel timelines are what make multi-sided empathy concrete.
In the wild
Consumer-side goal: collect more delivery fee. Restaurant-side goal: raise commissions for profitability. Delivery-partner-side goal: optimise cost, which means paying them less. Move one and the other two are already stretched in the opposite direction; modelling the cascade (X changes Y changes Z) is effectively impossible.
→ Swiggy shifted from OKR-driven coordination to big bets that explicitly hold some levers still.
Amazon is very clearly a customer-centric company — sellers matter greatly, but if forced to choose, the customer is slightly more important. Taobao/Alibaba's stated aim is to create life-changing experiences for 10 million Chinese sellers, so their marketplace is built from the seller's point of view.
→ The choice is not a best practice — it derives from the company's vision, and it must be explicit.
The original value 'customer comes first' was confusing because restaurants are selling customers too. Swiggy rewrote it to 'consumer comes first' — the person actually eating the food — because it is a convenience company delivering to the end consumer.
→ Restaurant and delivery-partner apps were then designed on the premise that both parties are, together with Swiggy, in the service of the end consumer.
Common mistakes
Importing single-sided product tooling wholesale
OKRs, standard A/B experimentation and conventional prioritisation all assume one user type you can divide and conquer. In a three-sided real-time marketplace these 'usual suspects' fail — and teams keep re-running them expecting different results.
Squeezing supply to please demand
Uber and others systematically hosed drivers to deliver for customers; Airbnb hosts get pushed into things they don't want. This breaks the stability precondition and eventually collapses the side you depend on.
Is it for you?
Best for
PMs and product leaders operating two- or three-sided marketplaces, especially real-time/hyperlocal ones
Not ideal for
Single-sided SaaS or consumer products, where OKRs and A/B tests work as intended
From the transcript
“so I've seen okas F multiple times when you're running this kind of a Marketplace big bets work much better”
“you need to be operating in a stable Marketplace so all sides need to be stable enough so that they're not going to go away”
“if you have to run a experiments on your driver side uh if you put half drivers on a versus half on B but there…”
“we had to clarify consumer comes first like the end consumer which is actually eating food”
From the episode
The full-stack PM
Anuj Rathi (Swiggy, Jupiter Money, Flipkart)