Do Things that Eventually Scale

"Do things that Don't Scale" famously said by Paul Graham is one of the most common (and probably the most iconic) advice given to startups at Y Combinator.

Most often than not, entrepreneurs don't even try out this advice which is pretty discouraging. But sometimes, entrepreneurs are told a version of it which I think Paul didn't originally intend to.

If we take Paul's original writeup (from 2013) and consider it the parent node, in the long interpretation chain, the closest child node should probably be Y Combinator's blog. The YC’s Essential Startup Advice writeup states "Rather, we tell startups to get their first customer by any means necessary, even by manual work that couldn’t be managed for more than ten, much less 100 or 1000 customers.".

And it later gets interpreted on most blogs to "focus on doing things manually" instead of doing things that allow startups to scale/grow quickly.

And this creates a shitstorm of child nodes spinning the same thing in 360 degrees.

Story time!

The book called "Shazam and Its Creators" by Kristi Holl tells a story of how at the time that Shazam was ready for business, there were no musical databases that the founders could access. They had to start from scratch. This was at a time before digital music was widespread when music existed primarily on CDs. In order to build an audio database, they needed access to thousands of CDs. The co-founders hoped to avoid buying the one hun-dred thousand CDs that they would need at a cost of a couple of million dollars. This is where Philip Inghelbrecht came in. He was able to arrange a phenomenal deal with Entertainment UK, the biggest wholesale distributor of CDs in the United Kingdom. Entertainment UK had one hundred thousand unique CDs. If anybody had music in its warehouse, it was Entertainment UK. Shazam didn't need full digital copies of the music itself. Using Wang's technology to recognize music, it just needed enough to make a small audio fingerprint. The deal Inghelbrecht arranged said that Entertain-ment UK would allow Shazam employees to move into its stores and pick CDs off the store shelves. Shazam would create its database using Entertainment UK's CDs.

For the sake of clarity, a more common (and again, probably the most iconic) example will be of how the Airbnb founders originally offered to “professionally” photograph the homes and apartments of their earliest customers in order to make their listings more attractive to renters. Then, they went and took the photographs themselves. The listings on their site improved, conversions improved, and they had amazing conversations with their customers. This was entirely unscalable, yet proved essential in learning how to build a vibrant marketplace.

The process was indeed manual, but the hypothesis behind all of that was to have better pictures on their website, which obviously Airbnb scaled later.

Now you can stop and ask, well, this is all good but...

Yes, I know you're thinking about companies like Doordash where the co-founders used to deliver "hummus" themselves. And this story actually helps making the case for our next point.

These kinds of hacks allow the founders to get the lay of the land so to say. The Doordash founders did all this to get direct feedback from their customers which in turn eventually helped them to build their company the way it is today.

Why Do Things that Don't Scale?

You may be thinking "wow that is confusing". You would be right, but let's unpack exactly what it means for the sake of the writeup.

The advice majorly breaks down to address three things:

1. Solve the dreaded "cold start problem”
2. Gain deeper insights
3. To just "get going"

But, what was the purpose of this blog?

Let's circle back to Paul, who already told us what I'm trying to explain, he did it subtly though, using just three words.

gradually. automate. bottlenecks.

Some startups don't drill down into, understanding the problem they're solving, the industry they're in, their customers and underlying pain-points, achieving a breakthrough by solving the "cold start problem" but only focus on the "get going" bit of the equation and later find themselves spiralling downwards.

Just doing manual work for the sake of doing manual work is a no go.

Doing manual work to get a headstart is all good, but not focusing on how and what we're doing, getting deep insights about the processes and how it eventually will be done, is bad for business.

Moral of the story, Do Things that Eventually Scale.