Achieving scale by doing things that don't scale
November 14, 2011starting up
Over the past few years of my journey with building startups, I’ve made a conscious effort to absorb as much of the fascinating insights and learnings of those more experienced than me.
Startups and large companies
One of the repeated insights I came across which never quite fully sunk in when I read it on Steve Blank’s blog is the idea that a startup is not just a smaller version of a large company, and that you should operate very differently as a startup. One of the key takeaways tied to this idea is the notion of doing things that don’t scale.
Doing things that don’t scale
Airbnb is the most famous high scale company to do this and succeed. Interestingly, however, they didn’t start with this idea:
"We thought that everything that we did here had to someday support hundreds of thousands to millions of users"
This belief is completely understandable, and it was my approach for a long time too.
The turning point for Airbnb was when they got into YCombinator and Paul Graham suggested they do things that don’t scale.
Does this really work for massive scale?
To really dig into this idea, I decided the best thing to do is to take the largest scale Internet business I can think of and investigate their beginnings. What I discovered in an early interview Mark Zuckerberg had about Facebook is truly fascinating. His response to “what comes next” was the following:
"There doesn’t necessarily have to be more. Part of making a difference and doing something cool is focusing intensely. There was a level of service that we could provide when we were just at Harvard that we can’t provide for all the colleges, and there’s a level of service that we can provide when we’re a college network which we couldn’t provide if we went to other types of things."
This means that in the early days the growth of Facebook was largely affected by Zuckerberg deliberately choosing to do things which wouldn’t scale. By taking this approach, he built huge value for his target users.
What does it mean to do things that don’t scale?
This technique is one I read about so many times throughout my journey with OnePage. When I made the decision to take everything I had learned and build Buffer, this was one of the things I disciplined to experiment with.
In the early days and even to this day, I have made an effort to do things that don’t scale. I’ve found that there are two key characteristics of “things that don’t scale”:
They help you avoid development before validating it’s required
This is certainly a key factor, especially in the early stage of a startup. Any time you can save on an activity which you haven’t yet validated as beneficial is worth doing manually until you can no longer do it manually.
Doing it “manually” gets you more benefits than if automated
I think the more important characteristic may be that when you do the task manually to begin with, you actually get more benefits than if it was automated. For example, emailing someone personally and taking care to read a little about their interests and find something to relate to, will give you a much higher response rate and trigger fascinating and useful conversations.
How can we use this approach for our startups?
With my latest startup Buffer I took this concept and used it to my benefit more than I ever did with OnePage. To briefly share real examples, here are two from the course of the journey so far:
Personally email the first 1000 signups
This is something Rob Fitzpatrick’s great article reminded me of. In the early days, I was in touch on my personal email address with almost everyone who signed up for Buffer. With low volume, I could always respond immediately and people loved it.
Charge without fully implementing a payment system
Some of the very early Buffer customers will know that I not only launched the product with paid plans from day 1, but that I also didn’t fully implement the payment system. When someone upgraded to a paid plan, I would email them personally as soon as I received the email from Paypal.
I didn’t do this to avoid the work, I did it because I had no idea whether it would be 4 days or 4 months before the first payment for Buffer. It would be a waste of programming effort to implement a slick payment system without validation with a few paying customers. Luckily, it was only 4 days until the first payment and after about 1.5 months and 6 new customers I implemented the full system.
With Buffer, doing things that don’t scale has brought us a lot of success, and the times when we make the big progress always comes back to doing new things which will provide enormous value but which we will have to adjust as we scale further.
Photo credit: OZinOH