It’s not often that startups reveal their revenue. But that’s exactly what Joel Gascoigne, the CEO of Buffer, did. In fact, he might be the most transparent CEO in the start up game. Joel not only candidly shows Buffer’s revenue in real time, but also reveals the salaries of each position in the company and regularly blogs about how Buffer got started and it’s progress.
At Hustle Con Joel’s talk will cover how Buffer got started using lean principles and continues to do so even as a successful startup. Joel will specifically discuss why Buffer uses fake door testing and regularly launches unpolished new features.
Idea to Paying Customers in 7 Weeks: How We Did It
This is the first of an ongoing series of posts called Building Buffer where we share our methods and learnings with the aim to help people and learn from others who have had similar experiences. We’d love your comments. The original article can be found here.
Rewind…
I’ve learned more in the two and a half month period since I launched Buffer than ever before. I am very excited to let you know we now have over 500 users, many of whom are active, and we are generating revenue through our paid monthly plans at a conversion rate of around 4% of people upgrading. Let’s go back to the very beginning.
A twinkle of an idea
It was a tiny idea. I wanted to take the scheduling feature of many Twitter clients and apps and make that single feature awesome. I believed that single feature was worthy of its own application. The aim was to create something genuinely useful with a delightful experience. The fundamental idea was to create a way to queue up tweets without scheduling each tweet individually. This is an idea I had after using other Twitter scheduling applications for the purpose of ensuring I didn’t flood people with 5 tweets at once whilst reading my tech & startup news in the morning. I couldn’t get it out of my head, and I’d suggested it to existing apps and they hadn’t implemented it. It was time to build it myself
Keeping version 1 minimal. No, more minimal than that.
I’m an advocate of the lean startup principles which Eric Ries proposes. With my first startup, I learned a huge amount about the principles and I tried to implement them as much as I could. I found that practice is much harder than theory. I even started coding Buffer before I’d tested the viability of the business. As soon as I realised that, I stopped, took a deep breath and told myself: do it the right way this time. It was time to test whether people wanted this product.
In Ries’ guide to Minimum Viable Products, one of the key things he answers is “how minimal should your Minimum Viable Product be?” Here’s his answer:
Probably much more minimum than you think
I had read that line so many times. I’d even told others. It was time to do it myself.
The smallest test
Here’s what we launched with:
The aim of this two-page MVP was to check whether people would even consider using the app. I simply tweeted the link and asked people what they thought of the idea. After a few people used it to give me their email and I got some useful feedback via email and Twitter, I considered it “validated”. In the words of Eric Ries, I had my first “validated learning” about customers. It was time to gain a little more validated learning.
Learning more
So we had validated that people probably wanted the product. The next thing to validate was whether people were comfortable with paying for such a product. This was as simple as adding a page in between the two which showed pricing. One extra click before they gave me their email for a notification when we launch. The extra step tests the pricing (by detecting which plan they click on) and also tests further the demand for the product (one extra click, so they must be keen). Here’s what we did:
The result of this experiment was that people were still clicking through and giving me their email and a small number of people were clicking on paid plans. After this result, I didn’t hesitate to start building the first minimal version of the real, functioning product.
The launch
I was lucky enough that coincidentally there was a little buzz on Hacker News about a “November Startup Sprint” where lots of people agreed to try and get something launched by the end of November. After initially grossly underestimating how long it would take to build the first working version of Buffer (I told people 1 week!), I decided to give myself a cut off point of the end of November, to tie in with the Startup Sprint. This resulted in building the first version in evenings and weekends over a period of 7 weeks. There were a number of features which I felt were quite vital, such as a guided step by step signup process, which I had to leave out because the end of November came round rather fast. I had committed to launch and I stuck with that commitment. Buffer went live on the 30th November and I got some great feedback from the Hacker News community.
Being prepared for a long journey with lots of course-correction
When I started building Buffer, I had already experienced building a previous product where things did not go quite according to plan. Luckily, this prepared me to be patient with uptake of the service, and to be willing to change things quite a lot until I reached something that would be truly valuable for people. It also taught be the value of customer development: to take advantage of those emails coming in by asking people questions. With my previous product, I did not reach out to enough people and say “is this a problem for you?” in order to validate whether the product was something people may want. After launching a version of Buffer I was quite embarrassed about, I was fully expecting for it to have a fairly poor uptake and to have to work a lot to adjust the product in order to gain active users and paying customers. Whether or not the goal is reached sooner or later than expected, there are always times in the ups and downs of the journey where this patience is required, so I value it as an overall mindset for Buffer.
Taking advantage when things go well
Despite being prepared for a long journey, and some things later on requiring that patient mindset, I was lucky with Buffer. It was evident that I had hit a chord with users and I am solving a problem which many people have. I also received a strong signal that the solution provided enough value to build a viable business – I had my first paying customer within 4 days of launching the “rough around the edges” product.
After the first paying customer, I took a step back, acknowledged that as a major milestone and decided a slight shift in focus was required. As a developer, it is easy to pile in more features at that point. I knew it was time to focus on marketing and further customer development. It was time to keep the balance of development, marketing and customer development with a product which had proved it was “good enough”. This has been a valuable lesson I want to take forward: when the signal is there that the product is good enough, shout about it!
What next?
There are always more challenges. Since launching I have got someone else on board to help manage the community and marketing, and I have developed a number of interfaces to the existing data in order to make sense of patterns and validate decisions. We’ve gained a huge amount of press coverage, we’ve worked closely with users on a personal level, we’ve rolled out more features, we’ve changed pricing plans and we’ve implemented an admin activity feed and done cohort analysis. I’m excited to share some of the lessons we’ve learned by doing this in another post on Building Buffer.
Have you had an experience of getting an idea off the ground, or have you had an idea and thought it would take longer to validate it? Are there things you would have done differently? I’d love to hear from you.