5 Things That Seem Essential That We Launched Buffer Without

626 Flares Filament.io Made with Flare More Info'> 626 Flares ×

This is the third article in our new series with advice on building a business, company culture and life-hacking from Joel, CEO here at Buffer. You can grab all posts here.

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 charging 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.

PS: If you liked this post you might also like “The Habits of Successful People: Be Inconsistent” and “6 Simple Things You Can Do Every Day To Be Consistently Happy

Photo credit: Barefoot Photographers of Tilonia, More on Joel’s blog.

  • Heather YamadaHosley

    Very interesting to learn about your thought process behind not including each of these features and the impact afterwards. Thanks for sharing, great series of posts!

  • http://www.dennisgorelik.com dennisgorelik

    Are these static pages needed at all? You didn’t really need them at the launch time, do you need them now?

    • http://www.highperformancelifestyle.net/ Kosio Angelov

      All websites should have a terms of service and a privacy policy page at least. Don’t quote me on it as I am no lawyer, but I believe it is the legal and ethical thing to do. Plus, it makes your website look legitimate in the eyes of the consumer. A website that does not have about, tos and a privacy statement can look a little shady. When you launch or test, definitely can be skipped, once you have some traffic rolling in and paying customers, they are a must for me.

      • http://www.dennisgorelik.com dennisgorelik

        Google Analytics data for PostJobFree.com (last 30 days)
        Total: 676,657 Unique Pageviews
        TermsOfService.aspx: 397 Unique Pageviews
        About.aspx: 119 Unique Pageviews
        That’s less that 0.1% for both of these pages together.
        Both “Terms of service” and “About us” pages are clearly visible on the home page (in the footer).
        In spite of it, 99.9+% of users do NOT care about these pages.

        • http://www.highperformancelifestyle.net/ Kosio Angelov

          My point isn’t that the about and TOS pages are going to generate large amounts of traffic, but that the absence of them might drop your conversion.

          How many people ever click on those SSL security and “hacker safe, checked on X date” buttons and links on a check out page? Probably nobody, but their presence makes the consumer feel more secure and is proven to raise conversion.

          How many legitimate sites do you frequent that don’t have an about and TOS pages?

    • http://modeista.com/ Martin Wawrusch

      You need a privacy policy and at least some rudimentary terms of services. Otherwise you open yourself up to potential future litigation. In certain states and countries it is required to have a privacy policy by law, and it must contain certain provisions.
      Others require naming a responsible person, if you fail to do that you will get sued by predatory law firms. That was a huge business in Europe for some time.

      I suggest you spend just one hour watching a court session, it is eye opening and very scary.

  • http://www.sociallysorted.com.au/ Donna Moritz

    Great post Joel – I just launched an online program (that actually lists Buffer as one of my 5 “essential tools” so that people reduce overwhelm) but I also had to strip parts back and it meant for a better product – less content, less overwhelming for users and then when you add parts in you can over-deliver! I have been loving this concept from the book Rework and now you are posting about it. We live in on overwhelmingly distracting world – anything that does the job without bells and whistles is a winner in this day and age!

  • Louisa

    I very nearly gave up with buffer over the sign in system in the early days – don’t really know why I persevered but very glad I did. Other features were a bit irritating but it feels good that you are continually monitoring and improving.

  • 3upgolf

    Joel – great post. Feature creep is one that any developer needs to be aware of. It’s all to easy to just “throw in one more fix” or implement a quick feature to hold the release off for a day.

    Something to help avoid that is to simply remember, there is no 1.1 without a 1.0. You can always deploy today and fix tomorrow. In fact, you’ll have to fix at some point in time, that’s a guarantee, so why not gets started with the evolution of your software sooner rather than later? :)

  • Ashley Read

    Hi Joel, great post! I love the insights you share about building Buffer and your startup journey. It’d be great to see a follow up post on how you decided (and still decide) the priority of adding new features. For example, did you add ‘change email, forgotten password, delete account’ before ‘editing tweets’? If so, did you make the decisions based on customer feedback?

  • http://www.seannisil.com/ Sean Nisil

    I love the interaction that organically occurs through a lean process like this. It allows the user base to speak into the future development of the service.

  • http://ifdattic.com/ Andrew M.

    Will have to try it in my new project – just adding what is needed. Was thinking already about doing something similar, just it’s no so easy to tell yourself “hey, stop, just do something that works and then add all the fancy stuff”. But it should be a fun experiment & experience.

  • http://doubtproof.wordpress.com riz

    “Do they understand it? If they understand it, is it useful for them? Stay laser focused on these questions.” — Good points to think about for me. :)