In the last 6 months, we’ve quietly shifted the direction of Buffer. Our adjustment is now almost complete and we’re charging ahead with our new vision. It’s interesting to reflect on how we came to realize that a change was needed, and how we went about finding our new path.
The original vision
The earliest idea of where we wanted to take Buffer was that we aimed to be a sharing standard:
Our vision is to become a new sharing standard across the web and apps, and to set the bar for great customer support.
For us, the idea with this was to be a very widespread consumer product with a low price point. We had been inspired by Evernote and casually used the phrase “The Evernote of Social Media” to describe Buffer. Evernote at the time had tens of millions of users and its business model was super simple: an optional pro version at $5/mo.
In the beginning, we had a $5/mo plan and a $20/mo plan, in line with this philosophy. Over time we adjusted our price to $10/mo and dropped the higher priced plan. Interestingly, for some time we had a $100/mo plan and people very readily paid that to manage additional social media accounts and team members. At the time, however, we were entirely focused on becoming a widespread tool and decided we must stay simple. We ditched the higher priced plan and attempted to scale as a platform rather than adding more power to the product itself. If we wanted to be a button across the web and apps, it had to be a simple idea.
What we learned attempting our original vision
In some ways I wish we had perhaps realized sooner that our vision to be a sharing standard was not going to work. At the same time, we gained many benefits by pushing ourselves to be a widespread product used by many individuals and small businesses.
Growth slowed, conversion rates dropped
We made a lot of progress in becoming a sharing standard. We made partnerships with Feedly, Pocket, Echofon, Reeder, TweetCaster and many other apps and services. I believe these integrations are still incredibly useful for our users (I personally am using the Feedly and Pocket integrations daily).
One of the key learnings we had in fulfilling a large part of our original vision was that partnerships and integrations rarely give you distribution. A key part of this vision working for us was tied to the integrations leading to many new Buffer users. We certainly got a good number, however we always had much more success with signups direct from our own web and mobile apps.
Not only did we not get a significant number of new users from the integrations, we also observed a drastic drop in conversion rates (to active users and eventually paying customers) for people who came from 3rd party apps. In hindsight this is not too surprising, since these users are not in that app primarily to use Buffer.
The benefits of freemium
While we found many flaws in our original vision and eventually decided that we needed to make an adjustment, I couldn’t be happier with the result of that journey.
Luckily for us, generating revenue was always a key focus (we charged from day 1). Therefore, even though we focused on having a wide reach, we always looked at our conversion rates and cared about revenue. In the journey of growing to 1 million users, we grew to significant revenues, to the extent we could be profitable and not have pressure to raise further funding.
In addition to building a profitable business, we have a true freemium / SaaS scenario and scale to be able to grow by understanding user patterns and running a/b tests and other experiments. We have 2,500 new users every day and consistent conversion rates to our $10/mo awesome plan as well as $50+/mo business plans.
I’ve observed that as startups grow, they tend to move up market. They introduce more powerful offerings and charge more. They start doing enterprise sales. We’re even on this journey now. At the same time, it’s incredibly powerful to have a free or lower priced product and have a large top of the funnel. We’re lucky to have both, and it’s much harder to try to fill that room at the bottom later.
The valley of death
Something that’s become increasingly clear to me as I’ve traveled this path is that I think there is a dangerous middle ground between trying to be super widespread and mainstream (and monetizing via ads) and focusing much more on value and power (and monetizing via subscription payments).
The way I see it, is that if you want to monetize through ads you probably need 100M+ users. If you want to build a solid freemium offering you only need a few million users, if that. Pure SaaS and it’s even less. But if you build something that people won’t pay for directly and end up with only 10 or 20 million users, you might be in a tough spot.
We’re now completely focused on building a world-class freemium and SaaS product to solve problems around social media.
The new vision for Buffer
As a result of our learnings and reflection on the slowing growth, Leo and I had a series of conversations towards the end of last year and decided on our new vision:
The vision for Buffer is to be the simplest and most powerful social media tool, and to set the bar for great customer support.
When we decided to make the change, we chose to approach it in a lean way. We didn’t talk too much about it until it really started working. To begin with, we simply brought back higher priced plans and reached out to some key customers hitting the limits of existing plans.
Fast forward to today, we have over 1,000 business customers and it already contributes 15% of our revenue. I’m excited about our new path. We’ve found it is incredibly fun to work with larger customers who have real problems and a need for a powerful social media solution.
Have you made any key decisions around changing the direction of your startup? I’d love to hear about your experiences and learnings. If you have any questions about the journey we’ve had with Buffer or our new direction, leave a comment below!
Photo credit: takasuii
It’s no secret that I’ve personally been hugely impacted by Eric Ries’ work and the Lean Startup movement. Buffer would not be where it is today without his writings and videos opening my mind to a different way of approaching a startup.
For me, lean is completely about building and approaching things in a way which minimizes the amount of wasted time and effort. A startup is a scary adventure to embark upon because there are so many unknowns. It’s different to a service business in that you have no idea whether your product will actually be adopted. As a result, it’s easy to accidentally build products or features which, in the end, don’t resonate as you had hoped.
Being disciplined about approaching things in a lean way is incredibly difficult. In theory it seems straight-forward. In practice it’s super challenging, and we’ve had some hits and some big misses too.
1. The founding of Buffer: going from an idea to paying customers in 7 weeks
When I finished studying, I was completely set on creating a startup. So I did just that, and I made it completely official. I told everyone I was doing a startup, I incorporated the business and we got a small government grant. I built a product and kept adding more to it. In the end, I hadn’t validated that it was enough of a pain point for people, and it grew very slowly.
With Buffer, I took a different approach. It was just a side project, and I was in no rush to call it more than that. I stopped myself as soon as I realized I’d spent a couple of days coding without validating the need. Then I sat down and thought about how I could see whether people need this product, without building it.
I created a landing page which looked just like it would if the product had existed. That’s the beauty of landing pages, they have almost the same flow through them whether the product exists or not. So I could see whether people would sign up for the product, and then ask them for their email at the end of the process.
I had email conversations and a couple of Skype calls with people who gave me their email. I talked about the problem I was solving and learned a huge amount from these interactions. This is known as customer development and I can’t recommend doing it highly enough.
This process proved to be a success. Through the conversations I learned that others had the same problem and were receptive to a solution. That gave me the confidence to build it, and 7 weeks later I had the first version of the product. 3 days after launch, someone started paying for Buffer. We’ve steadily grown recurring revenue since then. February just came to a close and revenue came in at $333,000.
Read more about Buffer’s lean beginnings
2. Creating a brand new Buffer browser extension experience
One of Buffer’s key features right from the beginning has been that we have a browser extension which allows you to very easily share a web page or blog post you’re reading. You can share it right away or schedule it to be posted later to all the key social networks.
Throughout 2012 we saw a huge rise in sharing of pictures to Facebook, and we started sharing more pictures ourselves. We found they did very well and received a lot of engagement. That’s when we had the idea to transform our extension to allow sharing of different types of media: links, text or picture. We wanted to make it super easy to share a picture from the page you’re looking at.
So (and here comes our big mistake) we got to work building a brand new version of our browser extension to allow you to pick images off the page to share to Facebook or Twitter. It looked a little like this:
We spent several months working on this alongside other product tasks, and spent some time polishing the experience. We loved the experience ourselves, we were enjoying using it to much more easily share pictures from the page. Then, we were starting to think about when we would launch it to everyone, we though “maybe we can let a few people try it out first”. We almost launched it to everyone at once, which would have been a very bad idea.
We pondered when we could get some people to test it, we thought maybe we could send an email in the next week. Then we thought, why not do that tomorrow? Or how about we send a Tweet right now and ask people if they want to try it. So that’s what we did, and we got on Skype with people and asked them to share their screen and reaction as we switched on the new extension experience.
The feedback from those screen-sharing Skype calls was shocking. 6 out of 7 people were completely confused about the new UI. They thought the picture tab would let them choose the thumbnail for the link they were sharing to Facebook (you could already choose that in the link tab). The biggest mistake we made was that we knew exactly what we wanted to use the feature for ourselves, so the UI made complete sense to us. It wasn’t clear at all for someone seeing it fresh. The worst part is we could have known this months earlier if we’d just done a few mockups and shown those to these same users.
3. Brand New Buffer: a completely redesigned web experience and new iPhone app
In the Summer of 2012 we started to think about some key improvements we should make to the web dashboard for Buffer. We had accounts listed horizontally and this meant there was a natural limit by the width of the page. We wanted to create an interface that would be more flexible. What started as a simple adjustment from a horizontal menu to a vertical menu became a half year project including a complete redesign, new features and unified web and mobile app experiences and design.
One of the core tenets of lean startup is to have small batch sizes. Somehow that went completely out of the window and we decided that we needed to group all of these changes together. We got hungry for a big splash launch and decided that’s what we’d aim for. We envisaged being on all the tech sites and having a surge of new users.
As with everything, this project took longer than we expected. In the end, we managed to wrap it up before the end of the year, which was a relief.
We were successful in getting that big splash we had dreamed of. We emailed our several hundred thousand users and wrote two blog posts. We were covered by Lifehacker, TechCrunch, Forbes, VentureBeat, TheNextWeb and more. I remember the excitement as I took this screenshot of our Google Analytics real-time where we had 766 people on Buffer at the same time:
It was several months later when we started to truly focus on metrics and growth that we saw the mistake this big launch was. The problem with grouping all your changes together is that it’s difficult to see how each of the individual changes has impacted everything.
From one day to the next, we had reduced our overall activation by 25%. We count a user as “activated” if they connect a social network and post at least once using Buffer. Activation dropped from 51% to 39% as a result of this launch. In the cloud of buzz and signups, we had no idea and no reason to suspect there was a problem. Upon closer inspection, it was even worse. Taking activation for web by itself, it had actually dropped by 50%. The new design and signup flow caused activation the web contribution to go from 24% to 12%:
The only positive finding was that our new iPhone app was certainly a success, almost doubling activation for people signing up from the iPhone app:
The combination of activation decreasing so much on web and iPhone activation increasing made it hard to see there was a problem. It took us several months to adjust our signup flow to bring the activation back up to previous levels. If we had a/b tested and looked at the metrics of the new web experience with a small percentage of our users before going live with it, we could have identified the drop in activation and fixed it before our big launch. We could have had months of higher activation.
The lesson from this for us is to always launch things in small batches, and to measure the impact of everything we do.
4. How Buffer for Business came into existence, and how it became 25% of our revenue in just a few months
Half way through 2013, Leo and I started to think about our vision for Buffer and whether it was playing out in a way we were happy with. Our vision was to be a sharing platform across the web and apps, and we’d made a lot of progress with our Buffer button across websites and blogs, and our iOS SDK inside Feedly, Pocket, Instapaper, Echofon and others. Our growth was still good, but it was slowing.
We had the amazing chance to meet with Jason Lemkin, who is incredibly experienced and sharp about what it takes to succeed as a SaaS company. We had thought for some time about expanding Buffer and having a product focused on business customers. So far, we’d talked ourselves out of it with the common argument that we should stay focused. Jason gave us some of the best and most controversial advice I’ve had, which was to “do everything, just try it”.
We left that meeting excited and decided we might as well move ahead and see what happens. My co-founder Leo took the lead on investigating the social media problems and needs of businesses.
We had two key product ideas which could be attractive to businesses. The first one we were super excited about: a way to allow the whole organization to connect their personal social media accounts and help spread the news of product launches and press releases. We thought it could be huge for marketing departments. Our second idea was an extension of Buffer, to make it work for businesses and agencies with large numbers of social media accounts and team members.
Leo reached out to several existing customers hitting the limits of our $10/mo plan and jumped on dozens of video calls. He asked them about their problems and shared our ideas to see if they resonated. We were so excited about the idea of supercharging marketing by making use of the whole company’s employees, and were surprised by how few people wanted that product. The best feedback Leo had was from a head of marketing who said:
"I can’t rely on employees to do our marketing. It’s a nice to have, but we wouldn’t pay for that alone."
The idea to make Buffer more powerful was a huge hit. People at the limit of the $10/mo plan were desperate to use Buffer with more than 12 social accounts, which was our current limit. We had a lot of pent-up demand.
So we moved ahead on allowing people to use Buffer for more than the current $10/mo plan. We reflected on how to do this in a lean way and came to the conclusion we could do it without any new features or work on billing. We charged them through the feature to create and change a billing plan in Stripe, and put them onto a plan in our admin area that removed the 12 accounts limit. With no new product or marketing, we suddenly had 50 customers and Buffer for Business generated $10,000 in new revenue, 6% of our total.
We then kept talking to these customers and discovered a handful of additional problems we could solve for them and include in a new product, which we launched as Buffer for Business a couple of months later. It’s been a big hit and is already 25% of our monthly revenue.
Let me know if you have any thoughts or questions about our focus on being lean at Buffer. I’d love to hear from you in the comments below!
P.S. Like using the lean startup approach to build products? I’d love your help - we’re growing the team at Buffer.
Photo credit: Betsy Weber
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.
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:
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!
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.
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
I’m a huge believer of the lean startup movement and the concept of validating ideas as quickly as possible. I think wasted time and resources are disastrous and no matter how much you love an idea, if it isn’t growing and becoming viable to build further, the fun won’t last. However, what I urge you to do is focus on the lean startup notion of your startup idea being a hypothesis.
Since your idea is a hypothesis, you can make it whatever you want. Think big, get excited by your idea. It will be amazing. Sure, you’re going to go ahead and validate it, but at least start by trying to validate that you could work on something really damn cool.
Do what you want. Build something that the thought of makes you jump out of bed each morning. Test the assumptions and make changes based on what was incorrect, but out of the possible options for the next path, choose to first try the path which maximizes your excitement.
Photo credit: Michael Wallace