Chicken and Egg problems with Platform Experiments

Lean Startup and Platform Experiments

I recently started working at Intuit, running market experiments as a part of the QuickBooks team. Here’s another post that’s a part of the ongoing lean startup series.

Chicken and Egg Problems

One of the challenges with building platform products or marketplaces is the classic ‘ghost town’ or ‘chicken and egg’ problem. It’s what happened to early Google Wave users who initially signed up, found that they had no one to wave to, and didn’t return. Or, e-commerce category launches where sellers dont sign up since the marketplace doesnt have enough buyer eyeballs, and buyers come only if there are enough sellers and a large collection that holds their interest.

Traditional wisdom generally says that the only way out is to make a significant upfront investment in seeding the platform for a few narrow categories until the network effects start to kick in.

While this approach has certainly worked, there are also enough instances where it has failed.

I spoke to a friend who heads the product team at Amazon India and found that their early approach to the India market was not different - they started with a few categories, built out a large catalog, focused on improving ratings in those categories first and then grew from there. But then, they had an existing brand with clout that it brings, and deeper pockets than many. Unless of course you are a venture funded e-com player that’s already on a treadmill with money to burn and little time to do anything but panic, spray and pray.

If you’ve read my other blog posts, you’d already know that this post isn’t about how to burn your VC money.

It’s about how to step back to look at your business model canvas, assess areas of your strategic direction that are at risk, and identify rapid experiments to learn and evolve a sustainable approach.

Two sides of a Platform

Platforms and marketplaces almost always involve at least two ‘sides’. Most often, these are producers on one side and consumers on the other. Think Wikipedia, Waze, eBay, Flipkart, Quikr. But there are variants where the two sides may share similar needs - think LinkedIn, WhatsApp, or Tinder.

Challenges with experimentation

One of the challenges I’ve heard of with applying Lean Startup to platform/marketplace problems is that it can be hard to test experiments without your MVP including a network that is already seeded. In other words, building out the early community or marketplace with at least a few categories and active users has to be a part of your MVP in order to effectively test anything or learn about the market. Without that, you end up with false negatives and the experiment design itself is broken. However, it can take several months just to grow a community organically or to build out a category. This can quickly inhibit your ability to build-measure-learn through rapid loops.

The insight from Brant

When I caught up with Brant Cooper, the author of the Lean Entrepreneur over a dinner organized by LeanMantra recently, he shared an interesting way of thinking about these problems which I found insightful. According to Brant, in every 2-sided platform, there’s always one side that’s really the product.

In every 2-sided platform, there’s always one side that’s really the product.

The side that matters

So, the way to think about this is to protect the experience of the side that’s the product, while offering a velvet rope experience to the other side.

Let’s run through a few examples to see what this looks like.

1. Wikipedia - arguably the contributors are the ‘product’. Apparently the ratio of contributors:readers is 5:1000.

2. Flipkart - the site visitors are the ‘product’, whose shopping experience needs to be protected while leveraging them to bring in hordes of sellers to fill out the catalog.

3. Dating sites - Most straight dating sites are careful about managing the ratio of men:women. Invariably, it’s the women whose experience is protected.

Things aren’t necessarily as black and white as this, and there are nuances where this may not always fit. However, this provides a useful metaphor for how we think about experience and structure our experiments.

The Velvet Rope

Getting a velvet rope experience right in the context of an experiment can be tricky. The original Gmail approach of throttling invites may now be passé, but others like Quibb were more recently successful in roping in influencers with a high hurdle.


Sandra, the founder of Quibb took the approach of manually curating every single invitee. Applicants were informed that Quibb had a 37% acceptance rate, and the chances of being accepted improved with social proof and a full bio. At first, you’d think the high hurdle would turn people away - but instead, it did the trick. The psychology behind this clever approach is well documented, and is a good example of the velvet rope experience in practice.

So in other words, think

  • high hurdle - bring in the best. the best attact the best.
  • curate - maintain a high quality with active curation.
  • hooks - use the hook method to encourage behaviors that benefit you.


Other examples here include the story of Tinder. The founders first visited sororities and helped women install their app and post their profiles. Next, they hopped across the the fraternities nearby and the frat boys got in line to download the app and connect with their Greek sisters. In many ways, this was the best channel to find their ‘ideal customers’ - the early adopters you need who can’t not use your MVP despite its early kinks.


In every 2-sided platform, there’s always one side that’s really the product. Protect the experience of the side that’s the product, while offering a velvet rope experience to the other side.

I’m currently at Intuit using rapid experimentation to build a platform that brings together Small Business Owners and Accountants to solve long tail industry specific needs. While the experiments are still at an early stage, this model has helped us refine our thinking about how we structure our experiments. Thanks Brant for the insight!