Joel Gascoigne on launching minimally and managing a distributed, transparent team at Hustle Con
In this 2015 Hustle Con talk, Buffer co‑founder and CEO Joel Gascoigne shares the story of how he built Buffer using lean‑startup principles, extreme minimalism, and a culture of radical transparency. He recounts early mistakes of coding without validation, the creation of a three‑page landing‑page funnel to test demand, and the ultra‑minimal first product that only supported a single Twitter account with no analytics. He describes manual processes for early payments, the importance of direct customer conversations, and how those practices informed later product decisions. Joel also discusses a failed UI experiment with a picture‑sharing browser extension, the development of Buffer for Business through iterative pricing tests and simple forms, and the benefits and challenges of a fully distributed, globally‑spread team. The talk concludes with a brief Q&A on distributed teams and validation failures, highlighting the need for consistent customer development and clear communication in remote organizations.
Questions this video answers
Pros: rapid response to incidents (e.g., a hack) because team members are on different time zones; no need for all‑hands overnight work. Cons: if you mix office‑based and remote staff you create a “second‑class citizen” dynamic where communication happens in the office that remote members miss. Joel recommends either fully office or fully distributed and uses HipChat as a virtual office for the remote team.
Yes. The picture‑sharing feature added to the browser extension was validated with a small user test and 6 out of 7 users were confused by the UI. The team’s internal bias made them think it worked, but the test revealed a failure, leading them to abandon the rollout until they could redesign the UI.
Chapters
So our next speaker is Joel Gascon. He's the CEO and founder of Buffer, which is— I'm sure you guys have all seen this. If you have Twitter or Facebook, it's where you see the BFF.ly on your feed. But right now they have 26 employees. They do about $3.5 million in revenue. And Joel's talk is going to cover how he was able to start Buffer in the most ghetto way possible. So please welcome Joel.
Hi, everyone. It's great to be here. Excited to chat with you all. So yeah, as Sam mentioned, my name's Joel Gascoyne. I'm the co-founder and CEO of a company called Buffer. And today I want to chat with you about some of the tactics and lessons that we've learned in the last few years that have helped us to grow Buffer. And so hopefully this will be useful for you if you're thinking about doing a startup or if you're working at a startup right now. As a little bit about me, I'm originally from the UK and started Buffer in the UK about 4 years ago almost now, so the end of 2010. And yeah, I'm probably an unusual choice of speaker for this conference because I've actually been coding since I was about 12 years old. So, but at the same time, I'm really excited to speak with you because of that. Because I found that often coding was kind of like a crutch for me. And it was kind of the first thing I would reach for whenever I had ideas. And over time I discovered that that's been kind of a really big mistake that I made. And it's something that I've had to adjust. So I've got a few different stories I want to share with you of times where we've kind of jumped too quickly to coding. And it's kind of not worked out. And then I've got a few other stories where we've had a lot of success without coding at all. Uh, our vision for the product is to be the simplest and most powerful social media tool. Um, the problem we help to solve is with, uh, posting to, uh, Facebook and Twitter and scheduling posts. So, um, the idea is we give you a queue, and you can add content to that queue, and then, uh, we'll then space that content out for you over the course of the day, so you could read the news in the morning, and, um, we'll then, uh, share that for you throughout the whole day. Uh, before I dive in, I also wanted to just mention 3 kind of interesting things about the company, um, that make us a little bit different than other startups. Uh, the first one is that we're a fully distributed team. Um, we're 26 people right now, uh, spread all across the world. Uh, we're in 20 cities, uh, in 5 different continents. Uh, the second one is that we've raised a $450K seed round of funding, um, but we've— hit profitability based on that. And so we've not raised any more funding after that, and right now we don't have any plans to raise more funding. The third one is that we have a core value of transparency within the company, and so we try and do things in a very open way. And this is exciting because I think by sharing our failures and successes, we can really help a lot of people and do things like this. So one of the most controversial things that we've been transparent about that you might have come across is we are completely transparent about salaries and equity within the company. So we have a formula to determine the salary of everyone in the company, and we make that formula public. But not only that, but we have a list of everyone in the company and their salary, and that's public too. So this is all available just at a Google spreadsheet. And if you want to check it out, you can go to buff.ly/openpay. Cool. So before Buffer, I worked on a previous startup for about a year and a half. Ultimately it was a failure, but I learned a lot of lessons along the way that contributed to how I thought about starting off Buffer. I think the two big mistakes that I wanted to mention, the first one is that I just I just built whatever came to my mind and without validating it. And the second one was that I didn't make enough effort to talk with people about what I was building. And I think overall the big mistake was that I just enjoyed the coding too much and didn't— and I kind of forgot about building a business. During that time, I discovered the Lean Startup concepts under Eric Ries. I think that really changed my mindset in a lot of ways, changed how I thought about approaching ideas. And in a way, that kind of changed my life because it then changed a lot of things about how I built things. So kind of based on the Lean Startup techniques that I came across, I decided with Buffer I wanted to take a different path. And so the funny thing is that as soon as I had the idea for Buffer, the first thing I did was just to think about coding, just jump in. And then I kind of had to just stop myself and say, you know, what should I— how should I approach this in a lean way? And how can I validate this without going ahead and building the whole product? And so I think that's probably one of the big lessons that I've learned after a few different failures is that I think if I look back now, it's clear that I was building things as a hobby, really. And I think that's what happens when you just go and build whatever comes to your mind. And that can be fun, but I think, you know, if you really want to build a business, you need to validate your ideas. Either that or you've just got to get really lucky. So thinking about how to approach things in a lean way, I thought, how can I validate the idea of Buffer before I even built a product? And so this is what I came up with. It's a simple 3-page website, and at the time I built this myself, but there's lots of tools out there right now that are much better equipped to build something like this than diving into code. So something like Unbounce would be absolutely perfect for building this. And yeah, so kind of just to walk through this, the most important thing to notice about this 3-page website is that The first page made it look like the product already existed. And I think that was really important. If you wanted to get a ton of signups, it might not be the best thing to do. But if you want to truly validate whether people want your idea, I think it's kind of crucial. So the first page was just like a landing page. It had a headline and then 3 steps, and then it had a plans and pricing button. And then they would click the price— the plans and pricing button and go to the next page, which was just a pricing page. And then from there, they would choose one of the plans, and then they would end up on the final page. And the final page just says, "Hello, you've called us too soon. We're not quite ready yet." And then it would give them a chance to put their email in a box and give me their email and be notified when the product actually existed. So I drove a bit of traffic to this 3-page website, and luckily some people went all the way through and gave me their email at the end, so that was pretty great. And as you already know, I was kind of obsessed with The Lean Startup, so I was pretty excited about looking at the analytics and checking the funnel and looking at all the numbers and things. And that was another big lesson that I learned, is that in the early days, the numbers are just not that useful. Don't have the volume, really. But instead, what was useful and what I did was that every person that gave me their email, I personally emailed them and got in touch, and then I had a conversation with them. So I had a lot of conversations over email and had a few Skype calls as well. And what I found was that once people understood the concept, quite a few of them said that they would want to use this product. And a few even said that they would pay for it if it existed. At the same time, quite a few people told me that I was crazy and that no one would ever use this and no one would pay for it. But I was pretty happy that I actually had some validation from a few people that said that they would want to use it. So that gave me kind of enough confidence to go ahead and think about building the first kind of minimal version of the actual product. Cool. So I'd kind of decided to build the first version of the product, and that was when I reflected on the Lean Startup concepts again. And something that Eric Ries said really kind of stood out in my mind. One of his conferences, one of his presentations, someone asked this in the Q&A session. They said, how minimal should your minimum viable product be, your first version of your product? And Eric Ries said that there's probably not, there's not like a perfect answer, but the answer is almost always that it should probably be much more minimal than you think. So I really tried to keep this in mind when I approached building the first version of Buffer. So the first thing that I approached in kind of a minimal way was the actual feature set itself. So the first version of Buffer, you could only use it for Twitter. So there was no other networks you could use it for. Not only that, but you could only use it for one Twitter account. And there was no analytics either. So really it was purely just this idea of the queue for one Twitter account and that was it. And I think that's kind of an important point is that when you're doing your first version, I think it's useful to be kind of laser-focused with what you put out there. And so I think it helps you then when you put it out there that it's gonna be a very clear signal one way or the other. Either it works or it doesn't. Whereas if you have a bunch of features, it's gonna be much more cloudy and you're not gonna know what to focus on, what to improve. A couple of other things that we left out in this first version. The first was the actual upgrade process of going from the free version to the paid version. And so normally when you pay for a product, right, you expect that you would, you put your card details in and you, then you kind of get an email probably and you get access to these paid features right away, right? What happened with the first couple of months of Buffer was that you would pay with PayPal and then I would get an email into my personal inbox that said someone had paid with PayPal. And then I would rush to the database and upgrade them manually and then email them the welcome email personally, and I would apologize for the delay of our systems. And this kind of worked out really well because, I mean, maybe it wasn't an ideal experience for the user, but what happened then was that I had a lot of conversations with users, and then it actually became an even better experience for them. Another example was that on the paid version, there was a paid feature of using your own custom Bitly details. And that was another thing where the way I thought about it was it's on the paid version, but it doesn't really have validation yet. And it didn't make sense for me to build that out before I had any paying customers. Why would I work on a paid feature when I could instead work on trying to get that first paying customer? In the first place. So there was this feature to have your own custom Bitly details, which would let you then see the click analytics in your Bitly dashboard. But, so this didn't exist, and then, so the first couple of people that upgraded, it actually wasn't a problem because they purely upgraded to get more space in their buffer. But the third person that upgraded sent me an email and said, "Doesn't seem like this is working." So I said, "Okay, I'll just— I'll look into it." And then I thought that's probably a good time for me to actually build this feature. And so, yeah, and then it took me about a couple of hours, and then I replied back and said, "Maybe you can try it now, and I think it's fixed now." And so then he was really happy with it, Again, I got to have a conversation and learn more about what other things he would want as well. So the end result of the kind of landing page experiment and the minimal first version was pretty great. It was a 7-week process in total from having the idea to launching the first version. And we had the first paying customer after 4 days. So it worked out well. It was just a $5 payment. It took a while. I was still working full-time. Doing web development on the side, so it took a while to be able to drop that and focus full-time. But it was a whole new experience for me. Yeah, so we kind of started off well, but what happened then over the next, like, year or two is that we struggled to approach everything with that same kind of discipline. And a few weeks ago, we're lucky to have Heaton Shah as an advisor. He's gonna be speaking a little bit later. And he said to us that he sees a strange thing with startups. They'll do customer development once, but then they'll fail to make it part of the product process. And this is something that we've found to be really true. That's something we struggle with a lot. So I've got a couple more examples I want to share with you of one where we've failed and then another one where we've kind of succeeded. Cool. So here's the first one. This is our browser extension popup. So we have browser extensions for Chrome, Firefox, and Safari. And almost 40% of all the sharing that happens comes from browser extensions. So it's been a huge part of our, of our success. And back in 2012, we started to notice an interesting thing going on with Facebook at the time, which was that pictures were becoming a lot more prevalent. On social media. And today they're a really big part of Twitter as well, so they've kind of become a big deal. Back then we noticed it, and so we tried it out in our own accounts, and we saw a lot of engagement. So we were excited to try and help our users with this as well and get a lot of engagement by using pictures. We also were quite inspired by things like Pinterest, where they'll show you all the pictures on the page and let you pin pictures, so we thought we could do something like that. So we kind of decided that we wanted to enhance the browser extension and bring in this picture sharing kind of ability into it. So we got to work, and a couple of months later, we came up with this. So you can see there's, like, 4 tabs on the left-hand side. So we would let you choose between sharing a link, a picture, a video, or just a status update. And that's how it looks if you're sharing a picture. And so we were pretty excited with this. We started using it ourselves and it was working really well for us. We got a lot more engagement by using pictures. And then we kind of— we were so excited that we nearly rolled it out to the whole user base. And then I think one of us in the team just said, well, maybe we should let a few users try this first and see what they think. So we decided to do some user testing. My co-founder Leo just jumped on He actually jumped on 7 Skype calls with customers, and we just enabled it for them and asked them to talk us through how it felt and what they were— what they thought things meant and stuff like that. The results were pretty shocking. We discovered that 6 out of 7 people were completely confused with the UI. And so we discovered that people thought that the picture here was like the link attachment that would come up in Facebook. For when you're showing a link, and people just didn't get it at all. And we discovered that our team was completely biased. Like, we knew exactly how it worked because we knew the problem we were solving from the first place. So we knew exactly what the UI meant and stuff. So that was kind of a big shame, and especially because we could have known this exact same learning just by doing user testing with mockups 2 months earlier. Uh, the final story I want to share with you guys, uh, this afternoon is how Buffer for Business came about. So Buffer for Business is our, uh, paid plans beyond the most popular $10 a month plan for Buffer. So we have $50 a month, $100 a month, and $250 a month. And then we have a few enterprise customers beyond that. And, uh, it's only been available for just over 6 months, uh, but it's already become a pretty big success, and it's— 27% of our monthly revenue now. So, yeah, so the first thing for us to kind of decide with Buffer Business was what would the product even be? So we had a couple of different ideas in mind when we thought about Buffer for Business. We had either just purely extending what already existed so people could have more accounts more team members and share more content. Uh, the other one was, uh, something we were really excited about, was a brand-new product. And the idea was to help, uh, companies to make use of all employees if they connect their personal Twitter and Facebook accounts and have them share the news from the company, the press releases, or, uh, job listings and things like that. So we thought this would be really great for marketing departments for companies. So what we did was we spoke with quite a few different customers. So my co-founder Leo, he did a lot of customer development. And what we found was the thing that we were really excited about just ended up not resonating at all with people when we spoke with them. So I think the best thing we— the most useful thing we heard was a head of marketing said, I can't rely on my I can't rely on the team to do marketing. Like, that's what we have to do. And so this will be a nice to have, but we wouldn't pay for this alone. Whereas the extending buffer and having more functionality, that was something that, like, really resonated and people were super excited about. So— and we had a lot of people that were hitting the limits of the $10 a month account, and so there was a lot of kind of pent-up demand there. So we knew which one we needed to, we needed to build. And so I just want to walk you through then the process we went through kind of after that. So we tried to think about how can we validate this further and kind of build this out in a really lean way. And what we realized is that if we just go in Stripe, we can add more plans in there. So we added just a bunch of plans for different price points. And we, uh, then Leo would just talk with customers who were hitting those limits and ask them if they wanted to get onto Buffer for Business, uh, which all it was really was releasing those limits. And quite a few people wanted that. So then he would just move them onto the plan in Stripe and, uh, then we would start charging them more. So this was great and in a very short space of time we had our first $10,000 in revenue. And that was 6% of our revenue at the time, so it was pretty huge right away. We then thought, how can we get more leads? So what we decided to do was to set up a Wufoo form, just asking for their email and phone number if they want to get more information about Buffer for Business. And so we advertised this in Twitter and on the blog, and that helped us grow the revenue even more. Then we realized that we could drive more leads if we put just a little bit of— doing a tiny bit of code and put something on the pricing page at the bottom. So just letting people go to that Wufoo form. The next thing we did was to— we thought it might be good to better qualify the leads. That helped Leo a lot, so we added a bunch more fields to the Wufoo form. Yeah, then finally, by that time it was kind of a month or two after we'd started and we'd learned a lot and the pricing points became kind of clear. So we decided to do a pricing page. But we still didn't do it ourselves and write any code or anything. We just decided to use Woofoo. So we had this Woofoo page with the pricing plans and we couldn't connect it to our database so we had to, like, ask for their email again and stuff. But it worked really well and it helped us to be able to test different prices and things like that. So this was great. And yeah, so today Buffer for Business is one of the best things we've done in the last year. And it's 27% of our revenue now and it's almost 100K a month in revenue that we're getting from Buffer Business. So that's, yeah, that's all the stories I want to share with you guys. One quick thing to refer back to the middle of the talk on how we're trying to make this a process now. So we're— we have— Heaton mentioned to us these 4 steps, and in the last few weeks we've been really trying to rigorously follow these steps. And especially kind of making these steps required for everything that we do is what's helping a lot. Especially the hypothesis part is where we actually need to talk with people. So cool. That's everything. Thanks so much for listening. And I'd love to answer any questions you have. I think we can take 2 questions.
Hey there.
How are you? Hey. Good, thanks.
I'm Michael from Lots of Stops. Great talk. If you wouldn't mind, so you have your team as is all over the world, right?
Yeah.
So that's what I'm looking to do as I build my company, and I'm curious if you might want to briefly talk about the pros and cons of having a team that's dispersed worldwide.
Yeah, absolutely. That's a really awesome question. Um, so I think there's some huge benefits that we've found. Um, we were hacked last year, and it was pretty crazy. It was a tough situation. But the fact that the team was fully distributed all across the world meant that we didn't have to do a crazy 2 or 3 days staying up all night just to resolve that. And we could have the different people in the world jumping in at different points. So it's been really, really great. I think the one key thing I would say with a distributed team is I got some advice from a guy called David Cancel. He's done quite a few startups and he's the chief product officer for HubSpot right now. And he said to me, he's had a few startups and he's tried both ways. He said, "What you want to do is have either everyone in an office or have everyone distributed. And if you go halfway, it's going to be really tough because then you end up with second-class citizens and communication happening in the office that other people don't know about." So that's how we do things. We have an office in San Francisco, but we just have 4 or 5 people in there, and we still use HipChat a lot, and we kind of say that HipChat is our office. So, yeah, that's probably what I'd say. But yeah, we can catch up afterwards if you have any more questions as well. Thank you.
Hey, I think it's really cool you're into The Lean Startup. I work for the publisher that actually publishes the Lean series. Nice to meet you. And we want to use Buffer for business right now, so we're very excited about that.
Awesome.
I'm interested in validation. Did you ever try to validate something and failed? Was there ever an idea that didn't validate that you can considered and didn't go through with?
Yeah, I mean, so the browser extension was a key one that failed. Another one was— I think that's probably the best example. There is one that we didn't validate, and it went through. And then we found out a few months later. So we did a whole redesign of the Buffer dashboard, and we didn't validate it at all. and then we didn't look at any numbers or anything. We didn't A/B test it, nothing. So then 2 months or 3 months after we'd launched it, we started to get really focused on data and look at numbers and things. We managed to trace back that we had a huge drop in activation of new users. So the new dashboard was converting new users to active users much worse than before. And that's something that we've actually been kind of catching up with ever since. So— Very cool. Thanks. Sure. Thanks, Joel. Cool. Awesome.
