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

How to start your startup in 4 steps

Having started my latest venture just over 5 months ago, and having just reached ramen profitability, I want to share some of the elements which made this startup “work” compared to some of my previous attempts. The first and arguably hardest part of a startup is actually starting, and that’s what I’m going to focus on with this post. The Internet is literally littered with the remnants of my many failed attempts (not necessarily a bad thing), so there are things I’d avoid repeating.

If I was to create a new startup, here is what I would do:

1. Have an idea

This is undoubtedly a key part, but don’t give it too much focus. If you have an idea, that’s fantastic. If you don’t, try and raise your awareness of the daily activities you carry out. Particularly pay attention in the areas which you are passionate about, because it’s important that you work on something you love. Pay attention to anything which you think could be more efficient or less painful. The best ideas are ones you will use yourself every day, and would pay for if they existed already.

A side point about ideas is that you will learn far more by being in the process of working on a bad idea than you will by waiting for the perfect idea. Even if you have the tiniest idea in the back of your mind, you will probably benefit more by going for that, even if it doesn’t work out. I certainly attribute much of the success I’ve had with Buffer to my previous experience.

2. Cut it down

This is very important. If you have an idea, break it down until you think it’s too small to be of value. That’s what you should consider your first version, in fact that’s probably too big too.

If you don’t cut out features from your initial vision, you’re much less likely to ever launch it. I’ve been there many times myself. Try to develop a fear of not shipping your idea.

Another thing to note, is that the idea of a big splash launch is worth questioning. Firstly, to link the big splash with the software being ready is very dangerous, and secondly a mindset of a big splash is inevitably going to cause you to delay getting feedback on your idea, which is the next step:

3. Share the idea, get feedback

This is one of the most important steps, and often the one which is missed out almost entirely. A lot of the time, it’s the step that doesn’t come naturally to a lot of people, and that was certainly the case for me. Missing this step could easily kill your startup.

There are, of course, many smart people arguing how important sharing your idea and getting feedback is in order to succeed. I wholeheartedly agree with this, and I believe we should approach our idea as a hypothesis of something we think could work, and we should be striving to validate the hypothesis by rigorously testing it.

However, there is another crucial benefit to getting feedback, and that is motivation. I’ve found myself lose motivation on something when I’ve worked on the development for too long without getting feedback, and I’ve talked to many other people starting up and found that this is key.

Get feedback to validate your idea, but more importantly get feedback so you feel good about what you’re building. One or two people saying “I can’t wait to try this” will do wonders for your motivation.

I can’t stress this point enough. It’s not buggy technology or a faulty marketing plan which will kill your startup, it’s losing motivation. Remember, you can get feedback without the product existing.

4. Go with your gut

If you’ve got this far, then you’re doing very well. In my experience, going forward from here is a matter of going with your gut. In the early stages, it’s not wise to pay too much attention to split testing or other ways to try and be confident about your decisions. Learn to act without complete information. Just be sure to balance building with feedback.

How did you get your startup off the ground? Are you about to start something? I’d love to hear from you in the comments. Also, if you want to bounce any questions off me privately, I’d love to help.

Photo credit: aartj