5 things that seem essential that we launched Buffer without

April 1, 2013starting up

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 bit.ly 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”. bit.ly 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 bit.ly 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 bit.ly 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