5 things that seem essential that we launched Buffer without

It’s a long time ago now, however I still remember it very well. When I first went about creating the Minimum Viable Product (MVP) for Buffer, there was something I kept very clear in my mind.

When I came across Eric Ries and his work on the Lean Startup while working on my previous startup, I tried to read almost everything he had created and watch every presentation he had done. I found his presentation on the Minimum Viable Product and remember this answer to one of the questions from the audience:

Most entrepreneurs’ instincts for what is the minimum viable product are like 10 times off. So, maybe you’re one of those rare entrepreneurs who has that gut instinct for creating an MVP, but just in case, just check out whether it’s possible that you could accomplish your strategy and learn something interesting with half the features, and maybe if you want to be really bold with half again, and just imagine: what would that look like for customers?

As a result, I had in my mind the whole time when I was putting together the first version of Buffer: how can I go even more minimal here? In fact, as we have grown, we have also incorporated this into the culture with a key point of our “Be a ‘no ego’ doer” value to often asking ourselves the question “what can we do right now?”

I’ll even admit that with all of this knowledge and even while I kept asking myself “do I really need this?” I was headed clearly along a path of launching with far too many features. In the end, I luckily had committed to a “November Startup Sprint” concept on Hacker News where a group of people had all committed to build and launch something within November. Oh, and I still launched the Buffer MVP on November 30th, 2010 (with no remaining days of the November Startup Sprint).

However, all these things combined helped me to launch a very minimal version of Buffer and gain early validation for the idea and feedback to guide our direction and for which bugs and features to prioritize moving forward. So, here are the 5 things we launched Buffer without, which could be seen as essential:

1. A paid feature mentioned on the pricing page: your own details for analytics

This one was interesting. I think it was perhaps laziness in the end, but with my own deadline approaching it took some discipline to decide “I can launch without this feature”. was an advertised feature for the paid plan, yet without launching I had no idea if anyone would pay for Buffer, so it made a lot of sense not to build the feature: I had little validation for it! I was lucky that the first paying customer was after 3 days, but they didn’t ask me about the feature, so I still didn’t build it.

When the second customer started paying for Buffer, I remember them emailing me and asking me about a text box for his details that “did nothing” when he filled it out. So, I quickly fixed that and emailed him back to say “try now”. In hindsight this was a great way to validate before building.

2. Automatic upgrade and immediate access to paid plan features after paying

An auto-upgrade process is one of those things that would be easy to think is essential when you’re charing for a product. What an awful experience it would be if they had to wait until I upgraded them manually myself. However, that is exactly what happened with the first handful of Buffer customers.

I was using PayPal and as many will know their Instant Payment Notification (IPN) system is not the easiest to code in order to have auto-upgrade for customers who pay. I had no idea whether it would be 3 days, 3 weeks or 3 years before the first paying customer, so why spend time on a smooth process for people who upgrade? I instead chose to spend time on work that might help me get that first paying customer.

When someone upgraded, I got a standard “someone sent you money” email from PayPal and then rushed to the database to manually upgrade them. Sometimes I got there fast enough, often though people noticed. Here’s an email I received which is typical of the first few paying Buffer customers:

Hi Joel,

I upgraded, but I’ve still got a free account. How do I get the account to upgrade?

This could be seen as an awful experience and very damaging. The crazy thing? The result was quite the opposite. This “issue” actually triggered an interaction between me and these users, and made them super loyal. People loved to chat with the founder.

3. Change email, forgotten password, delete account

Perhaps these kinds of features are much easier to build and have in place from day one with the kinds of frameworks available now. However, I think these are features that do very little to help you learn and validate whether people have a need for your product. If they might add any delay at all to your launch, do without them!

4. Editing tweets which you’ve added to your queue to be posted

In the first MVP of Buffer, if you added a Tweet to your queue, you couldn’t edit it. If you wanted to edit it, you’d need to delete and add it again. Tiny typo and want to correct it? Tough luck. This is one of those features that seems small, but I can assure you they all add up. I truly recommend you are ruthless about avoiding these kinds of features, so that you can ship your product and learn from what happens after you’ve launched.

5. Static pages: about page, terms of use, privacy policy

You know when you need to get on with some work and you tidy your room instead? These are those kinds of tasks when working on your not-yet-launched startup. It is so tempting to have everything looking nice and tidy for the launch, but these pages are so standard and won’t help you validate whether anyone will use your product. Showing that there is a human behind the product can be a benefit, but I’d just advise that you add a link to your Twitter profile in the footer instead of building fancy pages.

The goal here? To learn.

That’s the key thing to keep in mind, and it’s so easy to forget. You can build something pretty or make the code super clean if you want to, but that will just be an exercise for yourself at this point. What will help you to validate the idea and see whether you should continue along this same path is to get the product in front of users and talk with them and observe what they do. Do they understand it? If they understand it, is it useful for them? Stay laser focused on these questions.

One of the key lessons I’ve learned along my journey is that lean startup seems obvious, almost common sense, but it is much harder to do in practice. These tips are what I would try to stick to in order to really follow the lean startup concepts in the earliest stages.

Photo credit: Barefoot Photographers of Tilonia

Start something small

The other day I was listening to Dale Carnegie’s How to Win Friends and Influence People and and I found it amazing how this book, which has now sold over 15 million copies, originally started:

I prepared a short talk. I called it ‘How to Win Friends and Influence People.’ I say ‘short.’ It was short in the beginning, but it soon expanded to a lecture that consumed one hour and thirty minutes.

After giving this talk for some time, Carnegie found that the attendees started discussing their experiences and some “rules” emerged. Eventually the talk became a course, and there was a need for a textbook of sorts. Here’s how the now famous book became a reality:

we started with a set of rules printed on a card no larger than a postcard. The next season we printed a larger card, then a leaflet, then a series of booklets, each one expanding in size and scope. After fifteen years of experimentation and research came this book.

I found that absolutely fascinating. The book came out of a short talk and a few notes on a postcard-sized piece of card. Interestingly, I think a lot of the really big successes start like this.

The dangers of “big”

The challenge for a lot of us, is that when we go about our lives we interact with so many “big” things, and we forget or don’t even know how they originally started. It’s difficult to understand how the evolutionary process of products and brands contributes and is vital to what they are today. We also all have big aspirations and want to get there fast.

I’ve personally made the mistake of trying to jump to “big” too soon many times before: the goal my previous startup was to kill the business card, and we struggled to execute effectively on a much smaller scale. I think there are probably countless other examples out there where founders try to have an immediately huge vision.

Great things start small

What I’m starting to notice more and more, is that great things almost always start small. Most of us know that Branson started the Virgin brand with a student magazine, but Virgin is just one of many examples which shows that the reality is counterintuitive: actually, the best things we know and love started as tiny things.

I’ve found that if I look into my own life, I find similarly that some of the most important achievements I’ve made started as little projects. My startup Buffer itself is a great example: it started as a two page website and in addition the short blog post describing this process has now turned into a talk I’ve given more than 30 times.

Make it smaller: you’re more likely to succeed

One of my most interesting realisations from this thinking and from seeing many examples is that actually in order to succeed, we probably should think and execute on a smaller level. If we do this, we’re more likely to succeed. I wrote about this previously, in the context of not trying to change the world right away. I was pleasantly surprised when Paul Graham wrote a comment in the discussion on my recent article which suggested similar:

Don’t even try to build startups. That’s premature optimization. Just build things that seem interesting. The average undergraduate hacker is more likely to discover good startup ideas that way than by making a conscious effort to work on projects that are supposed to be startups.

Start everything with an MVP

I think Eric Ries really nailed this concept with his notion of the Minimum Viable Product. The great thing is, we see that even historical successes like Dale Carnegie’s How to Win Friends and Influence People, published in 1936, started as just a short talk and a few notes on a small piece of card. That was the MVP, and it was a perfect way to start. And if the content in this smaller form hadn’t resonated with people, my guess is that the book wouldn’t even exist.

I believe that we could and should start to think about everything beginning as an MVP, starting much smaller than we might currently think about it. Andrew Chen has a great example: decide what blog posts to write based on Tweeting the potential headline. I think there are countless other opportunities for this too, in all areas of life.

Have you thought about the relationship of big thinking to success? Did something work out better when you started smaller? I’d love your thoughts on this topic.

Photo credit: Toby Bradbury