I enjoy sharing things on Twitter and Facebook, but I'm totally inconsistent. One day I'll tweet a few times, then nothing for three days, then a mad burst of sharing and retweeting. If you're like me, Buffer is your new favourite app. It schedules your tweets and Facebook posts for you, creating a consistent social media presence. (It also supports Any.do and LinkedIn, and is available on iOS and Android.)
We talked to Buffer's co-founder Joel Gascoigne about the inspiration for the app, his biggest challenges, and what it feels like to celebrate one million users.
Where did the idea for Buffer come from? Were you trying to solve a problem you'd experienced, or did the inspiration come from somewhere else?
The idea for Buffer came to me after I had been using Twitter for about 1.5 years. I had started to share links to blog posts and quotes I found inspiring, and I found that my followers seemed to really like these types of tweets. I would often get retweets or end up having a great conversation around the blog post or quote. That's when I decided I wanted to share this kind of content more frequently, because the conversations being triggered were allowing me to be in touch with some super smart and interesting people.
So, with my goal of sharing more blog posts and quotes, I started to do it manually. I quickly realised that it would be far more efficient to schedule these tweets for the future, so I started to use a few available Twitter clients to do this. The key pain I ran into here was that I would have to choose the exact date and time for the tweet, and in reality all I wanted to do was to tweet "five times per day." I just wanted the tweets to be spread out so I didn't share them all at the same time when I did my daily reading. For a while, I used a notepad and kept track of when I had scheduled tweets, so that I could try and tweet five times per day. This became quite cumbersome, and so my idea was born: I wanted to make scheduling tweets 'x times a day' as easy as tweeting regularly.
After you came up with the idea, what was the next step?
I had spent the previous year and a half building another startup, and I hadn't had too much success. I made lots of different mistakes, such as assuming what people wanted and just adding features without getting any validation. During that period, I became fascinated by the work of Eric Ries and the Lean Startup methodology he was writing about. I was one of his very early blog subscribers and I watched many of his presentations. My failure with the previous startup combined with the ideas around the Lean Startup gave me a key realisation: if I wanted this new idea to be more than just a hobby and tool for myself, I needed to test whether other people would find the idea useful.
So, I decided to take a lean approach. First, I wanted to test whether people would use the product. To do that, I created a super minimal two page website, without building the product at all. Here's what it looked like:
I shared this with my followers on Twitter. I was lucky to have 1700 followers at this point as a result of actively sharing all my updates and lessons from my previous startup (one reason I recommend being super transparent) and so I had quite a few people hit this landing page and put in their email. As soon as they entered their email, I had a very personalised email which they received, and I asked for their feedback about Buffer. I tracked the metrics here, but the actual conversations were what was most useful.
A bunch of people didn't understand the product at this point, and quite a few said they wouldn't use it. Luckily, I came across a handful of people who identified with the pain point I was having myself, and they wanted a solution too. The next test I did before building out the full product was to see whether anyone would actually pay for this. So, I added a third page in between these two:
I tweeted again about the landing page and had more people sharing their emails. Again, it really wasn't about numbers or metrics at this point, it was much more about having conversations. This time, I tried to steer a number of the conversations to pricing, and specifically, figuring out whether people might pay for the product. Again, many thought this was absurd, or just didn't see the value. We learned a huge amount about how we can better describe Buffer. At the same time, there was a glimmer of hope for me as a few people said that if this product existed, they would pay for it. It was time for me to get to work and build out the full product.
(I actually wrote about the full details of this exercise in a previous post titled Idea to paying customers in seven weeks: How we did it.)
How did you choose which platforms to target and which to ignore or wait on?
This became quite a simple decision. I'm a big fan of the following quote:
"Do what you can, with what you have, where you are." - Theodore Roosevelt
Eventually our revenues would grow enough that my co-founder Leo and I could jump on a plane and find a way to base ourselves in San Francisco. To begin with, however, I was in Birmingham in the UK and I decided to try and make it work just with what I had. This also helped my decision of which platforms to target. I targeted only the platforms which I personally knew how to code. So, I started purely with the web, and I built a simple web app and a Chrome extension. I had no idea how to build an Android or iPhone app, so these would have to wait.
It just so happened that these restrictions are also a great way to most quickly validate and grow a startup. See, if you try and launch with all platforms, it's going to delay launching and that means you need to wait sooner to find out whether anyone even wants what you're building. I cut down the feature-set massively and luckily was able to launch the first version of the product in seven weeks.
Another key decision was whether to launch with multiple social networks supported, particularly Facebook. I decided to support just Twitter, as that was the primary problem I wanted to solve for myself. It turns out that Twitter and Facebook are very different networks, and it was wise to start with only Twitter since we wanted to make a product which was great at just a few things, rather than "just ok" at many.
This is also a frequent topic that comes up when I meet to help early stage founders. The advice I always give is to try and cut as much as possible out of the first version of the product. That way, when you launch, you'll hopefully have fairly binary feedback: either people love that one feature, or they don't find it useful. It's easier to figure out what to build out from a single feature people love, than to launch with a bunch of things and figure out what is working and what isn't.
What was your biggest roadblock and how did you overcome it?
When I first started Buffer, I was working full-time as a freelance web developer. It was incredibly difficult to find enough time to fit in Buffer on the side. I worked evenings and weekends at first. One of the key ways I tried to make it work was by launching a super minimal product, and this helped a lot with this challenge.
Eventually, I had a big breakthrough which I attribute a lot of my early success to. I realised that I was often trying to work on Buffer in my evenings, after a whole day of work for other people. I wasn't fresh at all, I was often very tired and unproductive. So I reversed things — I started waking up much earlier (around 6am) and worked for 90 minutes before I started my freelance work, while I was completely fresh.
If you're trying to build your own startup and truly want to succeed, you want to ask yourself what your priorities are. For me, building my own product and company and reaching a point where I could work solely on my own product was my highest goal. That trumped everything else, so I decided to work on Buffer as my first activity of the day.
What was launch like for you?
I look back at the launch of Buffer as a massive success — it was a milestone achievement for me. The numbers were not huge though, and it really took us a very long time to ramp up and start to see great traction. We had about 100 sign-ups in the first month and the first three paying customers. The first ever paying customer was after three days of launch — they paid $US5 into my PayPal account and I was jumping around the room. It was a tiny amount compared to what I could make from freelancing, but it was the first time I had made money online with a product I had created. I was no longer trading my time for money. $US5 into PayPal for a product that I could scale was a huge difference from thousands for freelance work which I couldn't scale in the same way.
But 100 signups and three paying customers couldn't really be seen as a successful launch. It actually took us six whole months before I could drop my freelance work. We just kept pushing forward and my co-founder Leo worked hard to figure out how to gain traction through content marketing. One of our best shifts in mindset was when we started to take the approach of "many launches" rather than a single "big bang launch." We would aim to get some kind of press ever 3-4 weeks, with a new feature we launched or a milestone we hit. This gave us compounding growth.
How do you handle user requests and criticisms effectively?
Since the beginning, I have always had a large focus on talking to users and helping them with speedy and helpful support. This now forms a key part of our vision and in fact 25% of our team is dedicated to customer support, with the rest of the team regularly spending time on it also. We have a monthly Happiness Report where we share all the insights into how we run customer support at Buffer and the real numbers around the volume we get. For example, in August 2013 we had 4335 email conversations, answered 52 per cent of emails within one hour, and 98 per cent were happy with their experience.
We have over one million users, and we've made a commitment to providing fantastic support for every single one of them. We do this through partly through hard work and hiring amazing people, and also with a number of tools. We use Help Scout for email support and Sparkcentral for support via Twitter. I am sure our Chief Happiness Officer, Carolyn, would agree with me in saying that we would be drowning in support without these incredible tools. They both allow us to have a shared inbox so the whole team can work on the inbox together, and they also help us remain super personal. For example, Help Scout adds zero ticket number information — for the person receiving an email it is just a plain text email with one of us. They love that.
On the product side, customer support is an amazing reservoir of insights into what needs to change about the product. That's why we love support and always ask people to get in touch with us. I regularly sync up with Carolyn to hear the most common problems or feature requests, and then we prioritise our roadmap directly based on these insights. This has helped us to evolve our product and release features which we know in advance people will love.
A key value at Buffer is empathy and humility and this helps us when we receive criticism. It can be easy to receive an email and forget the human interaction of it — to forget that it's a real person on the other end who spent the time to type all those words out one by one. My personal approach with these types of emails is to thank them profusely. If they are unhappy about something and take the time to get in touch, that shows they really care. And not many people are willing to tell us where we're messing up, so it is incredibly useful information to receive. The cool part is that by truly seeing it from their point of view and empathising with them, the most vocal critics can become your biggest evangelists.
Now, how do you split time between developing new features and managing existing ones?
That's a great question. We've actually been thinking a lot about this recently. Too many new features and the product will deteriorate over time. Too much work on existing features and growth is likely to slow. We try to strike a balance. Here's a picture from a recent brainstorm I had with my co-founder:
So, we generally aim for an almost 50/50 split between new features and fixing and improving existing features. We also have a culture where all engineers do regular customer support. This helps the engineers to see what real people are doing with the features they're building, and often this can mean it's easier to empathise with any bugs or confusions, and they get fixed a lot quicker. We then have 10 per cent of time on refactoring, which means "tending to the garden" and making our code base a joy to work with over time.
What advice would you give to others that want to take on a similar project?
If you're a first time founder, I recommend trying to really identify a pain point, which is something I've written about in detail here. A key is that you assume you might not have found one yet, (so validate rigorously — talk to people and check that users are coming back).
The other thing is to think about how you can transition to working full-time on your startup. For me, the best way was to generate revenue early, by charging for the product. As a first time founder in the UK, there's almost no way I could have gotten funding in order to work full-time on Buffer. By the time we raised our $US450,000 seed round, we already had 55,000 users and were making about $US13,000 per month. We would have really struggled to raise funding without that traction, and so I advise others to just get started and try and build something that people will pay for.
Lifehacker's new Behind the App series gives an inside look at how some of our favourite apps came to be — from idea to launch (and beyond).