Jeff Lawson on the Past, Present and Future of Programmable Communications

An interview with Jeff Lawson, Co-founder and CEO of Twilio.

After going to Twilio Signal event in London in September, I was asked by Twilio’s analyst relations about the event. I shared my thoughts in a lengthy article already, so it was easy to send out a link.

I did one more thing.

I decided to ask her if I can interview Jeff Lawson in person the next time I’ll be in San Francisco (which happened to be the following month during Kranky Geek). My expectation was to be ignored, or to just be declined.

But when she came back with an approval… I was clueless as to how to proceed.

We ended up deciding together on a recorded video interview.I was given free reign as to what questions to ask, with the request to share them if possible before the interview. No restrictions were placed. I reached out to a few friends asking for their thoughts of good questions, added a few of mine and prepared for the interview.

Jeff gave me his full attention for the better part of an hour. I ended up using everything we recorded - not removing any of the answers.

The result? A longish interview of around 37 minutes. I’ve added the transcript below the interview as well, if you’re more of a textual person.

https://youtu.be/3aTTOg-W4t8

I’d like to thank Jeff and the team at Twilio that made this one happen.

Transcript

Tsahi Levent-Levi: Good morning, Jeff.

Jeff Lawson: Good morning.

Tsahi: Okay. I'd like to start with something, a question that I was very interested in. You have two kids, right?

Jeff: Yeah.

Tsahi: Are they young?

Jeff: Yeah.

Tsahi: How do you explain to them what you do every day?

Jeff: That's a great question. It's hard to explain to a young kid what Twilio is, but here's what I've found is they use their phones ... They don't use their phones. They steal our phones, but the only thing we really let them do is communicate. If you think about it, that's the very first thing that a kid wants to do. Call Grandma, and I'll FaceTime Grandma from the phone. I explain that Twilio ... Twilio is a technology. We let everybody who wants to be able to build things that communicate, we let them do that.

Tsahi: Okay. So that's CPaaS in a way, right?

Jeff: CPaaS. Yeah. In an essence, we let companies call Grandma.

Tsahi: Yes. Okay. Letting companies call Grandma. I'll tell that to my daughter.

Jeff: If Grandma is your customer and you need to engage with her.

Tsahi: Yes. When you started Twilio, like nine or 10 years ago, what was the original vision behind it? I guess it was slightly different than what it is today.

Jeff: It's actually pretty similar to what it is today, I have to say. We started Twilio because I'm a software developer. I've been a developer for 20 years, and I also started multiple companies prior to Twilio. At each company, a common thread arose. At every single one of those companies, first of all, we were using the power of software to build a customer experience that was better than anything in the industry that had come before us.

I had started a variety of companies. An academic content company for college students online, StubHub, the online ticket exchange for secondhand tickets, and a brick and mortar retailer, of all things. The common thread among all of these was we were using software to build a great customer experience. We were using software to build amazing web applications, to represent the business, to enable us to touch customers. StubHub is the whole ability just to be able to connect folks together to buy and sell tickets. Software was key to that, and the key of software is agility. The ability to constantly iterate, constantly listen to your customers, put something out there in the world that you think solves a problem for them, get feedback and iterate. Sprint over sprint, every couple of weeks, you're putting out something better, learning from your customers. That's the super power of software. In every one of those companies, I had another problem. At some point or another, I had always needed to reach out and communicate with my customers. Just makes sense. Every time it happened, I said, "Well, that's neat, but I'm a software developer. What do I know about making the phone ring?" That's like magic. I have no idea how that works.

So I'd go to the industry, and I'd say, "How are we supposed to build this idea that we have?" We want to integrate with these systems. I have this idea for how I want to touch our customers, and the industry would say, "Oh, okay. Yeah, yeah. We think we can help you with that. First thing, let's pull a bunch of copper wires from the carrier to your data center. Then we're going to rack up a bunch of carrier gear in your data center, and then, let's see. None of this was designed to do this idea you have, so we're going to bring in this professional services army. They need to come integrate it, and they're going to beat up all that equipment and get it to work and do exactly what you want. That will take about two million bucks, and it will take a couple of years to build. Sign here."

Every time, I remember thinking, "Huh. First of all, millions of dollars for this one part of my customer experience? That's a lot of money. I don't think I have that, but if it's not for the money, though, what's much more important? The time." Think about it. Two years before I get version one in front of my customers, before I get that prototype in front of my customers? Get any feedback whatsoever? That's insane. To software people, to spend two years before you get anything in front of a customer? That's crazy.

After having that experience at three companies in a row over the course of 10 years, I realized, "Huh. The ethos of communications is diametrically opposed to the ethos of software." It kind of makes sense. If I was shooting satellites into the air and laying down millions of miles of wire everywhere, I would operate slowly and methodically, and that's what I would do. That's what the industry of communications industry has done for 100 years. The thing is, how you and I, how individuals, how companies, get value out of these networks has shifted. It's no longer about the physical networks. It's about the software that's running that defines how we get value out of that network, what we can do, what's possible. That's all about software.

So we started Twilio in 2008 to solve the problem of bringing communications out of its legacy in hardware and physical networks and into its future, which is software. Now, we do that with a powerful set of APIs that run in the cloud that let any software developer be able to start building that future.

Tsahi: I'd say you succeeded in that.

Jeff: Oh, well, thank you. We feel like we've just started.

Tsahi: Okay. In all of these years, what would be one of the most surprising use cases that you can say that you've seen or come in front was like, "Whoa. That's cool. That's neat"?

Jeff: There's so many. We build the platform. We never know what people are going to build. In fact, one of the little Easter eggs in Twilio's history is that in every press release when we launch a new product, my quote ends with the words, "We can't wait to see what you build." Every press release, year after year after year, that was always the line. Nobody ever caught on.

There's so many use cases. There's the obvious ones. The whole on demand economy. Things like Uber and Lyft and Airbnb, where Twilio is not only notifying you that your car is arriving, but also connecting drivers and riders together. That whole idea that I would use the internet and my phone to get a stranger to pull a car up and get in the car, I was always told to not get in stranger's cars. But now, that's what we do every day, and use cases around how communications, and Twilio has made that safe, made that convenient, made that easy. I never would have thought of those the day we launched Twilio, because really, mobile phones, their current incarnation, smart phones, were just getting started, and that whole idea of it; the applications of it were still completely unknown.

But then there's the crazy use cases that I still can't imagine. One of my favorite crazy use cases is there's some researchers in the United States who study the migratory habits of bears.

Tsahi: Okay.

Jeff: Right? It turns out that if you study the migratory habits of bears, you spend your days in a helicopter flying around looking for bears with binoculars. When you see a bear, you land your helicopter. You shoot the bear with a tranquilizer, then you climb up on the bear. You hope it's tranquilized, and you put a collar on its neck that's going to track its location. Then you run away very quickly, hopefully before the bear wakes up. Then a year later, you're circling in your helicopter. You spot the bear again. You land. You shoot it with a tranquilizer again. You climb up on the bear again, hoping it's actually tranquilized. You pull the data card out of the collar. You put a new one in, and you run away before the bear wakes up.

They're like, "There's got to be a better way. We would love to stop shooting bears with tranquilizers." So they built a collar that had a 2G radio in it that collects all the data. When the bear wanders into an area with some cell service ... They don't exactly walk around in shopping malls. When it wanders in, it picks up coverage, and it texts all that data off the collar to a receptor they built on Twilio. That was, I thought, such a cool use case, because they're using this technology, 2G radios. They're low power. They've got maximum range, and it is texting the data off to build an app. You're like, "Who would have thought of this?" We call this the internet of bears. I'm like, this is a use case I never would have imagined that there were people whose days were spent doing this. They found a use case for Twilio to solve this problem.

Here’s another crazy use case I love. There's a researcher in the UK who built an app that allows you to call a phone number, and based on taking a recording of your voice, can detect with a very high degree of accuracy whether you're likely to be predisposed to Parkinson's disease.

Tsahi: I should use that one.

Jeff: You've done it?

Tsahi: No, but do you have the number?

Jeff: It's a medical trial. They ran this trial. They found it to be an incredibly accurate way of assessing whether or not you are likely to develop Parkinson's just by calling a phone number on Twilio and recording your voice for about 30 seconds. What's amazing, as a researcher, he said trials like this would have usually cost millions of dollars to set up and run, because you would have needed all this sort of expertise and specialization. The doctor and his staff built it in a couple of weeks using Twilio for less than $1,000. They ran the whole trial, so it's amazing.

Tsahi: Yes it is. I want to talk to you a little bit about the market itself and the different players in that market. The main ones that you would have thought that you would have lead or be part of that are the actual Telcos, the carriers, the ones that offer the phone service to the consumers. When you look at what they are doing in CPaaS and in APIs, they have services, but none of them are quite as successful as the other vendors out there. Why do you think that is?

Jeff: Well, I love the carriers. They have a very valuable product in that they are building out all the infrastructure that we all use every day to communicate in every way we can. I would say, though, that the carriers are not well situated to solve these software problems. Historically, carriers have not been software organizations. They've been very effective at ground operations, at getting infrastructure out in the field, repairing it, installing it. They're very good at sales and marketing and servicing customers, but they historically have not been great software organizations, and that's why I think a new type of company has been needed to come and solve this problem. A company that is a software company.

Twilio, half of our company is our software R&D group. That's a different ethos. Building a world class software engineering organization, one that can ship and be agile and build resiliency with agility, which is what we call that process of having a high velocity of innovation but also achieving five nines of availability and things like that. That is a hard software problem, and so it takes a different kind of company to solve that.

Tsahi: Okay. What about all of the IaaS vendors? AWS, Google Cloud Platform, Microsoft Azure? They offer infrastructure. They give you compute and storage and databases today, and it's like shouldn't they also do communications? It's the next step. Why do you think that they aren't there yet or aren't there today?

Jeff: I think two things. First is, these companies have been primarily focused in the communications for online consumers. A lot of them have a consumer play, whether it's Microsoft with Skype or Google with Hangouts and things like that. Then on the infrastructure side, I think they've gone to the things that they do particularly well on the infrastructure to build, which is to say it's compute and storage, the most common areas of software computation, which has been a huge meaty market to go after, which has meant that communications hasn't been the focus of theirs.

I think companies like Twilio, we focus on communications all day every day. That's what we wake up to do, and so I think we're uniquely situated to be able to build out great services that target exactly the use cases of communications while the other platforms have been really focused more on compute and storage and the key areas of general purpose computation.

Tsahi: Okay. Another trend that I've seen in the last year or so is around UCaaS, Unified Communication as a Service. These companies that offer you desk phones, the video conferencing systems, the things that you need in order to run and operate your enterprise internally. Communication between people inside the enterprise. It seems that all or most of these vendors today start offering APIs. They bundle APIs on top of their service. When you go and talk to them, they usually say, "We've got APIs just like Twilio. When you use us, you don't need to pay for blah, blah, blah, whatever." It's like they compare themselves and position themselves as direct competitors to Twilio. Where do you see these two markets going? UCaaS and CPaaS. Where do they meet?

Jeff: Yeah. It's a very different thing. If you think about Unified Communications as a Service, you've got an application. When you build an application, you make all sorts of assumptions about how the world works. You have a domain. You've got models. You've got all the core components of unified communications. Then when you add APIs to it, which by the way, it makes a ton of sense. Every SaaS product has APIs. In fact, UCaaS has been a little late to that game, I actually believe. Most SaaS companies have had APIs for 10 years. But when you add APIs to a software application, those APIs bring with it all the assumptions that you made about that application. That's both good for some things ... If you want to extend the application in a certain way and you want APIs to do it, that's what those kinds of APIs are good for.

Twilio is designed from the ground up to be a set of APIs, to be ultimate flexibility. To not make all those assumptions about the one application that the end user is going to use it for, but rather to say these APIs are designed like building blocks to be put together in any way you see fit. That's why we can address a wide variety of use cases, whether it's two-factor authentication, identity verification, call centers, anonymous communications, notifications, alerts, anything you can imagine, you can build with Twilio. That's because we were created from the ground up for this recombination of these building blocks as opposed to taking something that's already built and fixed in place and then saying, "We're going to add APIs to it." It's just a different way of approaching the API problem. Both of them have merits, but I like our approach, because it gives us the ultimate flexibility to really enter any of these use cases in a really wide breadth of things.

Tsahi: Do you see a unified communication platform as a service; A vendor that does such a service deciding not to build the whole communication infrastructure on its own, but instead using someone like Twilio, a communication platform as a service, to build on top what it is that he is doing?

Jeff: Yeah. I believe that companies whose primary business is communications can and definitely should and would get competitive advantage by using a platform like Twilio to build upon. The reason why is this. It used to be when those UC companies started, their core competency was making the phone ring. Then they'd add some software functionality on top of it, sure, but the vast majority of what they worried about was how do I make the phone ring? The problem is Twilio has democratized that ability.

Every developer ... Every mobile developer, every web developer ... now has the ability to make the phone ring in 100 countries around the world where we have phone numbers and touch every phone on the planet ... Mobile, landline, et cetera ... with an API that is reliable, that is scalable, that is global. Now, you've got developers out there who get to focus solely on customer experience, features, integration, UX, mobile. Build the things customers really care about and bring this core competency of focusing on user experience that software developers do so well. A one or two developer team can actually create a customer experience that is better than some large company that is focused purely on Unified Communications as a Service.

The existing UCaaS vendors, they would be wise to build on top of the same platform that any developer in the world can come and start to compete with them on. If they don't, those independent software developers, they can actually start and build companies that are really compelling competitors, because they don't have to focus on the low level bits. They're focused on the things customers really care about, which is features, functionality, and the user experience that matters.

We have seen this play out, for example, in the call center market. We've seen ... At our first conference back in 2011, Tiago was the founder of the company TalkDesk. One developer. Do you know Tiago?

Tsahi: Yes.

Jeff: Back in 2011, Tiago was the founder of TalkDesk. Single developer. He was a web developer. He knew web development really well and focused on building a product that he thought would be really compelling. Because of Twilio, he didn't have to worry about any of the underlying infrastructure. Now, TalkDesk is hundreds of employees, has raised a lot of venture capital, has Fortune 1000 companies running call centers on them all because he was able to focus on the things customers really care about, is the features and functionality of the application. He did not have to worry about making the phone ring. That's a really powerful competitive dynamic, as new players come in fundamentally uplevelled, because they're building on platforms.

Tsahi: When I look at the feature set that you have at Twilio, the different types of functions that you offer, at the end of the day, that is something that is always commented when people talk about Twilio and they're trying to attack Twilio as a company. They say, "All of the money comes at the end of the day from SMS and voice. That's what they do, and at the end of the day, that's too competitive as a market today." If you actually look and search all of the CPaaS vendors, all of the direct competitors that you have, almost all of them have the same type of characteristics. They make most of their revenue today from SMS and voice and a lot less from the IP based services that they have, from the new things that come out. How do you as the leader in the CPaaS space deal with that and meet that challenge?

Jeff: I think there's two things. First of all, most mature products for any company are generally going to be the largest contributors of revenue. Especially with developer products. We have a very long commitment to developers, and that takes a little longer than other products to adopt, because you launch a product, then developers have to see that product, understand it, and build their product, and then bring their product to market. You've got a little bit of an extra delay as a developer-focused company before products become commercially viable.

That is a long commitment, and that, quite frankly, is why a lot of companies don't have the stomach to serve developers, because it's a long commitment to developers to get those products to grow and be large. But we have that commitment. The way we look at developer products is that they have a slower start but then a fantastic ramp up capability. So I wouldn't worry about the short term. We're planning for the long term. In the long term, it is blatantly obvious that the software APIs and software communications are going to win. We're there with all the products that developers need to build it. We see developers building amazing things using our software products, our video SDKs, Twilio Clients for Voice Over IP, the rest of our software products.

The other thing I'll point out is that our software products often drive usage and adoption of our voice and SMS products as well. They don't exist in a vacuum. When a customer builds a call center using Twilio's TaskRouter product, which is a globally scalable cloud-based ACD ... When you use TaskRouter to build a call center, guess what? It drives more voice revenue. When you use Twilio Client as the basis of your call center, it drives more PSTN revenue, generally, as well, because you've got an inbound phone number.

It's interesting is that these new technologies, software-based communications, are actual drivers of competitive advantage for our customers who adopt them, whereas if you think about the customers of ours who've adopted Twilio Client to allow any computer with a web browser to be able to now become a call center by just plugging in a headset and using our Twilio Client product that's powered by WebRTC, that has leveled the playing field because you no longer have to manufacture or sell hardware phones or PBXs in a closet. These new software technologies have been huge drivers of a new set of players to arise in this industry who previously wouldn't have been able to do it. That's creating a new market dynamic here of new players entering the field and new products entering the field that wouldn't have existed 10 years ago.

That's really exciting, and it's creating a huge market shift, but it also draws more usage of the PSTN right along with it. The same thing you can say for our Twilio Chat product. The same thing you can say for a number of our products, Twilio Studio. So all of these products together, you usually don't use them in a vacuum. You use them together with other products. That's part of the nature of APIs. But having them all together and being able to plug them in together to do these interesting things is fundamentally changing the landscape of the companies and the products that are out there that are really pushing the ball forward on communications.

Tsahi: I think I saw the first thing that you said when I worked at RADVISION years ago, but in the opposite sense. At RADVISION, you had two business units. One of them was a technology business unit. We sold SDKs to others to build their own products. The second business unit dealt with selling videoconferencing equipment. Whenever there was a downturn in the company because of the market, the CEO came out and said, "We have this business unit that sells videoconferencing. It's now slow because of the market. Then the TBU, the technology business unit, we're still going strong because we see that this will go upstream three years from now when developers actually launch it."

There, the business model was flipped. We usually licensed the software in advance so developers had to invest when they started, and not when they saw the revenue. What you are saying is that today, in order to be in the developer space, you don't make the money up front from developers that build stuff in the future. You wait and you grow with them. That waiting for that growth is what makes a company big at the end, is being patient.

Jeff: Exactly right. It's the combination of our usage-based revenue model that tightly aligns us with our customer's success. This is key. When we think about what is the driver of innovation, what makes developers be successful in building their next idea, it is experimentation. Experimentation is the prerequisite to innovation. Everything that we do is about lowering the barriers to a developer getting started and running as many experiments as they can for an idea that they want to try out. That's why we have such a low upfront. You get started ... Every developer who has used Twilio started by spending their first penny to make that first phone call, send that first text message, fire up that first video session.

You never know which one of these ideas that developers are building is going to be the next great big idea. Our job is to make it so developers can try as many of these ideas and run as many experiments as they can until they find product market fit with the thing that they're building. That's why it's a long commitment to developers, because you need to give them the runway. You need to have that patience, but you also need to have that attitude that it's not about, "Hey, a developer came to our door. I'm here to get all the money from you today." You're like, "No. We'll do well if you do well. I'm just here to make sure you do well. I'm here to do everything I can to make you successful in building your ideas." Ultimately, that's how I'm going to be successful, but it's a long commitment.

We like to say, though, it is a compounding interest business, essentially. You invest in developers, and they build. With the usage-based model, as they grow, as they're successful, that, then, turns into our success. For us, that means customer success is the very first thing. It's the prerequisite to our own success. Everyone at Twilio is always focused on customer success first.

Tsahi: I've been to two Twilio SIGNAL events, both very interesting events. I really loved them. What I noticed that you know exactly what the product does. When there is a product launch, you play with it. You do it on stage. You use it. You're a developer yourself. How can you do that and still be a CEO of more than 900 employees?

Jeff: I think as an API developer-first company, I have to do that. That's how I can make sure that we're building the right things, and that's how I can make sure I'm close to our customers and I'm close to our products. I love playing around with the new Twilio products. I am the first person they give access to when we build stuff, or at least, I hope I am, because that's how I love playing around. I just dive in there. I read the docs. I started building stuff. That's really exciting.

Recently, I was building something for Halloween with my kids with some Arduinos. I love building internal things at Twilio. A few years ago, I built our goal-setting software that we were using at the time. I just dove in. They don't let me touch production code anymore, which is probably a good thing, but I just love being a developer. Even though I'm a CEO, I love continuing to invest in that part of my life. Obviously, I don't get to do it as much as I used to, but it would make me very sad if I had to stop. I've just arranged my schedule and arranged my life so that I always make sure I've got some time to stay current on new stuff, both inside Twilio and outside Twilio and build. I've always thought that just building, just having a project idea in mind and committing yourself to building it and picking even some new technologies you've never used before, that's a great way to keep learning and keep building and keeping your skills up.

Tsahi: I can easily relate to that. Talking about products and what is it you do, the last year it seems that you have somewhat shifted. If up until now, you could have said that when Twilio launches a new product or introduces a new product, that would be yet another building block that you can use to do some kind of communication. A new communication service that you couldn't build before. It seems that you've started moving upstream. There is the Engagement Cloud with Notify and Authy. Then there is even Twilio Studio that goes for me even one level above that. Why did you make that move? Why the shift?

Jeff: Well, we don't see it as a shift, because to us, it's always about having the right API for a developer to get the job done. As a platform, you start off with a set of building blocks that provide maximum flexibility, because you don't necessarily know what developers are going to want to build. As you learn from developers what are the most common things that they want to get done, but also what was really hard? What did they think would be easy to build and it turned out was very hard?

We view our job as making our customers successful. When we see the things that we can do to make their lives easier, help them get the job done faster or not have to reinvent the wheel because they're trying to figure out, "Hey, how do I figure out how to distribute calls?" and I see every other customer trying to figure that out, too, as they're building a call center, it becomes obvious. You say, "Wow. My job is to make my customer's life easier and make them more successful. Why don't I build a product that does that thing?" So you end up with Twilio TaskRouter, for example.

In the case of Studio, we view it as making the developer's job even easier and allowing more people to participate in the development and the maintenance of these applications they're building. Why? Because we saw developers build an application, and certain parts of it are really exciting, like how do I figure out the exact experience I want? How do I integrate all this stuff? Then parts of it are really boring and become a tax to the developer and to the whole organization, such as when folks are saying, "Hey." Product manager says, "Hey, can we update the text? We're going to run an A/B test. Can you try 50% on this and 50% on that? Can you change the SMS text? Can you change how the call center greets the people coming in?"

The developers don't see that as exciting. They see that as, "Oh, it's continual maintenance. It keeps pulling story points off of me every week, because I've got to keep maintaining the thing." We said, "Isn't there a way that we can allow the developer to do the really important parts, the parts that are about integrating systems and things like that, and then take the other parts that are a little more standard and make it so not only the developer doesn't have to write it ... They can just drag and drop and build it easily ... but they can also hand some of that off to other people in the organization." Maybe the marketing people have ideas about how they want the content to work. Maybe the ops people want to change how the IVR call flow works. There's all sorts of different people who are invested in these communications applications, because customer engagement touches so many parts of the company.

If we can offload a bunch of that work from the developer, that ultimately will accelerate our customer's roadmap and make them more successful. Again, you go back. That's our goal. By the way, when we make our customer successful, that makes us successful, so we're all aligned in this. Studio is a great way to do that. So we keep listening to customers, hearing the things that they love about the API approach, the flexibility it gives them, the fact that they can now build things that they were never able to do in the past because pre-built software applications weren't flexible enough. But then we say, "Great. How do I make it so that you can get that flexibility faster and easier than ever before?" You do that by listening to your customers and solving the most common pain points.

Tsahi: I really love Studio. I've played with it. It's a great tool. Really.

Jeff: Awesome.

Tsahi: How do you make the definition of it? Going ... Building a UI tool, an IDE that can mix and match stuff and do this logic is never easy. I've used tools before that are similar. Some of them are good. Most of them not the good. How did you nail that experience in a way that, at least for me, was just point on?

Jeff: I think there have been fits and starts in the history of computation around visual designing of programming. Sometimes they work. Sometimes they don't. To us, there were two things that were involved in that. Number one is working with a lot of customers and a lot of users. We actually started with paper and sticky notes and starting to design with them how they would want to design something like an IVR or an SMS bot or a chat bot, things like that. We actually did it with sticky notes before we wrote a single line of code. To us, that was the equivalent of for APIs, it's writing the API docs first, putting them in front of a user and saying, "Hey, is this the API you would want?" We do that before we build the product. We did the same. We applied the same logic to building a user interface for drag and drop development.

Then the second thing was I think we constrained it down a bit to say, "This isn't about general purpose computation," because you get in all sorts of hairy things. We're focused on the customer engagement. If we scope it down and we say, "We want to make the very best visual designer for Twilio for customer engagement. What are the things it should encompass?" I think that the key of building both power and simplicity is really understanding your domain that your customers are operating in and then designing the perfect thing for that domain.

I think that obviously, we're just at the very beginning. We launched it just over a month ago, and so we're continuing to learn from customers and get that feedback, but that's our approach that I think has helped us to build something that customers find both powerful but also easy to adopt and easy to use. That comes from the same approach we've used to design APIs that I think customers would articulate in the same way. They're powerful and easy to use.

Tsahi: What's the feedback that you get about the engagement cloud? It's out there for what, half a year now?

Jeff: Mm-hmm (affirmative). Look, when we talk to customers and we take a step back and we say, "What is Twilio all about? Why is Twilio important to you, ING Bank? Why is Twilio important to you, Morgan Stanley bank?" Some of these very large organizations, so obviously have a lot of options and a lot of legacy systems they could have kept using. The answer we get is, first of all, flexibility. With Twilio, we get this unprecedented flexibility.

When you think about the importance of customer engagement to a company, almost nothing is more important. When I talk to a CEO of a bank, and you ask them, "What's important?" they are so concerned about, "How can I maintain my relationship with my customer?" That's the biggest fear that C-level executives have. That is done with customer engagement. How do you keep up? If you think about the problem space here, it's insane.

As consumers, the technology that we use has advanced incredibly rapidly in the last five to 10 years. We've got a wide variety of new applications that we use. We use video. I use video almost daily. I would have thought that was crazy 10 years ago. I would have thought that was stupid, and now here we are. We use video on a daily basis. We've got great chat applications. We've got apps in our chat and chat in our apps. It's amazing. Yet, for companies to communicate to their customers, it is incredibly broken. Why? Because companies can't keep up with the pace at which our expectations are changing for how communications is going to work and how great of an experience it's going to be.

We're still stuck in the days where you essentially call an IVR of a company and they don't know who you are. You enter your 40-digit account number and then you talk to an agent. They're still asking your name five times. You're like, if I had that experience with a friend, if I called my friend and they asked me my name five times during the call, I would think there was something medically wrong with them. Yet when you call a company, that's the experience you expect. Nothing is more broken about communications than how companies talk to their customers. We want to fix that.

When you talk to executives at companies and you say, "What keeps you up at night?" It's, "Yeah. I'm worried about losing my connection to my customer. Being disintermediated by all these other technologies that are coming out. I need to keep the connection in order to stay top of mind and stay relevant to my customer." When I think about how that works, it's like, "Well, you've got rapidly proliferating ways in which you need to reach your customer."

10, 15 years ago, talking to your customer generally meant you had a phone number and customers could call it. Now, you've got not just phone calls. You've got text messaging, you've got chat, you've got mobile apps with push notifications. You've got WeChat, WhatsApp, Facebook Messenger. You've got so many different ... Now Alexa, Google Home, personal assistants. You have so many ways and very finite development resources to keep up with this changing world. By the way, it's not just the ways in which you need to communicate that is proliferating. Think about all the departments in a company that need to actually keep up. You've got sales, marketing, customer support, onboarding, product teams. Every part of the company is trying to keep up with every part of this changing technology landscape. It is an unsolvable problem for most companies.

That's what the engagement cloud is here to sell. We want to provide one system that allows companies to keep building, keep iterating, but to reduce the barriers, reduce the time to do that and give one tool to all these different teams who need to touch customers, to be able to keep up with this rapidly changing landscape and constantly iterating on those customer experiences with easy to use tools and infrastructure that they don't have to worry about scaling. They don't have to worry about reliability. They don't have to worry about onboarding new platforms. We're going to do that for them as the world is changing. They get all that stuff from us, and so they focus on, "Okay, what's my special sauce? What's the thing that makes my brand and my company engaging to my customer?" I'm going to focus on that last bit, and we're going to iterate on that constantly, and I'm going to empower all these different teams inside the company to be able to have that at their fingertips. That's what the engagement cloud vision is all about.

Tsahi: Thank you for your time, Jeff.

Jeff: Thank you, Tsahi.

Tsahi: I thoroughly enjoyed it.