His middle school videography curiosity-turned-business-venture foretold him converting his undergraduate fascination with the still-nascent internet into a dot-com business, too. “I wanted an excuse to figure out how this cool internet thing works,” says Lawson. “And what better way to do that than go find a customer problem that you think you can solve with it? Now you’ve got a mission.”
That M.O. stuck, and Lawson went on to become the founding chief technology office for StubHub and an early member of the AWS team at Amazon before leaving to launch Twilio, which now has well over 200,000 customers — running the gamut of size and industry and business stage — and more than 10 million developers on the platform.
Lawson straddles the line of software developer and CEO, giving him a rare perspective on the common ways the two sides misunderstand each other. It also gave him an early, deep understanding of developers’ needs in a software platform — which has been borne out in Twilio’s success, and expounded upon in his new book, Ask Your Developer.
“I always think about the superpower of software as your ability to hear a customer problem, or what you think is a customer problem, and very quickly go build a prototype, get it out in front of customers, and keep iterating your way towards a better and better and better product,” says Lawson.
Greylock General Partner Sarah Guo sat down with Lawson for another installment of Greylock’s Iconversations series to talk about his book, business trajectory, and what he sees happening in the future of software and the internet. You can watch the video from this event on our YouTube channel here.
Listen to the conversation here.
I’m Sarah Guo, a general partner at Greylock. And our guest today is Twilio CEO and cofounder, Jeff Lawson.
I’ve been so looking forward to this chat because I have an amazing love for companies that really invent a new type of business from first principles. And Twilio was an outlier when it came onto the scene in 2008: Mobile and cloud technology were starting to converge, but building a business directly for developers wasn’t a broadly accepted strategy.
Clearly, Jeff and his team were onto something. It was a vanguard company in terms of software adoption, and their cloud communications APIs went on to become a default part of the developer toolkit. And, today, the company works with more than 200,000 customers.
Jeff is a lifelong entrepreneur. He started his first business in middle school, launched another while he was in college, and was the founding CTO of StubHub. He was acqui-hired into Amazon and was part of the early team that built out AWS.
Throughout it all, Jeff has been a candid and outspoken leader who’s unafraid to talk about missteps. His new book, Ask Your Developer, is one of my favorite books of the past year and outlines strategies to create developer-led business culture.
As he says, “Build or die.” Dramatic, but right, in my opinion. We’ll talk about that too. And I recommend the book to all of you.
Jeff, thanks so much for being here today.
Thank you, Sarah, for having me here.
So, middle school is a pretty early point to start an entrepreneurial journey, and you’re a glutton for punishment, really. Tell us about how you got started down this path.
There are two things. First of all, I’ve always loved to learn by doing. So, instead of looking at a book, the way I tend to learn things is [to] just get your hands on it and figure it out. I remember, at that point in my life, I was really interested in video. I always liked video, and [wondered], “When you watch TV, how do they make those cool effects? And how do they shoot that video?”
My dad had a video camera, a very basic one. And I remember I wanted the real thing — I want one of those professional cameras. But how was a 13-year-old going to afford some professional camera? So, I was like: I’m going to start a business videotaping weddings and bar mitzvahs and all this kind of stuff, get people to pay me to figure out [how] all this cool stuff works. Have money to go buy the cool gear. And basically, figure this out. And that’s what I did.
So, my first company is called Video Visions. And a great tagline: Look forward to looking back.
I love it.
By the time it started out, I think when I was like 13 years old, someone would pay me 35 bucks to go videotape their third birthday party. But by the time I graduated high school, I was doing full-on weddings that might be a $10,000 gig with editing. And so, it’s just really interesting.
That was the first company that I built. But it really all came from, one, wanting to figure out how to do video, and, two, wanting to [get] gear that was really cool. And [that] made me say, “OK, how am I going to afford it?”
So, how do we go from that to Versity, StubHub, all these tech businesses?
Well, it’s interesting. So, the first company that I started — the first, let’s say, “real company,” or maybe interim company — I was in college. I started at the University of Michigan [in the] fall of 1995. This was a month after the Netscape IPO, and it became apparent to everybody that, Oh, my god, this internet thing is going to be big.
And so, I show up at school at the University of Michigan. And the first week of school, the first day of school, everybody is excited — parties, you’re excited about dating, or whatever. I’m like: I was most excited about the 10-megabit ethernet jack in my dorm room. At this point in my life, I’d only ever had like 28k modems. Having a 10-megabit internet connection, that was amazing. And so I started just playing around with this brand new thing called the internet.
I remember one of the first things I did in my dorm room, before I unpacked any of the stuff that I brought with me, was I FTP’d down a copy of Netscape Navigator 1.0. And that was where it all started. I started playing around with this technology. I remember [browsing] all these websites, sort of like academic stuff, and web pages about people’s dogs or their interests or whatever.
But then you start to come across these pages that were dynamic — they did things. I remember this one web page, [where] you clicked checkboxes for things you wanted on your pizza. So, it was like: pepperoni or olives or screwdrivers or hammers. And you’re like, What is this? What is going on? You click it and you click submit, and it would render a picture of the pizza that you just asked for with all those various things. Like, This so stupid. But that’s amazing. How do they do that?
I wanted to basically figure out how this whole internet thing worked. And so, I started my first company. It was very similar to the video company, which was like, I want an excuse to figure out how this cool internet thing works. And what better way to do that than go find a customer problem that you think you can solve with it? Now you’ve got a mission. You have a purpose for: Why am I learning this technology? It’s like, well, I’m going to go figure it out in service of this reason. And if I do a good job of it, customers will buy what I’m building.
That was how we started our first internet company, back in 1997. It was an online lecture company for college students. We took this industry that was — at the time, if you were in college, you could walk down to a coffee shop and get a Xerox copy of the lecture notes from the courses you were in. And you paid $50 a semester to do that. And we said; Well, why would you have to walk through the snow? This is Michigan, after all. Why would you walk through the snow to go pick up lecture notes when you could just dump them on a web browser?
And so, we built this company. It was called Versity.com, and we hired notetakers on these college campuses to go take lecture notes. We paid them to transcribe the notes, put them into our system. And then we gave them, for free, to college students. We ended up amassing an audience — like, a weekly audience of millions of college students — that came to the site every day. And we never made any money.
But we raised a bunch of venture capital. We had millions of people coming, and it was a very typical dot-com story: We were literally the dorm-room developers building this thing. We dropped out of school, raised venture capital, moved out to the Bay Area, built it up, sold the company to a competitor on an all-stock deal. The competitor went public or filed to go public in April of 2000 — and failed to go out because the market closed right at that point.
And they were bankrupt by August.
Was the competitor making money?
No. I don’t know.
Or is it like a true dot-com company?
True dot-com stuff. In our company, we raised I think about $12 million in venture capital, which was a lot at that time. And I think we made a total of about $30,000 in revenue, because we put ads on the site and said we’ll figure it out later. It was all about eyeballs and stuff like that. But that was the first entrepreneurial journey I was on.
So, despite the fact that we didn’t make any money for anybody — equity did not end up being valuable — it was such a wild ride of learning and figuring out new technologies, figuring out business, figuring out the internet, hiring lots of people. It was just this amazing thing. I’m like: I want to do it again. What a cool experience that was, that we were trusted with millions of dollars, and we could go build a website. We could go attract millions of people to that website by just building something that was of value.
And that really got me started down this path of saying, It’s amazing when you think about what the internet is and what software is.
"The scale that you can impact humans today with software, with the internet — it's really mind blowing when you think about it. And we kind of all take it for granted."
But when you sit back for just a moment and think about it, you’re like, Let me get this straight: I can open up this thing called the text editor. I can type some magical codes into the text editor, hit publish, and it goes into an app store or online on the web. Millions or billions of people can interact with that thing that I built, and I can build a company and make money. But, overnight, I can affect billions of people if I build the right thing. That is unheard of in the history of human creation.
For most of humanity, if you built something, it was like: a chair. And, great. A dozen people would sit in that chair, and that was the scale of your impact. And now, suddenly, anybody with access to a tech center or an internet connection can truly change the world. And that’s amazing when you really take that in and think about it.
Yeah. It’s incredible, and it’s inspiring. And without using the buzzwords about it, I’m gassed up about the idea that — not only [that] I write code, [and] more and more people write code, but you don’t need to anymore, actually. Increasingly, you can type words, as a human being, into a text editor in a higher level of abstraction and do the same. I think the internet’s going to become more powerful. And I can’t be excited enough about it.
It’s really interesting, about the accessibility of the internet and programming. Because the way I think about it, 30 years ago, I had Microsoft Word running on my 386 Windows 3.1 computer. And Moore’s Law has kicked in, in a serious way. Like, that computer was a 20-megahertz computer. Now, we’ve got our word processor, which is like you’re writing inside of a browser. And it’s like: Has the browser gotten 10 million times faster, or has the word processor gotten 10 million times faster? No, it’s the same thing.
We built all these abstractions into computing that enable us to do so much with so little. And, in many ways, that’s how we’ve used Moore’s Law — to build those abstractions. They’re less efficient than back in the way-long-ago when you were writing assembly code. But, with a tradeoff for efficiency, [it] means that there’s so many more people who can access building on the internet and can build software and can run it at internet scale and a global footprint.
It’s amazing, because it’s never been easier to write software. And I think we’ve used Moore’s Law in a pretty effective way to make the humans better at what they do, as opposed to making the computers better with it.
Yeah. I definitely want to come back to that. There are a couple different really interesting threads there.
One of them is also your role in being part of the team that started to build one of the most important layers of service abstractions in AWS — because, I would argue, that has been one of the biggest needle movers to people being able to build today.
But, before we get there: StubHub did work, or worked, in a much larger degree and did make dollars. How did you come to find that team and go on that mission?
Well, Jeff and Eric were the founders of StubHub. They were bankers, and they had this great idea for this business for people to buy and sell live event tickets. They wrote the business plan, and then decided they’d actually start the company. But they needed folks who had actually started companies before and operated [them].
So, I joined as the first hire, as the chief technology officer. My friend Matt joined as the chief operating officer. And, together, we started building out the team and the technology to get StubHub off the ground.
It was really wild. I always think about the superpower of software as your ability to hear a customer problem, or what you think is a customer problem, and very quickly go build a prototype and figure out if, indeed, you can go solve that customer problem.
And you get that out in front of your proposed solution. You get it out in front of customers. You get feedback. And you keep iterating your way towards a better and better and better product. And that’s exactly what we did at StubHub. A lot of people are surprised to hear that we went from the first line of code written to launching StubHub in about six weeks.
Yeah. I remember we had a hard deadline. The NFL season was starting, and we wanted to launch for the NFL season. We started writing code in, I don’t know, it was July or something. But that just goes to show you the power of: build something quickly, put it in front of customers, learn, iterate.
How did you end up thinking about developers? I assume Amazon and your experience there had something to do with it. You were obviously a developer yourself, but how did you end up thinking about them as a customer?
So, see, right. I was a developer, building things all the time. My third company actually was a bricks-and-mortar retailer for extreme sporting goods — skateboarding, snowboarding, surfing. I don’t know if we’re going to get into that. That’s a weird one. How did I end up starting to do that?
I built a ton of technology for that company. And I remember just thinking about, when I needed something, what would I do? What was the solution to this problem? You find websites and various things, and you go click around. And most of the time, you might say, “Oh, I need a point of sale system,” or whatever it was that I needed for the retail business.
And you click, and then you get to this thing where: OK, well, this looks interesting. And it’s like, OK, what do I do next if I’m interested? [And you get:] Talk to sales, talk to sales. That’s probably not going to be the thing that I, as a developer, need. Back, back, back.
You’d always find, as a developer, that there were certain signs that something was made for you, because it was self-service, it had published API documentation, so you could say, “Oh, yeah, this does the thing I needed to do.”
I realized that there were certain things that you would do differently if you were to appeal to a developer who’s trying to solve a problem. Maybe it’s midnight, they’re like, Oh, let me crack open this problem and see if I can solve it in the next few hours. That’s not the period of time when you’re going to talk to a salesperson. And a developer gets into the flow of trying to solve this problem. The biggest thing that breaks flow is: OK, fill out a form and wait three days for someone to call you back. Flow is: I’m trying to solve it, and I keep going and keep solving.
And so, I realized that there’s a certain way you build things for developers, which at the time was very nascent. And there really wasn’t open source and things like that.
When I went to Amazon, I went because I had been an entrepreneur three times in a row. My first company, Versity, my second company, StubHub, my third company, the retail business called Nine Star. None of them, at the time I was there, were all that big. It was always the early days. And in the early days of a startup, you’re just kind of running around doing stuff, and it’s not well organized. There aren’t even a lot of meetings. It’s just: Get stuff done.
And I always thought, if I’m an entrepreneur, success looks like I build a big company one day. Yet I have no idea in my head of how big companies work. I literally never worked at one. I was like, I know there’s these big buildings and the logo of the company is at the top of the building. And people walk in at nine and they walk out at five. I had no idea what they do all day, which sounds so weird, but it was true at that point in my career.
And so, I said, “I want to go work at a big company. I want to learn how bigger companies work, and what goes on in those buildings.” And because, if I want to build a company one day, let me have a model in my head for: What are the things I want to replicate? What are the things I want to avoid? I made a very short list of companies that seemed like the kind of companies where I’d learn that, and got an offer to join as a very early product manager at Amazon Web Services.
It’s a funny story. I was interviewing there. The AWS team was, I don’t know, probably about 30 people. And I was interviewing and Andy Jassy was in my interview loop. And you get to that part of the interview where, at the end, the interviewer is like, “Well, do you have any questions for me?” And I said, “Yeah, I actually do. What is Amazon Web Services?”
They hadn’t explained—
[What] I spent all of my day interviewing for. [They said,] I’d love to tell you, but I can’t. It’s top secret. But, trust me, it’s cool.
And you took the job based on that?
As it turns out, when you’re a relatively mobile 20 something candidate, that’s a really great recruiting tactic to be like, Yeah, I could tell you, but then I’d have to kill you. Yeah, I took the job. I’m like, “You know what, I’m going to trust this guy. This is cool and this is interesting.”
So, I moved up to Seattle and started my first day. My first day, I got there, and my officemate was this guy named Dave, who was the first product manager for S3, the storage service. And it was like, “Hey, Dave, nice to meet you. What are you working on?” He’s like, “Well, we’re building this storage thing where it’s a HTTP request. And the developer can embed, can store files in it. And it only costs like a penny.” And I was like, “Wow, this is mind blowing.”
And I just started seeing all the things we were building at Amazon — this whole idea that a developer would be the customer. And that this is the infrastructure that they would use to, like Amazon, build internet-scale applications. And that was absolutely amazing to me.
When I left Amazon, I knew I wanted to start my next thing. I got the experience; I saw the big company; and I said, “OK, it’s time to start my own thing again.” I thought back and [had] this question of, “What am I going to start? What am I going to do?” And, so, I started looking at a lot of different ideas.
But one of the ideas, one of the things I realized, was that [at] all three of my prior companies, there were two things in common, even though they were completely different. I mean, the businesses couldn’t have been more different from each other.
Number one: the power of software. The fact that we were using software to understand a customer problem, build the answer to that problem incredibly quickly, put it in front of customers in record time, and then iterate our way towards a better and better and better product experience. And to me, that’s the superpower of software.
But the second common thread between all those companies was [that] we were building up these customer experiences and the lifetime journey — of how you go from finding the company, to signing up, to using the product, to getting help, all that stuff.
At every one of those points, there would always be these ideas of, Oh, wouldn’t it be great if we could let a customer call in and get automated access to this information? Wouldn’t it be cool if we could send a text message to them when this thing happened? We kept having these really neat ideas.
And every time we had those ideas, they were like, “Yeah, that’s really cool. But I’m a software developer. I don’t know how to do that. Making a voltage on some phone line somewhere in the world appear? I have no idea how to make a phone ring.”
So, we turned to the companies who seem like they did. We turned to carriers. We turned to people like Cisco. We said, “Hey, you know what, we have this idea that we’re trying to figure out. Can you help us with that?” And every time, we got pretty similar answers, like: “Oh, yeah, interesting idea. We can help you with that. First thing is you’re going to roll out a bunch of copper wire from a carrier, then you’re going to rack up a bunch of hardware, and then you’ve got to buy this whole software bit. And then you’re going to bring in this army of professional services to come and bang all this technology together. And I think we can bring it into submission and do this thing you want. It’s going to take us three years and $4 million. But sign here, we’ll get started.”
And every time, I was like, “Wait, first of all, millions of dollars. We’re starting off. I don’t have millions of dollars to spend on this thing.” But more important than the money, actually, was the time. I was like, wait, hold on, let me get this straight: We think we know what our customers want. And three years from now, when we finally get version one rolled out with this waterfall looking process, we put it in front of customers. Then they’ll tell us what they really wanted, and we go back and spend another three years and $4 million to build the thing based on the feedback? This is the opposite of software.
How do we ever expect to serve customers if this part of what we do is so diametrically opposed to everything else that software people do? And that was when I said, OK. How do we bring this idea of communications, and how we engage with our customers, into the software? How do I put this into the tool belt of every software developer in the world? When they run into these ideas and they say, Oh, wouldn’t it be cool if…? — the answer now was: Yes. Let’s build it in an afternoon. And that’s where we started building Twilio back in 2008.
Yeah. Amazing. And, clearly, people do a lot more if they can just say, Well, what if… and We’ll just try it right now. And then [in] 10 minutes, I’m in flow and have the creative idea.
In 2008, 2009, what was the reception for the initial idea?
Reception by who?
By developers, by your audience. But there’s clearly another comment behind that joke. So, you tell me who the other one [was]. [laughs] I suppose I don’t know [your] investors, your parents and friends.
Your cohort there.
Well, so, developers — here’s the interesting thing. As I said, I was working on a bunch of ideas at that time. And I had an idea for a distributed BitTorrent-based cable company, and an idea for a computer backup service. Bunch of things.
And every time I had an idea that was working, what I would do is go find a bunch of what I thought were the potential customers for that thing. Usually it was friends, family, colleagues, whatever. And I would say, “Hey I’m thinking about this idea.” And I could describe the problems. And then a funny thing happened. Either, one, they start asking you a bunch more questions, like, “Oh, well, that’s really interesting. Would you do this, would you do that?” But, usually, what happened is there’s this awkward silence, and they’re like, “Yeah. How about those Giants? Did the Giants win last night?” And you’re like, “Oh, OK. Yeah.”
And they would awkwardly change the topic because they had no idea how to respond to what you just said. And that shows that you didn’t tickle some problem that they deeply held, that it didn’t pique their interest. And they were trying to be polite, but didn’t really understand what the hell you were talking about.
So, when I had the idea for Twilio, I went to a bunch of software developers I knew. And I said, Hey I’m working on this idea of this platform in the cloud. And you can make API requests. And you can make a phone call,” and kind of describe what it did. And I’d say, “Does that sound interesting to you?” And if anything happened, they would say, “Oh, yeah. How about those Giants?”
So, at first, I was like, OK, this idea is no good. But then a funny thing happened. Almost every time, conversation moved on, but a minute later, they would say, “Hey, yeah, I got a question. You know the telephone thing you were talking about a few minutes ago? Could I send a notification to a customer when their package ships from the ecommerce site I just built?” And I’d say, “Yes, yes you could.” And they’d be like, “Oh, that’s interesting. Yeah, we were just trying to figure that out. Hey, can I try that out?”
And so, every single time I got this, the gears started turning in their head after I described what we were thinking. And they’d always match it to some use case, something they had been trying to build, just like I had been. And they would inevitably say, like, “Oh, yeah, I’d love to play around with it. Let me know when I can play with it.”
And that gave me the confidence to say, I think this idea has merit. So, we started building it. I stopped with all of the stuff I was working on and started building this thing.
Took a prototype that we built, put it out in front of many of those developers that we talked to, and said, “Remember you asked to play with it? Here you go.” We’d send them some credentials. And we kept building it and getting feedback and iterating. And that was the encouragement, really, that allowed us to continue investing in this, quit anything else that we were working on, and just focus all of our energy on Twilio.
And the funny thing was — you’d asked before, what the reception was like — [when] the developers that were digging it in the early days and giving us a lot of feedback and adopting, and people started building apps, all of Twilio was running on one EC2 small. And it was really not well made, but it was just enough for people to be able to prototype things. And [a developer] launched on Lifehacker — the thing that they had built on top of Twilio got coverage on Lifehacker. And we were like, No, don’t build things that are real, but nonetheless, it worked and it was fun.
So, people started building things. We said, OK, great. We got early customers coming on board, that alpha type period. Then set our sights on bringing in or raising a bunch of money, and then we were going to launch.
So, summer of 2008, I go out to raise a seed round for Twilio and go around to talk to a bunch of investors — I go to Sand Hill Road, I go to angels, I do all this stuff. And two things happened. First, it is the summer of 2008, financial crisis is in full swing. People were literally like, It sounds interesting, but we’re just not investing. So, sorry.
I remember I got one investor really interested. It was the full partner meeting I was going to, which is usually the last step. It’s a formality, basically, and then they fund you. And I remember it was the day after Lehman Brothers collapsed. They walked into a full partner meeting. They were like, “Sorry, no, we’re not doing anything anymore.” So, that sucked.
But more interesting than that was the other bit of feedback that I got from a lot of the investors. [They] said, “You know, I don’t really get it. Software developers, they don’t have any budget. They don’t make decisions. They’re not a market. No one knows how to reach them. So, come back to us, why don’t you go build an app, go build a PBX or a couple of apps. If you really want to, you can add APIs to it later.”
Facebook did, [it] seemed to work out for them. But: Go build an app and come back to us and talk to us if you build an app. That was the most common refrain that we got during that whole summer fundraising. “Go build an app. That’s what everyone does.”
We went that whole summer. And because of the financial crisis, because of the developer thing, I spent that whole summer trying to raise money — didn’t have a dime, not a single investor, nothing. We didn’t even have a bank account, because we would have had nothing to put [in it]. You need a check to open a bank account. We had nothing. And I remember this very fateful phone call I had with my two cofounders. And I said, “So, look, we couldn’t raise any money. What do you want to do?”
And we thought about, Alright, maybe we should just go build that app that everyone’s talking about. Maybe we should go back. It’s a horrible idea. We should just go back to square one and find a different idea. But I remember us coming to the conclusion that, Look, our customers are telling us we’re on the right track. Developers are building stuff. They’re loving this thing. Let’s follow our customers.
And so we did. There was a very small amount of money from a few friends and family, and we launched Twilio. And, immediately, developers started signing up, paying us, building stuff. Our second day after launch, Sony became a customer. And yeah, righ?. It all just started happening. And I circled back for those investors and started showing them, Look, here’s traction starting to happen. New, small-scale traction, but every month the revenue was ticking up, up, up.
In the beginning of 2009, I was able to go raise money. But it just showed that [when] following customers, don’t worry about what investors tell you.
"If your customers are sending you a signal, really pay attention to that. Because what do investors want? They want traction."
They’ll give you their best advice on how they think you can get traction, but the real thing everybody wants is traction. And so, follow your customers to get traction. And that’s what we did, and it worked out really well. We were kind of off to the races.
My, how times have changed. And everybody is a believer in, or many people are believers in, the API economy today. But it’s an incredible start. When you say Sony became a customer on day two, that doesn’t come for free, right? Reaching developers is still a practice. And I know, even in 2009, you were talking about the power of community. I’m a big believer in the power of community. I even invested in a company called Common recently, that allows companies to better serve their communities at scale.
But you talked about communities, social presence, open source, the pace of blogging, conferences — this wasn’t mainstream enterprise go-to-market in 2008. People didn’t believe in it. Investors didn’t believe in it. What gave you the confidence it would work? Where’d you come up with the ideas for that?
We had a very sophisticated marketing strategy. It was: Be everywhere. Be awesome.
That was our marketing strategy. And we just started doing the things that we said would reach us. One of the great things about kind of being the customer demographic you’re trying to reach is you just literally say, What would resonate with me? So we started going to meetups. We started going to hackathons. We started buying ads on websites that developers frequented. And just got out into the real world where developers were convening, and in the online world, trying to figure out where they’re competing and get there.
I remember at one point, you really [had to] think like a developer, to say, OK, what’s going to get them in? We never actually did this, but I really wanted to do it. Asterisk was a popular open-source, telephony server. And, [in] the early days at Twilio, a lot of people I talked to about Twilio, they’d be like, “Oh, yeah I tried using Asterisk to solve this thing. It was so complicated. I couldn’t figure it out. I wrestled with this thing for a week and then gave up.” That was a common refrain I heard. So, I was like, Oh, why don’t we go buy Google ads for the error codes for Asterisk?
Because, think about that developer trying to wrestle this really complicated piece of software that’s not working and all the error codes that they’re Googling trying to figure out How do I solve this problem? Let’s just put an ad that says, like, “Hey, don’t bother figuring out this error, just move to the cloud.” And so, things like that — guerrilla tactics to get yourself in front of developers and the things that developers care about.
One of the early things that we did is we started a weekly developer contest, the Netbook Contest. Remember, there was a brief window of time when netbooks were all the rage? Those $200, $300 computers, they were like that big. It had a little keyboard, a little screen, but they ran full Windows or Linux. And there’s no use case for it. They were just kind of cool. So, you couldn’t justify selling out your own $300 for it, because you knew they would just sit in the closet, but, damn, you really wanted one.
And so we were like: Alright, let’s run a contest. Every week, we’re going to give away a netbook, and we’re just going to make up a theme every week. And this week, OK, the best thing that you can use Twilio [for] plus Halloween. And we were like, “That’s this week’s theme.” And in the early days, for some of these contests, we’d have two people who would submit an entry. And then we’d write a blog post on Monday morning, like, “Oh, of all the entries we got, we picked such and such. And here’s the new theme.”
And so, we just did that. We stopped doing it at some point. But by the end, we’d have a lot of entries. And it was a really great vehicle to go do partnerships. I remember [in] the early days of Twilio, I called up Jeff Barr at AWS. I said, “Jeff, can we do a joint contest with AWS, and you’ll give the winner like $1,000 of AWS credit?” He’s like, “Sure.”
So, we did joint [contests]: The best use of AWS plus Twilio, the best use of this and this. It gave us a venue to go build partnerships and build relationships. And: “Oh, yeah, Jeff, and you’re going to blog about this in the AWS blog, right?” “Oh, yeah.” It was a vehicle to go get ourselves out into the world.
This was all super guerilla, but just saying: OK, I’m a developer, what am I looking at? Where am I going? What am I doing? Where am I learning about new technologies? Where am I doing my job? And even things like Googling error codes was one of things that we were thinking about — of, Where are the places where you might need a developer? Be everywhere, be awesome.
Yeah. And that’s so interesting, because it speaks to another theme — we’ll talk about the book in a bit —but about developers.
If we’re going to have developer-oriented businesses, developers need to be business people and to be thinking about what the go-to-market is for these businesses. Because people who do not understand the audience — you can’t take your average SEO consultant that doesn’t think about developers and have them come up with the error codes for Asterisk. That just won’t make any sense.
That’s a great story. [I] still want a netbook.
There may be a closet of them somewhere in Twilio, still.
So, Twilio works with a huge range of customers for very different use cases at all levels now. Were there some early customers, key ones, that taught you the most important lessons about how to keep iterating and move the product forward?
There were so many influential early customers. I’ll share a couple of interesting stories.
Intuit became a customer very early on. And at the time, we were entirely self-service. You had to come to our website, sign up. And famously, one of the first investor pitches I ever did was kind of a friendly investor. He’s the guy who invested in my prior startups. It seemed like that’d be my very first investor pitch for Twilio, the friendliest one possible, a guy who’s invested in me multiple times in the past.
And he asks, “So, what’s your sales strategy look like?” And I said, “We’re not going to have sales. It’ll be self-service.” He laughed me out of the room. Laughed me out of the room. He’s like, “You are going to need salespeople.” I said “No, it’s all self-service. Developers just come, sign up.”
That was still the mode we were operating in, and Intuit became a customer. And I remember I got a support ticket via email — [we were] still the three founders and I think maybe two employees at the time —and the support ticket came in, and it was a product manager from Intuit. It said, “Hey, we just discovered Twilio. We’re building the thing, but can I talk to somebody about what we’re building?” And I was super excited. I was like, “Oh my god, Intuit. This is fantastic. Of course, set up a call and I’ll talk to them.” [And it was] like, OK, how reliable are you, and how does this work? How much does it cost? We get discounts at scale, blah, blah, blah — the whole thing.
And I’m so excited to get Intuit as a customer. I’m like, Wait a minute, I just did sales. And so, I remember at that moment realizing, Oh, you know what, yeah, clearly, we are going to have sales. And that’s when we started our sales journey, of hiring people to actually talk to customers.
What were some other interesting customers early on. I mean, there’s so many. We have about 235,000 customers now, and over 10 million developers on the platform. Just some interesting use cases. One is this doctor in the U.K., who built this thing called the Parkinson’s Voice Initiative. He did this study to realize that with just a phone call recording of your voice for about 30 seconds, he can actually diagnose with greater than 99% accuracy whether or not you’re going to get Parkinson’s in your life. And he built that study.
He basically built machine learning models based on voice. And he built that whole study, and proved that out for less than $1,000. And when you talk to him, he’s like, “Yeah, historically, this would have been: No, I had to go to my institution and get a grant. And the grant would be for a million dollars. And it would take five years.” He’s like, “We built it in like a week. And we had our results six months later.” And he’s like, “And it all cost us nothing. This was just mind blowing for this pace and the quality of the research that we can do.”
I remember another one. There were these other researchers — sometimes researchers have the most interesting use cases. Their job, they were tracking the migratory habits of bears. So, if your job is to track the migratory habits of bears, usually [what] you do in a typical day [is]: You get a helicopter, you fly around with binoculars, and you go spot some bears.
And when you see the bears, you’ll have the helicopter, you go run up to the bear, you shoot it with a tranquilizer. And then, hopefully, it’s tranquilized, and you climb on up, you put a collar around its neck, and then you run away, hopefully before it wakes up, fly away. And then a year later, you get back in your helicopter, you go try to find that bear, again, so that you can, again, tranquilize it to pull a data card out of the collar, put a new data card in, and then run away, hopefully before the bear wakes up. And they were like: “There’s got to be a better [way]… I’m really tired of shooting bears with tranquilizers.”
And so they built this collar that had a 2G, very power-efficient modem that would collect data and periodically wake up. And if the bear ever wandered into cell service, it would text all the data off the card as fast as it could. It was super powerful.
This is a better system. Yes.
Much better system. I call it the internet of bears. And just sort of these use cases you end up with.
But we have customers of every shape and size. We’ve got digital leaders that you think of:, Uber, Lyft, Airbnb, pretty much everyone. But now the incumbents, as well, in every industry. So, major banks: NatWest, ING Bank, Bank of America. I mean, you name it.
"Every company is having to become a digital company."
And when they do, they start adopting the tactics of the great digital companies, which is: they start hiring developers, they start building software, they realize they have to build in order to create a great experience.
So now our customers really run the gamut of every industry, every continent, and every kind of company — big and small, new and old. That’s one of the things that’s really cool about being a platform — you can really attract every kind of company and every use case, even things you didn’t imagine on the day that you started the company.
You build a new product, you find yourself being used for these things, whether it’s verifying customers’ identities, powering the contact center for a major global bank, or tracking the migratory habits of bears.
There’s a reason why, at the end of every press release Twilio’s ever done, there’s a line from me that says We can’t wait to see what you build.
So, I have to ask you for all of the founders listening in right now. It’s a common adage that you need a killer app to make a platform company. You’ve built a platform company, and I love bears, but tracking the migratory habits of bears probably isn’t the only killer app that made Twilio.
You’re not going to go tranquillize some bears this weekend?
I feel like I have picked the wrong career path. That’s really cool. But I love software.
I guess, how would you respond to that — the idea of needing to identify the killer app to make a platform grow quickly?
Well, I always thought about this 80-20 rule. Because 80-percent of what people want to build with your platform, you should probably have a reasonable idea [of], and it should be easy to build those things. But there’s another 20-percent, which is like, I’ve got to get it figured out, and let’s make sure those are possible.
So, the obvious things should be easy and everything else should still be possible. It’s how we’ve thought about it. Inherent in that is this idea that like, yeah, we do have a bunch of ideas about [what] people [want] to build. Therefore, we should optimize the product of the platform to make those things easy and make them work really well. And so we’ve always sought to do that. But the challenge — the difference between a killer app and the platform — is everything else is possible.
You learn that a bit by building yourself. I remember [in] the very early days of Twilio, we built a thing called VIP, vip.twilio.com. Yeah, no one’s heard of it. It was another — it wasn’t a growth hack, but, I gave [out] a secret business card. We had these black business cards printed out, and all it said on them was vip.twilio.com. This was before influencers were a thing, but I gave them out to press, to analysts, to investors. And you could log into it only if a secret Twitter account followed you.
And so, if I followed you from that secret account, then you can log in to this vip.twilio.com thing, and you got three phone numbers. And the three phone numbers were a conferencing line, a voicemail transcription line, and a toll-free phone. You got your own toll-free phone number.
It was. It took us 10 minutes to build this thing. And the interesting thing, the reason I tell the story, is we were our own ISP — building an app on top of Twilio that that itself had many customers. Our customers in a sense: the VIPs I gave it to. And because of that, we realized, Oh wait, it’s really hard to build a multi-tenant app on top of Twilio.
That led us to go build a bunch of features that ended up being really valuable to ISVs — companies like Zendesk or ServiceNow or Talkdesk. These folks are built on top of Twilio. All the features that we intuited we would need because we were building a little bit on top of it ourselves directly enabled those amazing customers to then go build things on top of Twilio as well.
Yeah. Such a cool path, and very consistent with your learning-by-doing mentality.
The notion of the killer app, though — most people say you have to have a killer app, that you build, and that’s driving adoption of your platform. I thought about it a little bit differently, as: Let’s build on top of our own platform, so we know if our product is good for the use cases that we can imagine. And let’s test the hypothesis that many other things are possible. But not [that] the killer app is how you drive adoption of the platform, because that’s a different model. That’s the, “Hey, go build an app, and then add an API to it.” That’s really what that model is. That’s the killer app.
And I thought of it as: Our job is to deliver composable building blocks, programmable APIs that allow developers to embed those into the great many things they’re doing, which is just kind of a fundamentally different value proposition.
Yeah. We don’t have any that track bears, yet, but I sit on the board of some companies that are trying to be platform companies. And I get so excited when people build weird things on them, because it tells me that there’s experimentation. It’s working in people who are trying to stretch the limits of what’s possible.
Let’s talk about the book. So, I loved it. I genuinely mean that. I recommend it all the time. But I’m a software person and making a huge career bet as an investor enabling other software people. So, I’m like: I drank the Kool-Aid.
What motivated you to write the book? What were you hoping to accomplish?
I am a software developer and I’m a CEO. I talk to developers all the time, and I talk to C-suite people all the time. And what I’ve found, what I’ve noticed, in talking to so many customers, especially big customers, [is that] there is this gap between how developers think and how business people often think. And they don’t really understand each other.
Think about it, you’ve got the business people who ask these questions: How come the developers, like the roadmaps, always seem to take so long? And they can’t tell me what date this is going to ship or what features it’s going to have? I think about Agile. What do we often say? You can predict the timeline but not the features, or the features but not the timeline.
To a business person, you’re like, “What? We have a marketing conference. We’re spending millions of dollars. You’ve got to tell me when it’s going to ship and what it can do.” And developers [are] like, “Sorry, we can’t say that.” It’s infuriating. Think about the flip side, the one of the developers, [it’s] Oh, the Dilbert pointy-haired boss guy doesn’t get it. And it’s like these two sides don’t understand each other.
Well, as a developer and CEO, I’ve got a foot in both worlds. And I regularly would get customers come to me and ask things like, “Jeff, I just have this question. We’re trying to build a software culture, and we’re trying to hire developers, but it’s really hard. How do we do it?” And I find myself talking through some of these things, about: How do you hire great talent? And how do you empower them? And I realized that my role as both developer and CEO is pretty rare.
So, let me take the knowledge that I have as a developer, and let me try to give a playbook to the business people of the world, of: Here’s what’s actually going on with those developers. Here’s how it all works. And here’s what you need to know to be a business person, or an executive, who’s going to have a high-performing software team in your company. How do you not be the pointy-haired boss? And, by the way, how do you unleash that talent to do great work?
And that seems to be the missing book. Because so much has been said about digital transformation. I mean, every article.
There are so many books and articles written about digital transformation, it’s almost like the software is going to write itself. And, no: Like anything in business or life, it’s all about people.
It’s: What are people going to do? And nothing has been said about the talent. The people of digital transformation, the software developers, the people hands on keyboards making this whole thing happen. How do you unleash them to go win in this digital economy? And so that’s why I wrote the book.
OK. So, let me ask you a question [about] sitting on both sides: software person, business person. Developers are creatives. I strongly believe that. But it’s an interesting creative activity, because it’s not painting or being a jazz pianist. You’re still building with schedules and on teams. And there’s a piece that’s like the industrial craft of it, where we also — let’s just think about the VP of engineering persona. We care about delivering against expectations with some degree of predictability. And you do have different levels of performance in your team.
Can you tell us a little bit about how you think about managing engineering teams when you obviously have such empathy and understanding for the thing that could make Twilio magic — [that] the thing that could make it great is leaving room for that creativity?
I think that’s the key thing. The key thing is, first of all, recognizing that code is creative. And by the way, the examples you gave of, like, a musician, well: There are professional musicians. There are some cities where they have to perform every night and have to make it work. And so there’s always an art of taking something that is a craft and a creative exercise, but also turning it into a predictable thing.
But I’ll also say that, in the world of software and business, there’s a certain creative aspect. Think about the disruption that’s going on in the world all around us, and try to predict what the disruption is going to be next year, or next decade, and how our companies are going to survive that and thrive in that world. That’s a fundamentally creative thing.
The interesting thing about software is anything is possible. Rarely are there things that most companies want to build and you’re like, Software can’t do that. Like, no, computers can do almost anything that we need them to do. Therefore, the only question is: What do we want them to do? What will create business value? What will my customers appreciate, etc. That’s the creative process.
So, first is recognizing that code is creative. And if you talk to most business executives, I think their view of how technology teams work is sort of like: OK, over here, there’s some business people, MBAs who have gone and talked to customers and written a specifications document. And, then: I’ve got this black box over here where all the developers are. And if you feed product specs and Mountain Dew in one end, you’ll get code out the other end. That’s how it works.
And what I’ve tried to do is to dispel that, like: No, no, no. For a creative field, you don’t want to hand people solutions and say, “Build this.” You want to hand them problems that you want them to solve. Because developers are creative problem solvers. And if you think that the only kind of problem a developer can creatively solve is like, How do I build this sort algorithm? — you’re really missing out.
By the way, hint, developers don’t build algorithms anymore. What you’re really doing is saying: How do I solve some business problem with a computer? And that’s fundamentally creative. And so one of the things I talk about in the book is [to] share problems, not solutions.
Imagine one world where a business executive writes product spec and hands it to a development team that says, “OK, we do a forum on a website. It says first name here, last name here. Last name can be 40 characters long.” Well, you [can] get a developer to dutifully write you that forum, I’m sure.
But imagine a different world, where that executive goes to that software team and says, “Hey, what we’re really trying to do here is make it so a customer can sign up for our bank account, and they can do it in two minutes, not the hour that it takes today. Can you help me solve that?”
Now, you’ve got the software developers talking about all sorts of interesting new ideas: Oh, what if we change the flow this way or what if we delay gathering this information until later? What if we do all these cool things that we’ve seen, felt, heard? And technologies that we’ve played around with, that can enable us to do these amazing things?
What I found is that, when you do that — when you go to a team with a problem, not a solution — a few things happen. Number one, teams get really invested in the problem. We’re humans. You give someone a mystery, they love solving them. Hand people mystery, ask them to solve it, and people get really invested in that.
And when they know why they’re solving the problem, and they know who the customer is, there’s all sorts of things that come into it. The spec doesn’t say whether they should hit enter or not. I don’t know, do what seems right. Do what you would want.
And then, third, is: There’s a level of pride. There’s a quality that goes along with that, going the extra mile.
And so when you do those things — hand a developer a problem, not a solution — people tend to get better software, written faster, with the details thought through. Who doesn’t want that? What business executive is out there saying, “Those aren’t the things that I want.” Of course you want that. And the interesting thing is that the business people and the software developers are all super aligned around the same motivation. They want to build great technology that’s used by millions or billions of customers and it makes the company money. That’s basically what everybody wants to do.
So, great, let’s align around that. And let’s get into creative problem solving. How to do that? What should we build? That is a hard problem. Great. Let’s get our best minds all thinking about that. How are we going to serve our customers, not assuming that, Oh, that’s just the product manager’s job. That’s just the MBAs job to go figure that one out. No, let’s get all of us thinking about that.
Talking about things that are on the roadmap and moving into the application layer, what’s the strategy in the contact center space?
Oh, absolutely. So, we’ve got a product called Flex. We have a big ecosystem of contact centers built on top of Twilio, and we have a platform that we built ourselves. Now, the interesting thing about our platform, what we found, is that there are a lot of customers who want a turnkey solution. And there are a lot of partners who have built those on top of Twilio. Amazing companies like Zendesk and Talkdesk and Zoho and Freshdesk and all sorts of really cool companies out there.
But we found that for the very large contact centers in the world — these ones are thousands and thousands of agents — they do a ton of customization of those solutions. And SaaS does not lend itself to really deep customization because the power of the cloud is multi-tenancy. It’s one code base that everyone’s using. And so, typically, there are a few things that you can tweak, but you really can’t go in and deeply tear the thing apart.
And what we found was that there are a lot of companies out there, bigger companies, that need to be able to go in and tear the thing apart in order to make it work the way their company works, and to fit with their workflows — all sorts of interesting things like that.
So we built Flex as a contact center platform that enables a company to go, take it out of the box, and have a contact center [with the] many things that it does and has — all the channels and has routing of agents and all this kind of stuff.
But, fundamentally it’s still a developer product, [that is how] it’s designed. The first step after you spin up a Flex instance, it says, Alright, now download the SDK and start building. And you can build modules for it. The whole thing is built — On the back end is all of our rest APIs, on the front end is React. Developers can go change the parameters of the default React components. They can go build their own React components.
We invented a way to basically compile in our core code and your React components and all your customizations and continually recompile the combination of both of our code bases into a runtime that is just yours — that runs on our platform, that allows us to keep innovating and you to keep innovating. And as long as you keep that contract in place, we can both keep making the solutions better.
We launched that about three years ago. And, now, we’ve got amazing companies, both digital-native companies — Lyft is running their customer service on Flex, and Shopify is running their customer service on Flex — but also really big banks or insurance companies. Allianz Direct is the largest insurer in Germany, and a very traditional industry, and they’ve spun up their new digital business on Flex.
It’s really been really interesting to see this problem, out there in the world, was the amount of customization that companies need to do has really held companies back from migrating contact centers from on-prem to the cloud.
And contact center business is a huge one — and 85-percent of that market is still on-prem. And you think about every other category of software is like, hey, it’s well on its way to being a cloud business. It’s like 80-percent on the cloud, and the 20-percent laggards are still on-prem. And the contact center is reversed. You’re like, Why is that? And when you go double click on the problem, the problem was that nothing in the cloud provided a level of deep customization. So we built that platform to enable that.
You’re a huge SaaS business with consumption-based revenue. You do report to the street. How do you think about forecasting that revenue?
You know, it’s an interesting problem. And in the early days of Twilio, it was like: How do we forecast? Now, luckily, in the early days of a company, you don’t really have to forecast. But what we did was, if you have a large customer base — we have 235,000 customers across many different verticals, many industries, many continents, big companies, small companies — it starts to actually look more like a consumer business in some ways.
I don’t think Amazon forecasts how much I’m going to buy tomorrow, but, in aggregate, all their customers, humanity, will act in a somewhat predictable way. And I think that a usage-based SaaS business ends up being that way as you get big when you get to scale.
And so, our FP&A team has been able to model the business. And the first few years, I mean, this was before we were public, but the first few years, the model was it’d be off by 5-, 10-percent. And then it kept dialing it in, dialing it in, and dialing it in. And now we’ve got models that are pretty darn accurate for what the business is going to do. So that’s pretty useful. And, again, it kind of goes back to aggregates.
Well, I could certainly be here for another couple of hours, but we’re at the end of our time.
Jeff, thank you so much for being here today. And thank you to you and everyone at Twilio for powering so many of the products and tools that we rely on, and paving the way for a new type of company. It’s been such a pleasure to have you.
Awesome. It’s great to be here. Thank you for the invitation, Sarah. And it’s been fantastic to chat with everybody. Hope everybody is doing well, and I can’t wait to see what you build.