Can you introduce yourself?
Sure, my name is Jeff Lawson. I'm co-founder and CEO of Twilio.
Nice and short.
Right, do you want more? Never ask an entrepreneur to talk about himself.
Just give me a sentence or a minute about things that you’ve done.
I'm a serial entrepreneur. This is my fourth company. Immediately prior to this, I was a product manager of Amazon web services, and when I left Amazon I was looking for the next thing I wanted to do and thought about a bunch of ideas. One of the things that struck me was each of my three previous companies we'd wanted to incorporate communications into the web apps we were building, and we didn't know how, three times in a row, and so we started Twilio to solve that problem.
That's what I really want to talk about today and how you built an application that is used by a lot of developers, and how you built that community because that's so important, right? Once you get the guys on board then it sort of multiplies and spreads and they then evangelize your product. Take me back from the early days, so you started building this product. How did you get the developers on board?
Initially we realized that ourselves, as developers, we had want to incorporate communications into our apps that we were building, and myself, three companies in a row had this need. Each time we said that's really interesting. We'd love to build these apps that communicate, but you know what? We don't know the first thing about telecom, like making a phone ring. That's magic. We don't know how to do that because we're web developers, right? We're not telecom engineers. When I realize I have this experience three times in a row I said that's really interesting.
It makes sense, right? You've got web applications that we use all day, every day. You've got your phone with you all day, every day. It just makes sense that these two things would collide frequently in the realm of what developers were building, and so we started talking to other developers, and we said, “Hey! If you had a tool that let you buy phone numbers, make and receive calls, send and receive text messages, and we described how it would work, would you have use cases for it? We got this pretty clear picture from developers that “yeah, I definitely would have used that at my last company or my last contract or my last customer. We would have used that.”
We got this picture of my experience with the use cases were coming up pretty frequently and they were routinely dismissed as “that'd be really neat”, but it's just not what I do. As a web developer, that's not something that I know how to do. You could ask me to go build you a suspension bridge too, but I'd say that's neat but I don't know how to do that.
We started Twilio to solve that problem. What really informed the way that we went to market, and doing so via developers was the fact that we saw communications as an extremely horizontal problem space right?
There were these primitives of the phone number, of the phone call, of the text message, and then inside the phone call primitives like, saying text, playing back audio, gathering digits from the phone's keypad, recording audio, and dialing and bridging other phone calls together.
These were the primitives, and we really boiled all of it down just five things, pieces of business logic that you put together in a phone call to build just about anything. We said between these primitives, developers can build arbitrarily complex and arbitrarily domain-specific solutions to the problems that they're seeing. There are things that they need solved in their use cases.
We said because it's so broad and because we cannot even predict all the things that people need to build, the right way to do it is to give the tool, these building blocks, to developers and make those building blocks as simple as possible so you don't have to become an expert but make them flexible enough that you can build just about anything, a solution to almost any kind of problem.
That's where we got this very platform-like approach, which is simple APIs for developers, pay as you go pricing, self-service so developers could just come and sign up and get started in minutes and build applications.
Part of it was because we see it as just such an enormous number of things that you can build, and from what we talked to developers we heard such an enormous number of problems that they could solve and different domains of things they could do that we wanted to make sure that developers weren't constrained that they had the tool they needed. Literally, with Twilio we've seen this. They can put telecom in their tool belt and when those problems arise as from what we've found, they always do great! I know how to solve that! I'm going to pull Twilio out of my tool belt and be able to solve those problems for my customers or for my company or for my client.
How did you promote the service to developers?
Once we decided, developers were the obvious. That's something I think you have to be pretty crystal clear about. It was for us. We’re very clear that developers are who we are talking to. The first step is build a product that's right for developers. You can build a developer product, but you won't tell people how much it costs. That doesn't work very well because developers if they can invest their time in something they want to know what it's going to cost. If you put the documentation behind NDAs or behind, “Oh you have to pay us first”, it doesn't work.
Be very up front.
Very up front, right. We like to say developers are doers, people who get stuff done. For a doer, someone who wants to make an informed decision with all the information, we need to give them the documentation, the pricing, and the ability to sign up and get started playing with it, get hands on very quickly. We like to say that the documentation of the API is our marketing.
That's the developer-centric solution. Empower them. Give them information and let them make a decision, an informed decision about whether or not Twilio is going to solve their problem. If they suspect it is, great. Get out of their way. Let them actually try it for themselves. Let them prove that it solves their problem. That's sort of the approach of how you build a product for developers.
Then the next step is how do you let developers know about it, right? You've got a product that appeals to them, great, but how do you let them know about it? Our strategy has been to get out in front of developers where they are, online and offline, and take a very developer evangelist type of approach, right? We get out to hack-a-thons, to meet-ups, to startup weekends, to all sorts of events where developers go.
We also participate online in communities like Hacker News and Hackspace and those communities as well, and essentially because we are developers, we're essentially talking to ourselves. We use the same way that we talk about our services and places where we go to talk about it that we ourselves would go to learn about new technologies and to essentially hang out with other developers, and where developers learn new things, that's where we want to be. It's sort of interesting because you go to somewhere like Startup Weekend. I don't know if you're familiar with Startup Weekend?
We're a worldwide sponsor of Startup Weekend, and what's interesting is why go to Startup Weekend? Is it that we really think the next billion dollar idea is going to be launched at a Startup Weekend? Well maybe. Actually Zourlie came out of a startup weekend, which is pretty neat. They built all that stuff on top of Twilio, but necessarily is that why, no. I’ll go back to that we're doers. The people who get hands on and see problems and solve them and doers exist everywhere -- in startups and in big companies and in everything between.
Those kinds of people are the ones who go to Startup Weekend because they just want to do stuff. They want to be intellectually engaged, they want to learn new things, they want to meet new people, and they want to build. Our participation in Startup Weekend was all about reaching those people.
The kinds of people who like to learn new things and solve problems and do cool things with new technologies, they go to Startup Weekend. Maybe it's not the next billion dollar idea that they build that weekend, but Monday they go back to work at their company, and now they bring Twilio with them.
That's the idea. It's just getting in front of the developers, and in particular empowering them to say, “Hey, here's what you can do with it. Here's one example of what you can do with it, but I can't wait to see what you're going to build.”
What do you think has more leverage, online outreach or offline? Let's say if you had to just focus on one, I know you did offline and online, but just give an idea of where someone should focus their energies. Have you seen more results by attending events, sponsoring events, or contacting people on Hacker's News?
Well, you know what it is. In marketing, you don't remember a message until you've seen it eight times or whatever, eight times a minute, but it's all about repetition.
For us it's not about just one thing. You can't just have a blog, you can't just be on Twitter, you can't just be on Hacker News, you can't just show up at one event. It's doing all those things well, and just being a part of your community wherever the community is. If you said my go-to-market strategy is hanging out at Hacker News, I would say that's probably not going to work out well for you. If you said my go-to-market strategy is only Startup Weekend, I would say that's probably not going to work out for you.
Really for us it’s been about essentially being everywhere, and Danielle who was our first evangelist and our first hire at the company, her motto that she I think took from Jason Calacanis is ‘be everywhere, be awesome,’ right? That's what Jason looked at and that's what Danielle looked at. Part of the game is just showing up, being there, and it takes a lot of energy, and it takes wanting to meet people and meet people doing great things.
Then when you're there, be awesome. It's a little hard to quantify, but you just be on, and be interested in people, and be interested in their capabilities and what they can do and have a fundamental belief that people and developers, in particular, can build great things, and that we're there to help them do that.
When did you start seeing results? For somebody listening now, say you've got a timeline, three months, six months. Is it possible to estimate intervals of when people will start responding to your marketing message?
It's really hard to say because not only do you get out and show developers what your tool can do, it's got to be helpful for them, right? If you go out there and you show a product that doesn't solve the problem they have, you're not going to see results. It's a combination of solving a problem they have and making it apparent to them how it can solve their problem. To me, that's the magic
How did you make it apparent for them?
Some of our most successful demos we've got and I will say that telecom has an unfair advantage over almost anything else out there because there's some magic to it. You can write a few lines of Ruby or Python or Java or PHP and now suddenly phones are ringing. That's really powerful because it jumps out of the computer. It jumps out, say, a website and actually touches people in the audience who you're talking to, touches their phones. It's pretty magical.
It's a great way to demo the product because it actually leaps out of the screen and into the real world. We have a little bit of an unfair advantage that way. People say never follow the Twilio demo, which is probably good advice.
Something we do a lot of is we go up on stage, and instead of going through a slide deck or anything, this is maybe at a meet-up or something like that -- we'll go up there and we'll just open a text editor, and live in front of the audience build an application that does something.
Build an application that's a conference call, for example, and then live, go buy a phone number in real time, and whatever the phone number to the conference app that we just wrote and in less than two or three minutes build a conference service from scratch and then invite the entire audience to call into it.
It's sort of one of those things where it's obviously very cool to do that. It's fun, but it also immediately shows the value prop. Look, this didn't take years, months, weeks, days or even hours, right? Building these kinds of applications, I can do it, obviously, me and one of our evangelists.
We know it really well, but if I can do it in two minutes, imagine what you can do. Imagine all the things you can do in a very short period of time, if the tools are really this easy and the level of understanding that you need is really simplified down to what your users and your customers will care about and not all the underlying technical complexities but really just getting stuff done that you or your customers or your product team or whoever it is are going to care about the end result.
Getting straight to that end result is what we can demo for you in two minutes at an event. That's what I think gets the point of what are we going to do for you. It's about putting this new magic in your tool belt and making it blatantly apparent that it is simple and easy to do.
Almost showing but not telling.
Exactly, showing and not telling. I've seen some of the guys who write mobile apps and compile them for multiple platforms in real time, like that’d be neat demos where they'll write an app or they'll take a web app and then in real time compile it for an IOS or Android or anything like that. I've seen good demos that the whole point is show it. Don't tell it, absolutely. That goes when you're reaching customers or if you're talking to investors or really anybody. The power of the demo is much better than anything you can say.
How has it been to provide a service for other developers?
It's great. Developers are really smart, very technical audience. There's no BS. You cannot bullshit developers because they're too smart. It seems obvious, but a lot of people out there might treat the developer audience like you treat any other audience. You put nice clip art and people shaking hands on your website, and you click here to talk to a sales guy.
That doesn't work. You don't withhold information from developers, and that's what typical enterprise sales is about. Don't talk too much about what the product does because maybe someone will actually figure out that yours doesn't do the thing they need to do or don't tell how much it costs because I can only tell you how much it costs if you tell me how much you can spend. These two typical enterprise sales tactics that are all about withholding information from the buyer, developers are the complete opposite. You can't BS them, you give them information and tell them what the product does.
How do you do that with the documentation? Tell them how much it costs. Let them sign up and let them get building any time of day or night that they want to do it, and in a very small amount of time that they can get up and running on their own schedule at the time when they want to focus on what you can do for them.
That to me we call it around here ‘no shenanigans’ that someone actually spidered our website and piped it through graph and found that there are about 460 instances of the word shenanigans on our website, and that's the way we talk about it, which is no shenanigans.
Just be straightforward, tell people what you do, tell them how much it costs, and if you solve a problem for them and they like the price and it's worth it, they sign up, and if it's not, they don't. You don't withhold information, you don't play games, you just be straightforward and that's the way we try to do business.
Number one, as developers that's how we want to be treated, so that’s how we built our company. Number two, why do developers want to be treated that way? Because developers are smart. They don't want to talk to sales guy who’s going to give them a run-around. They just want information that they can use to make an informed decision and move on.
I want to talk about documentation. How do you guys go about creating something that's just straight to the point, no BS, clean, explains everything?
When I was at Amazon they had this process they called working backwards. Working backwards at Amazon meant that if you were launching a product, the first thing you did was you wrote the press release, the very first thing. It could be a year before you ship anything, you write a press release. What's interesting about it is the press release forces you to focus on what the customer cares about because it’s what you would be telling the press.
The other thing you see about press releases, press releases have an order of importance to them. The headline expresses the most important arc of the story. The first paragraph tells you all of the most important facts about what the reader would care about. The second paragraph is a little background you tell them. By the time you get to the eighth paragraph it's the details that aren't that important.
The press release ends up being this tangible format of expressing the value prop to the customer. It forces you to make decisions about what is important, and would how express it and ultimately phrase all of that in the context of what does the customer care about. That's Amazon's working backwards process.
We adapted that here, but instead of it being a press release, it's that tangible format that you can actually discuss and mark up and come to conclusions before you write a single line of code.
We write the API documentation first, and then we collaborate on what the documentation looks like and how does it work, and does it solve the use cases we want to solve, and is it clean, is it understandable.
What we'll do is we’ll actually have customers we know who are interested in certain features we'll give them Akka documentation before we've written a line of code. We'll say “Hey, with this API would you be able to solve your problems?” And we get feedback from customers. Then we elaborate and on those problems. Once we come to the point where we say you know what, we think this is the right API, then we go build it.
For us we focus a lot on that that API design, and the usability of it, does it make sense, is it self-documenting? Do you have to read the docs or do things just kind of work the way you think they are? Are the defaults the sensible defaults? So the most common use case just works out of the box without you having to think about anything, and then everything kind of stems out from there.
How long do you spend on the docs?
It all depends on the product and the nature of the product and how complicated it is. Certain ones have been very easy. Other products we've worked on the documentation for months before we felt we had it right so it all depends.
What have you learned from your startup journey, what are the key takeaways that you've learned?
This isn't necessarily particular to Twilio, which is my fourth company. One of the things that I have learned over the course of doing all four of these companies is that you have to do something that you're passionate about from the product perspective. You have to be building a product that you feel the world needs, personally. You have to love the product, and it sounds sort of obvious.
I found other ways to rationalize it being an interesting endeavor, and why this was interesting or why some of the challenges involved were interesting, but at the end of the day, if I wasn't a user of the product and I didn't just say, “Hey this product needs to be in the world and the world's a better place because of it,” it makes it really hard to get through the hard times with a startup and all the times when you're working really hard and it takes a lot out of you emotionally, physically, whatever.
If you don't have that fundamental passion for this product needs to exist and we're going to get it into the world, it will be hard time making it through the difficult times and all that. You just have to have this deep, fundamental feeling that you want this product to exist because you want it for yourself and that's the best motivator you have.