6 Lessons from Joel Gascoigne
Last Thursday I spent the morning at the Leaning to Start Up event in Manchester. Joel Gascoigne, the founder of Buffer gave a talk covering some of the lessons that he's learnt from building startups.
I've been a Buffer user for quite a while now, and first came across the app when Sal Virani suggested I read one of the Buffer blog posts that explains how he tested the demand for Buffer. If you're thinking of starting your own business online, that post is well worth a read.
Thursday's talk included similar advice, along with plenty of new tips. Joel structured it around six key lessons.
Lesson 1: Be open, vocal, and share your progress
Joel's first start up was a site called 1 Page, which allowed you to create an online version of your business card. While 1 Page wasn't ultimately successful, the 18 months that Joel spent working on it weren't wasted. He blogged and tweeted prolifically about what he was doing and built up a substantial twitter following (1,700 followers).
Those twitter followers were very useful when he moved on from 1 Page and started testing ideas for Buffer. The statement that resonated for me was this (I'm paraphrasing):
Working on startups is a career path, and it pays to build your personal brand while you're working on your idea. Every app that you start builds on your brand. Even if your current startup isn't successful your personal brand and followers stay with you.
Lesson 2: Work on the side
You'll often hear people advising you to focus 100% on your startup idea, rather than working full or part time to pay the bills while building a business in your spare time. Joel started working on Buffer at home in the evenings, while working as a freelancer for two clients.
Once he'd demonstrated that there was demand for Buffer he built a very simple first version of the app. He offered a paid plan from the very beginning (with a simple Paypal button). As more people signed up to the paid plans he was able to slowly reduce his freelancing commitments to focus on Buffer.
Seeing people pay for it also provided plenty of motivation to keep going.
I've experimented with working on startups on the side and found that it didn't work too well for me. I suspect that my difficulty was due (in part) to me having validated my original idea less rigorously than Joel did. I've spent a lot of time experimenting with different ways to divide my time between client work and my startup, but that's a story for another post.
Lesson 3: Test assumptions
When working on a project for an employer you have (by definition) a validated spec to work to. When you're working on your own startup there's nobody to tell you what to do next. You just have a hypothesis, and its important to validate it yourself.
Joel read Eric Ries' blog while he was working on 1 Page. He decided to give Lean a try, but wanted to try it from scratch on a new idea. Lean can be difficult to apply rigorously; Joel jumped straight into coding Buffer before realising he was doing it wrong. He stopped and put a lot of thought into how to validate the idea.
Buffer's first minimum viable product (MVP) was just a landing page. The page implied that Buffer already existed, explained what Buffer did, and had a "Plans and Pricing" button to click if you wanted to buy it. Instead of a pricing page, people were shown a newsletter sign up page with a brief message explaining that Buffer wasn't quite ready.
Joel feels that you're missing out on a lot of validation if you've only got a newsletter sign up page, rather than a button for signing up or purchasing the product. If people haven't tried to buy your app, how do you know that the people on your mailing list are interested in paying for it?
Whenever anybody signed up to Joel's mailing list he emailed them personally, explaining more about Buffer and asking for feedback. He stressed the importance of their feedback in the email.
Having demonstrated that there was interest in Buffer, the next step was to find out if people would pay for it. A pricing plan page was inserted between the button and the newsletter sign up form, showing three pricing plans. A few people clicked on the paid plans, and Joel emailed them to find out how much they felt it was worth.
With the first MVP out of the way, Joel built version one in his spare time over the next six weeks. It was a very simple implementation, only supporting one twitter account per customer. The paid plans simply allowed you to add more tweets to your queue.
By the time the first version launched Joel had collected 120 email addresses on his list. Fifty people signed up on launch day (though not all were from the mailing list). They had their first paying customer within 3 days.
Lesson 4: Be curious, embrace serendipity
Joel skipped over lesson 4 while he was giving his presentation (I suspect he was short on time) and suggested we email him to find out what it was about if we were interested. So I did.
Once Buffer was making just enough money to support Joel and Leo (his co-founder), they became curious about all the buzz around the San Francisco startup scene. On a whim they jumped on a plane to California where they met lots of people working on startups. One thing lead to another and they ended up getting Hiten Shah and Guy Kawasaki onboard as advisors.
Embrace serendipity. Good point, well made.
Lesson 5: Focus on solving problems, not raising funding
If you're a first time founder looking for funding, the best thing you can have going for you (from an investor's point of view) is a product that has traction in the marketplace. Traction validates the idea.
If all you have is an idea (without a working demo) then you could also raise cash on the basis of the idea alone. You're less likely to succeed if you've got a working product that hasn't gained traction (investors will wonder "why not?").
Joel's advice to first-time founders looking for funding is therefore to build an early version of the product that solves a real problem. Solutions to real problems tend to gain traction.
Joel and Leo initially had no plans to raise funding for Buffer. It was only while talking to people in San Francisco that they realised that funding made sense for them. Joel had been handling all the design, development and system administration, and he didn't have any capacity to take on more work. An injection of cash (from a $400,000 seed round) allowed them to bring another developer on board to scale the business. There are now 6 people working at Buffer. They're turning over $35k per month, and are growing at 30% per month!
Lesson 6: Enjoy yourself
This one is pretty self explanatory, but by no means less important than the others. From my own experiences so far, it's vital!
It was an excellent talk, and inspired me to post more about what I'm learning while I'm building Agile Planner. The data that Joel shared from Buffer's early days (such as how many people were on the list at launch, and how long it took to get the first paid subscriber) was especially motivating. Have you got any similar figures you could share?
Useful links
- Buffer's article on how they stayed Lean: Idea to paying customers in 7 weeks: how we did it
- Eric Ries's blog: Lessons Learned
- The Lean Startup book
I love feedback and questions; please get in touch on Twitter or ask a question in the comments.
