Twilio’s Jeff Lawson on Building and Scaling a Developer-Facing Business
Jeff Lawson is co-founder and CEO of Twilio, one of the first and most successful Services-as-Code companies in the world. Under Jeff’s leadership, Twilio helped define how best to build the next generation of developer-facing businesses. We at Redpoint have been fortunate to be a part of the journey and he graciously took the time to chat with us, sharing some of the lessons he has learned building and scaling Twilio.
If you are interested in learning more, this month Twilio will be hosting Signal, a conference for developers building the future of web-based communications. If you want to be a part of the conversation regarding the future of messaging, bots, WebRTC and IoT, you can register here and use REDPOINT20 for a discount.
On the keys to Twilio’s success…
It’s been a combination of 1) getting into the developer community and being authentic and then doing that at scale, and 2) that our product really added something substantial to the developer tool kit. The fact that we are able to add this fundamental new capability to what you can do as a developer was clearly powerful.
It’s not that we made the developer’s life a little bit easier, which would be fine, there are lot of tools that do that, but the special thing that caught people’s attention was that Twilio made new things possible. The fact that when we do a demo, we’re able to have code leap out of the computer and do something in the real world — make the phone ring — is fairly magical. Then it works to our benefit that we’re able to say this magical power that I just demonstrated is available in just few lines of code to any developer using our API. So many developers write code that’s always constrained in that little box [the computer]; how many times can you write a form database application? That’s every web app you’ve ever built. But now suddenly you can write a few lines of code and instead of just putting strings into a database you are actually making something happen in the real world. It’s pretty exciting.
It just so happens that this magical product also translates into a business that operates in an enormous industry. But at the most basic level it’s about treating customers incredibly well. Figuring out how to reach the customer was sort of natural for us as developers. And then having a product that solves a real business problem. Those two things have to work in concert together. It’s that combination that’s allowed us to be so successful.
On winning the hearts and minds of developers…
It really helps to have the mindset of developers when building products for developers. You can never lose that perspective. Think of how you would want to be treated if you were working with or engaging with a product or with a company. And it’s really more than engaging the average developer, but making sure that they can be successful using your service.
Here’s the thing: you shouldn’t be out there selling something as much as you should be becoming a part of the community you are trying to serve and that’s changed too. Community used to be a thing that was like a forum on your website. And now community is everywhere. Meetups, out there in social media, in new native platforms, on Twitter, StackOverflow, etc. So it’s a commitment to cultivate community out in the world as opposed to in your internal facing view of it. We just go out into the world online and offline, wherever the developers exists.
Be helpful and be yourself; it’s community. Sure we represent the company, but you can’t be overtly commercial and can’t be overtly trying to sell something. I think that’s how we’ve always looked at it. And I think that’s why we are able to have a genuine dialogue with our customers. Sure, we have our agenda because we have our business, but at the same time we’re just trying to be good members of the communities we serve. It’s a long play, it’s a deep relationship to build. But I think it’s really good to build that long term relationship.
On marketing to developers…
You have to show developers what is possible, but you don’t want to limit what’s possible. Developers are very creative, but at the same time like any creative endeavor you need to get the juices flowing. This has been an area that we’ve always sought to innovate and try to truly figure out better ways to educate new developers on what Twilio is and what you can do with it. Our most recent example is the Twilio tutorials. This tool lets code really tell the story about what’s going on. Often times you have tutorials that are written in prose with some code examples. It’s not the most riveting prose exactly. So we’ve invented this new format which is really a walk-through where the code itself tells the story. Our documentation is our marketing. There’s a bunch of pages on our site around products and use cases and things like that. Those are more for the non-technical user. But for the developer, what our product can do is very accurately depicted in the docs. That is the most truthful description of what the product does. Docs are the marketing materials to developers so we try to do the best job we can and I think we innovated on that in 2008 and we just innovated again with the tutorials. We keep pushing the state of how we think the developer can learn from this documentation.
On selling to developers…
I was always emphatic to call our developers our customers. Developers are the ones who pay us, developers are the ones who adopt our product, and developers are the ones for whom we build the go-to-market. I think the danger is when you somehow create a distinction between the people who pay you and those who you consider your customers. I’ve been emphatic the other way, which is that we always have to consider developers to be our customers. There are many companies who court developers where they aren’t the ultimate customers and those are the products and services devs should be wary of. If you are not the customer, then developer access to whatever you are doing is probably considered strategic, and if it’s strategic, strategies can change. But one thing that rarely changes is revenue. Revenue always seems to matter. If you are building on top of platforms where your end of that platform is considered strategic, well, I would be cautious.
You want to make sure there is no hidden agenda in the engagement you have with the people who are using your product. If we treat developers poorly or as a means to an end then we go out of business. So we’re very transparent in terms of the product and economic relationship we want to have with our customers. And that’s critical for developers, because you are building on top of us and so your app is only as powerful as the foundations that it’s built upon. That’s why it’s important that those foundations are rock-solid.
On interesting lessons learned in building and selling to developers…
When you’re an API company, developers come to rely on your bugs. I just talked to one of our early engineers and he was telling me a story about how on the first week on the job, he fixed a bug and customers suddenly were returning the wrong thing. He checked in this bug fix, pushed into production and had angry customers. Customers actually coded to account for our bug that had been in there for years. The lesson is it’s excruciatingly difficult to deprecate functionality from an API, even if that functionality is a bug. In fact there is only one instance where we deprecated something and it took us about three years to do it safely.
It makes sense: you have all these customers who have written apps, put them in production, and they are probably thinking about other things. Their code was written 2 years ago; the last time an engineer looked at it was ages ago. And so you are actually creating a big burden for your customers when you say, “look, you have to re-open that code and make a change.” Other than on one instance, we’ve supported every feature we have ever shipped. It’s really tough and that makes the architecture and the design cycle of what you are building even more important. You can’t change it later without a whole lot of pain.
You listen to what Eric Ries was saying about MVP’s and iteration and all that, and it sounds really tempting, but as an API company you don’t exactly have that same luxury as a SaaS company or a consumer app. Every change you make is essentially a permanent one. Plus designing your organization around coping with that is also very important.
It all relates to treating developers well. When developers say you have a good reputation with them, a big part of that is that you never pull the rug out from under them, never change an API, that your API is rock solid, that it always returns it 400 milliseconds, etc.
On Signal, Twilio’s annual developer conference…
This is the fifth conference we’ve put on. The first three were called TwilioCon and last year was the inaugural Signal. This is a developer conference for people interested in moving web communications forward. We try to mix in both Twilio and non-Twilio content. There are people talking about how to build better apps in a wide variety of ways, or new tools to use, whether it’s different types of data sources or different kinds of profiling or debugging tools. It’s helpful to people who want to get better at their craft. Then there are a lot of sessions specific to communications, talks like how is software going to improve communications?
We think it’s a great event for developers who, first and foremost, invest in themselves and their craft. There are a lot of people there who do that. There are a lot of people there just to see the work of other developers and learn from them and get better at what they do. If you are building an app on Twilio, or you have built or are interested in building one, there is a lot there. If you look at our API, there are a number of things you can do at Twilio is expanding. I think a lot of developers may have used only one of our products and they are there and I think the conference is actually a better way to understand the wide variety of things that Twilio does, whether it’s SMS, voice, in app audio, video, IP messaging. We’ve got a lot of different products now and for whatever reason you adopted Twilio in the first place for a project, because, presumably, you wanted the apps to communicate with the world, communicate with your users. So, there are more expanding, ever more interesting ways in which you can do that. Signal is a place to engage with the folks who build those APIs and with those who use them.
P.S. I think we really figured something out last year which is our after-party is called $Bash and it is pretty awesome.
