Inside Twilio’s Journey From a Single Voice API to a Multi-Channel Communications Giant, with former VP of Product Patrick Malatack

If you’ve ever booked an Airbnb and texted your host, received an email from Netflix about the latest season of your favorite show, or called a real estate agent through Trulia, then you’ve experienced the power of Twilio firsthand.

Founded in 2008, Twilio has built and scaled its communications empire – now worth nearly $50 billion – by making it drop-dead simple for developers to add communications to their apps. Today Twilio’s communication APIs have powered more than 795 billion interactions across voice, text, chat, and more and its platform boasts more than 8 million developers.

But, when Patrick Matalack, Twilio’s longtime VP of Product, joined in 2011, the startup offered one communication channel – their voice API – and had just put their second into beta. “A lot of people don't know that Twilio started in the voice space,” he tells us. During his first week, Patrick would become responsible for building out their second channel, Twilio’s SMS API.

Over the next seven years, Patrick helped grow Twilio from a single voice API into one of the world’s leading multi-channel communications platforms. His strategy? Focusing on global coverage first, then channel breadth. “Until 2014, we were focused on expanding our footprint [for SMS and voice], getting coverage in every area code and in every part of the planet first.”

Courier’s Founder and CEO Troy Goode sat down with Patrick for a wide-ranging chat on Twilio’s product evolution. Patrick reflects on the societal shifts that fueled Twilio’s early growth, the challenges and opportunities of scaling globally, and why there’s still plenty of greenfield left when it comes to multi-channel customer communications.

If you enjoy the discussion, check out more episodes of Courier Live. You can subscribe on YouTube, follow us on Twitch, or tune in on Twitter every Wednesday. Below, you’ll find a lightly edited transcript of the conversation. 

Transcript

Troy: Hey internet friends, I’m Troy Goode. I’m the founder and CEO of Courier. Today I'm joined by Pat Malatack. Pat led our seed round as a partner over at Matrix Partners and was previously the VP of Product at Twilio. Thanks for joining us, Pat.

Patrick (Pat): Super excited to be here and chat about the communications landscape and how it's changed over time.

Troy: First I have to say — and you've heard me say this before — the first four days of Courier's existence were entirely mine and then, from the fifth day onward, I got to share the spotlight with you. We got connected very early on. Pre-product, pre-team, pre-customers, standing shoulder to shoulder at the white board, designing APIs and really building Courier up from the beginning. It was a great way to start given your background and your experience and helped us accelerate really quickly. So first of all, thank you for that.

I'm hoping there are other founders out there working in the communication space or who have communication requirements and that they'll be interested in hearing more about your time at Twilio, about joining something very early and seeing that evolve over time.

From power user to product leader

Pat: I can start by just telling you a little bit about just what that journey was like for me. Before I joined Twilio, I was at Microsoft as a product manager up in Seattle. Like a lot of developers out there, I'm a builder by nature, and I had come across Twilio. This was almost two years before I joined. I had an apartment building I was living in that had a buzzer, but you needed a Seattle area code, a 206 area code, to be able to integrate with the buzzer system. I don't know why that was the case, but that was the case back then. I had a cellphone and did not have an actual phone in my apartment, so I was trying to figure out, “How do I solve this problem?”

I started doing some research and I came across Twilio. At that time, Twllio was only a voice API. Jeff [Lawson], John [Wolthuis], and Evan [Cooke] had built it out to enable voice communications. When Jeff was at StubHub, he had really wanted to connect a courier who had a ticket with the buyer. He had tried to figure out, “How can I do this?” At the time, there wasn't a mechanism to do it, and that was the founding story for Twilio.

I built, first, just call-forwarding directly to my phone, so I could buzz people up to my apartment. Then I started, like most folks that start tinkering, playing around with a bunch of other things. I started assigning certain friends their own passcode, so they could show up in the building and I didn't need to buzz them up anymore. If I wasn't home, they could get into the building. I just went from there and really, really had always had a passion for building platform products. I was working on the SharePoint platform at Microsoft and really loved developer products, really loved APIs. That was sort of my first taste of Twilio, as a Microsoft employee just playing around and solving a simple problem.

Twilio’s webpage for its voice API (circa 2009)

Troy: That's probably one of the things Twilio has become best known for — being the first big developer-focused cloud platform. Just get your API key and get up and running. Work on side projects, hopefully work on something commercial, but building cool things was the focus.

Pat: It's interesting because I think this has been the journey now for a lot of developer products. But, really, Twilio was doing this first, and credit goes to Jeff, John, and Evan for having the insight that, if you give developers a tool, they will come up with really interesting ideas on how they can use that tool and do things that you'd never imagined.

I was, at the time, working on SharePoint, but I was also working on this task management thing at Microsoft. Next thing I know I was doing voice memos where you're calling a number and creating reminders. All these different ideas started coming out because it was like, “Wow, now all of a sudden, there's a set of things that enable access to a whole area that never used to be programmable.” A lot of new products now are following this exact same pattern, but Twilio was really the first to go out and do it.

Troy: So, it's 2010, 2011. Twilio is a couple years old and you're at Microsoft up in Seattle, at a big mature company working on a mature product, SharePoint. How did you end up working at Twilio? You've kicked the tires. You've enjoyed using the product. How does that convert into a product role?

Pat: I'd probably been using Twilio for maybe six months, something like that. I'd also been playing around with a product they had in beta at the time, which was the messaging product, Twilio SMS. I was just really excited about what you could do and, at the same time, I was planning at Microsoft for what has since become Office 365 and much of their cloud services. I was also looking at what Amazon was doing; my roommate worked at Amazon at the time. I had been in the middle of just embracing cloud computing overall and was excited about what could be built with Twilio.

So, I did what anybody would have done that was looking to change. My short thinking was, “I want to go someplace smaller.” I'd seen how a big company operates at Microsoft and Office was an unbelievably well run division of Microsoft, a well-oiled machine. I wanted more of what I learned later to be the chaos of the startup environment. I wanted something a little bit less structured.

I was basically looking around and applied for a few different companies. Facebook was the new hot place that everybody was joining. I also applied to Twilio, which is the place I was personally excited about, and I wanted to be down in the Bay Area. I just applied right on the website; I didn't know anyone. For folks who say, “Oh, you don't need a webpage,“ well, I applied directly on the website. They reached out a couple days later, I had a few different calls and flew down, and I immediately just clicked with the group that I met there. Honestly, three weeks after I first met the team, I moved from Seattle and was living in San Francisco. So, it was pretty quick.

“Surprise, you’re working on SMS!”

Troy: You've shared a story with me before that I'd love for you to share again. When you showed up at Twilio, things ended up being a little bit different from what you expected, right?

Pat: Yeah, this just speaks to the dynamic nature of a startup environment. They told me I was going to build out the Twilio marketplace, which was the role I was hired to do. I show up and, the next thing I know, it’s day one and they tell me I wasn’t going to be working on the marketplace and I was going to be working on Twilio SMS. The first week I was there, they're like, “Well, you're going to be working on SMS, but it's super chaotic. All the carriers hate us right now and it might get shut down.” So now I’m the PM for this product that might get shut down. That was the environment I walked into, coming from a very stable, large, publicly-traded company. That was my dramatic introduction to the startup life and the environment I was in for what ended up being the next seven years.

Troy: Tell me more — what did the team look like at Twilio? The core product was originally a voice product, and they were shipping the SMS product, either in beta or recently launched. What was the team like? The company was about two or three years old at this point, I think.

Pat: There were about 20, 30 folks at the company when I joined. I came in, really, as one of the early product hires. I think a lot of people probably don't know that Twilio started in the voice space. When I chatted with folks, it was like, “Ah, I thought Twilio started with SMS.“ It's like, “No, it actually started with voice.“ It was launched with Jeff Lawson rickrolling Michael Arrington from TechCrunch. That was the launch story.

The code that Jeff Lawson used to rickroll Michael Arrington

It was a pretty small team when I joined. The messaging team was a team of one engineer, and it was a shared responsibility for them. There was one person working on SMS at the time I joined. There were a number of evangelists, probably, at that point in time, three or four developer evangelists. Maybe one or two other folks on the marketing side. There were one or two people in sales. Pretty much everyone else was an engineer building the product, writing code. I remember showing up and, at the time, the CEO Jeff was still checking in code. I was like, “Huh. I wanted an environment that was smaller, but the CEO is actively checking in code.” This was very different from how things worked under Steve Ballmer at Microsoft. He wasn't checking in any code there.

Introducing programmable messaging to a voice world

Troy: You mentioned something that's absolutely true, which is most people, especially a few years ago, thought of Twilio as primarily an SMS company. They would be surprised that voice came first. Today, they've obviously got a portfolio of different channels that they support. Just looking at the funding history for the first few years at Twilio, it looks like something must have been working with voice. They were able to raise a few rounds of capital quite quickly. What led to the initiative to add messaging? To add SMS as an additional product?

Pat: You have to remember that, way back when Twilio was founded, the iPhone did not exist, which is crazy. What was the world prior to smartphones, right? But that was the reality. When you  think about how you were interacting with companies, you would interact with their website or you would interact via a customer support phone number, a phone line. These were the two primary channels at that point in time that businesses would use to communicate with their customers. So, it made a ton of sense to start there.

There were folks building a bunch of different things like IVRS [Interactive Voice Response Systems] being built on top of Twilio. Twilio had — which still exists today as part of TwiML [Twilio Markup Language] — the ability to build IVRS and applications on top of the phone network. That was the initial launch of Twilio and the original product that was there. It was definitely working, and it was doing well. They were able to fundraise, and it was a growing business.

But, at the same time, as the iPhone launched, the primary way in which you communicated with each other wasn't this T9 text input anymore, which only nerds like me were excited about, with their Motorola Razr flip phone. What happened is that text messaging just completely took off. Smartphones showed up, and they had these full QWERTY keyboards. What had happened was that the only way you were doing full messaging on your phone, prior to the smartphone, was with Blackberries, and that was primarily email.

So, basically, smartphones take off and text messaging subsequently takes off. Jeff, John, and Evan are sitting there with a ton of phone numbers thinking, “Hey, why can't we text on these phone numbers?“ That's a thing that should be programmable, just the same way that we're making voice programmable. That was really the impetus. The main thing that happened, and I think this has happened repeatedly throughout the history of communications, is that the way in which humans communicate with other humans fundamentally changed.

Twilio’s pitch for receiving and sending messages with its SMS API

What you saw was a shift in how we communicated with each other, from primarily over voice to a lot more people messaging each other. So then it seems logical that our application should be able to talk to us in the same way our friends talk to us. You have WhatsApp now, you have Slack. Yet we're all still calling each other and talking on voice.

It’s really that people change the bandwidth of their communications and make it more appropriate for the problem they're out there trying to communicate to someone else. Even for myself, when I'm spending time communicating with my family, it's usually over FaceTime. That's the right channel. It's richer, I'm able to see what's going on, I can see my nephews and nieces growing up. So, then, it’s like, “How do we expect the brands and the companies that we work with to communicate with us in a similar fashion?” I think it starts with how we communicate with one another, and it sort of evolves from there.

Troy: Yeah, that's a good point. Today, messaging to me is a much broader term than SMS. When you're thinking about programmable messaging, there were other chat platforms, for example, like AIM and MSN, and probably Yahoo Messenger was still around. But at the time, messaging really just meant SMS.

Pat: We talked a lot about whether we should be building things that integrate with those services. What we generally observed is that, as the technology changes, the landscape and the tools you use for communicating also change. And really what had happened is that the rise of the smartphone changed how people thought about what messaging was. It moved from only synchronous AIM-type chat into hybrid asynchronous modes, which is largely what you have now with WhatsApp where it’s asynchronous by default.

The AIMs of the world went down in popularity as the WhatsApps of the world went up, but that was all enabled by the fact that people now had a smartphone with a persistent connection to the internet. And this made constant push notifications possible.

I think a lot of people might have forgotten that Twitter was built over SMS. That was a thing. All the limitations in the number of characters in your Tweet was driven by GSM [Global Systems for Mobile Communications] networks and how they could do character encoding in an SMS world. And all that changed as the rise of the App Store evolved. If you think about Twilio as being founded before the iPhone, that was really what the environment looked like at that point in time.

Troy: Absolutely. I know that there are a couple of products in the Twilio portfolio that have some degree for push support, but I get the impression that it was never really a focus for Twilio. Where did push notifications fit into the messaging ecosystem?

Pat: There were a bunch of different players that were in the push space and so, back in 2011, there were players like Urban Airship that were really focused exclusively on push. Remember that the smartphone world had just started off then. Not everyone had a smartphone initially. More importantly, businesses didn't necessarily have mobile apps. There's still many businesses that don't have mobile apps. I don't have a PG&E mobile app, but I sure would like to know when they're going to shut off power in California, right?

Frankly, email and your phone number are your universal addressable identities, so that was where we focused. We really wanted to empower all businesses to be able to communicate directly with their customers. Over time, we did add push to the platform at Twilio through a product called Notify.

Expanding Twilio’s global footprint, then channels

Pat: When I joined, the Twilio SMS product was only available in the US. We didn't have short codes. We launched short codes shortly after I joined, which is now a pretty big product. A lot of people are familiar with short codes these days, but that all happened after I joined. We had tried to launch internationally. We launched first in the UK to try and figure out that market and we incrementally launched in a bunch of different countries around the world, but the product was a US-only product.

We felt there was a lot still to do to enable the product and enable our customers so they could operate anywhere in the world. When we looked at how many developers out there were using these products, we saw the same needs and we felt that we should focus on making sure we could serve our customers wherever they were operating. That was the focus for the company: we had a thing, it was working, and we wanted to make sure [our product] worked globally and fully solved our customers' needs. Developers who were born in the web era, they assumed, “When I launch my thing, it works everywhere in the world” That was just not how telecommunications operated.

Honestly, in those super early days, a lot of what we did was just trying to figure out: how do we scale this thing? How do we get it working as reliably everywhere else in the world, beyond the US? How do we enable these types of experiences so developers could deal with the telecommunications networks of the world as a single abstraction and a single API endpoint? That’s how we started: as a product that offered both SMS plus voice. Until about 2014, we were focused on expanding that footprint, getting coverage in every area code and in every part of the planet first.

Troy: That's a journey that still continues today, right? It's a huge, hairy, complex problem. You've got a company worth over $30 billion that's still working to get sufficient coverage in Africa, India, and other countries.

Pat: Yeah, that's a never-ending problem. Just getting high quality, reliable support everywhere on the globe is just an ongoing effort. And the team working on it is massive. It's a huge business now. Our focus early on was asking, “Can we get this product working for our customers?” Because developers want a single abstraction – they don't want to have to think about all the complexity in their app and write code at the same time.

When you pitched me on what you were looking to do with Courier, I saw the same pattern playing out. Rather than the complexity of the global telecommunications network, it was the complexity of all these new emerging ways in which customers are communicating with each other and companies now want to be able to communicate with their customers. Figuring out how you get the abstraction right so that you lift away a lot of that complexity is a big part of why I was excited in our early conversations.

Moving past walled gardens to a multi-channel approach

Troy: I think you tried to solve a similar problem with Twilio Notify. You had evolved from SMS and voice and started to integrate push and Notify might have had support for email as well. Can you remind me what Notify looked like and why was it being built?

Pat: Notify was going after a big part of this problem, which is that companies need to communicate to their customers in so many different channels. Our approach was, “That’s great. How do we plug all those different channels into the core platform?”

Customers needed the connectivity into all those different channels, but they also needed a different kind of abstraction. That was a lot of the inspiration around getting other platforms plugged into the Twilio platform and trying to enable that. But, even while we were doing that, tools like Slack were blowing up. The communication landscape is not a static environment. Communication is a constantly evolving thing, and making sure that you're continuing to build and integrate with those services, I think, is pretty cool.

A big part of what we were doing was trying to figure out the key building blocks. We felt that connectivity to the telecommunication network was a key building block. We launched Twilio Video in 2015. Video was one of the missing building blocks. Email was also missing, which Twilio was able to solve with the SendGrid acquisition. That’s the approach we took: what are the fundamental building blocks that developers will need to build any type of communication experience? And then there was a long bet on developers that they'll figure out new and innovative ways to use these technologies that we couldn't even envision ourselves.

Troy: Earlier, you were talking phone and email as universally addressable ways to contact a user, but, there's been a proliferation of new channels that tend to all be walled gardens now. Is that something Twilio thought about? For example, now you have Slack and Microsoft Teams. Conceptually, they’re work chat products, but they have completely different APIs and completely different protocols.

Pat: It’s super tricky. They all have their own addressing mechanisms, but many of them also have openly available APIs. They're not quite walled gardens. If I asked you what your push token on your phone was, you wouldn’t know. If I asked you what your Slack UID is, you probably don't know. The way that I've always thought about this is, essentially, you had these IDs that were a global addressing mechanism, which is what the phone network is and what the email addresses are. Then you have a set of siloed addressing mechanisms, despite the fact that there are available APIs. That just adds a ton of complexity to the process.

That change in how these platforms evolve has shifted the thinking around the right abstractions to build. That eliminates a lot of the complexity on these developers. They don’t need to keep track of every one of these different addressing mechanisms for all these different emerging platforms. The trickier part is that end users don't know their address in almost all of these situations. If you told me, “Hey, would you like for me to get in touch with you?“ It's like, “Well, yeah. Absolutely, but there's really only two identifiers I can give you that will help you get in touch with me.“ I still think that email and SMS remain, certainly in the business to customer realm, the least common denominator of communication. Everybody has it. It's something that you can count on and is available.

A lot of the things Courier's doing actually simplify that addressing challenge for developers out there, but I still think that's been one of the big barriers to a lot of these other platforms.

Navigating the complexity of user preferences

Troy: So, I think that leads to another question: if we've got these globally addressable channels like email and phone, why would we want to message people on other channels?

Pat: The use cases and the level of bandwidth of the communications matter. There are different use cases where I want different types of communication and a different level of urgency around it. If it's PG&E telling me that we've had a lot of fires in California lately, I want that very urgently. I want a voice call that interrupts my day and that tells me what's going on. In other instances, I might just want an email that’s passively in the background, saying, “Hey, your rates have changed.“ Don't call me and tell me that I've got a change in my rates.

The way I think about it is you need to modulate the relevant communication channel for the type of communication that you're sending to your end user and according to the preferences of those end users. An email versus SMS versus a bot that will communicate to me in Slack. The challenge has been that this is complex on both the user-side – what are your preferences and how do you want to be communicated to? – and on the business side. If you want to let me as an end user have a variety of preferences around my communications, there's a lot of work you need to do to build the appropriate infrastructure.

What ends up happening is that everybody's shared de-facto pattern is, “I'll just send you an email and I'll send you all the things.” It's because it's hard to do this. From my point of view, I don't think businesses want to upset their users. Businesses are not like, “You know what I love? When my users think everything I'm sending them is spam and they're annoyed with my brand.“ That is just not a thing that businesses want, but to do it correctly, to send the right notifications at the right time in the right channel, that itself is a very, very tricky task. These are really tricky problems to solve, and so a lot of companies just don't get around to doing it.

There's a lot of engineering that needs to go in to build that type of infrastructure. There's a ton of companies that have invested in these highly advanced teams that have built this [infrastructure], and you've shared Slack’s notification workflows a number of times. Slack put a lot of time and effort to get this right.

Slack's workflow for sending user notifications

Facebook has similarly invested in these things. That’s great if you're Facebook and Slack – what does every other business do? Who is helping all the other companies that want to give their users control and support for different channels but just don't have the time to invest in it?

Troy: I really liked the way you put it: that channel preference is going to vary by person but also by the content. As humans, we intuitively do this every day with our friends and colleagues. Within the last 24 hours, I'm pretty confident I've sent you both an SMS and an email for different purposes. Same person, but I was picking a channel just subconsciously. This message makes more sense to go to Pat over this channel, and this message makes more sense to go to Pat over an email. I'm sure that, in my head, there's some algorithm running to say, what's less likely to annoy my colleague? What's more likely to get a response? I do the same thing with my wife, with my co-workers, but businesses don't, right?

Pat: I think it's not because they don't want to. It's because it's hard to do this correctly. And that algorithm functions partly in knowing the preferences of the other person. Knowing that, for example, for my mom, I'd just give her a call because there's a lot of back and forth and not a lot of information exchanged when I'm texting my mother and she's just much more comfortable with a phone call. This is sort of negotiated within our human relationships.

Businesses need to understand what our preferences are and then use their knowledge of the type of content that they have – what's mission critical, what's not – to adapt to the right level of bandwidth for the type of content that they're trying to communicate. it's very tricky to do, and there's just not a good way to do this.

If you’re looking at the market, we've gotten a lot better at adding more and more channels in the last five years. There's just been this explosion of channels, but figuring out the right channel at the right time with the right set of preferences, is really, really, I think, still a fairly unsolved challenge, especially for these businesses that want to do the right thing. It's just hard.

The power of investing in user notifications

Troy: That brings me back to Slack. I don't know that Stuart Butterfield would agree with this, but I actually think notifications and their early investment in them is one of the big reasons why they launched off so quickly. I was a HipChat customer for years before Slack hit the scene, but I remember kicking the tires with Slack and finding it pretty comparable at launch. For me, the big difference was the notifications. They were one of the earliest ones to invest in multi-channel notifications, saying, “Hey, when something happens, we're not going to send it to you on multiple channels at the same time. We're going to figure out if we route it to mobile push, in app, or email. And we're going to apply some intelligence for that kind of “right channel, right time, right person” methodology.“

On Hacker News, one of the big complaints about HipChat at the time was that they felt like they were just getting spammed on notification channels, right? You'd get an “@” mention, and regardless of, if you're just sitting there staring at it, boom, you get an email, right? And so it just blew to your inbox.

Pat: It meant you just could use Slack. It allowed everyone to basically have the flexibility to have the right set of settings. I don't know the size of the team that built it out, that probably still runs all the notification preferences, but I'm sure it's not a trivial team there. Certainly, the teams that we were working with when I was at Twilio, teams like Uber, they had pretty decent-sized teams that owned making sure that the preferences were right, that you got a push notification at the right time or that you got a text message or that the driver was able to call you. Getting those experiences right was a big investment for these companies.

Troy: Last time, I checked it was about 10 over at Slack, which is par for the course for larger companies. I know of several companies that have significantly larger teams than that just focused on building notifications, but 10 is pretty common.

Troy: One of the things that I shared with you when we first met is the reason I’m building Courier is because I had needed it. I was previously CTO of another company and was building out a system where we needed Slack-esque notifications.

We had a collaboration element to the product and one of the things that we wanted to do was let users know when other users were trying to get hold of them without annoying them. We wanted to follow the standard Slack style: If the other user is online, show them an in-app notification and, if they’re not they have the mobile app, send them a mobile push notification and finally fall back to email if neither of those work. Sounds really simple. Turned out to not be as simple to implement as I thought.

One of the ways we got connected is I actually went over to Twilio to talk to some friends and said, “If anybody is going to have a solution here, it'll be you guys.“ And they pointed me to Twilio Notify. Earlier you were saying that finding the right abstraction level was the hard part, and that was the bit for me that didn't quite fit and why I ended up starting Courier.

Solving the abstraction layer for notifications

Troy: One of the things we haven't talked about yet that is quite complex – and one that wasn’t really addressed with other attempts at solving that abstraction layer – is the template side, the actual content and how you can build the content in a way that can be used across multiple channels. I'm curious: did that ever come up at Twilio? Did you look at addressing it?

Pat: It was not the thing we were primarily focused on. What we were focused on was getting access to all these other channels. And, so, development teams were basically building a bunch of the content authoring in-house and that was in their systems. As you and I were whiteboarding and talking through this in the super early days at Courier, one of the things that I really liked about Courier was just getting the right abstractions in place.

There's events that are generated by your applications. Those events may or may not result in a notification, right? With Courier, the notifications can be designed and authored by the designers, the PMs [product managers], the growth teams in your organization and then the way in which those get communicated is informed by the preferences of the end user. That’s a decoupling of the developer needing to know the end user preferences, while in every other version of this I’ve seen, the development teams were performing the notifications and were responsible for the preference management. That tight coupling of those two things, I think, is what had made these things far more complex.

One of the things I was excited about when we were first chatting was your notion of decoupling these two things. Let's allow preferences to be something the developer doesn't need to be aware of. They just need to know about what their event did. What is the relevant information from that event? Pass that along to Courier and then Courier will figure out where I should send it and how it should look – the decoupling of the actual results in the end user delivery. The canvas of that delivery was a core insight that you had that made me really excited about what you were building.

How Courier powers your notifications infrastructure

Troy: There’s a reason we ended up there. Let’s imagine a world where if we’re starting from SMS. SMS has kind of some of the simplest content expectations. It's quite constrained both in length and in terms of the richness of the content. I know there are upcoming protocols that are hoping to expand that, and we'll see when those happen, but when we start to look at other channels, all of a sudden, both the complexity of the content that you can create increases and the complexity of what it takes to represent that content. Email is kind of canonical. You can do all the things, right? But you're writing awful, awful HTML that's got to work across Outlook 2003 and Superhuman and Hotmail and Gmail. Most developers have felt that pain before.

When we think about apps like that Slack, each of them is now bringing their own unique spin on the answers to questions like: what's the content? How can we represent it? What are the constraints? WhatsApp famously has a ridiculous bureaucratic process to get the template approved, right? There’s really, really thin constraints on what you're allowed to do, and you're not allowed to do. Slack has their own bespoke DSL Block Kit that they're constantly evolving. Each one of these channels is now increasingly complex, whereas, if you were just doing SMS and voice, SMS is basically plain text.

Pat: Before, preferences had to be coupled with the application logic. What has happened now, with all these proliferating channels, is actually the templating is now coupled with the preferences which are coupled with the application logic. That's where I think it gets really, really hairy for developers. You can't unbundle templates or preferences. They need to be working together to actually simplify things for an end developer. Otherwise, even if you say, “well, we got all the channels that you need in place,” the challenge is you as a developer still need to know the rules or the constraints of that given channel.

It's a slippery slope, where now it's like, “Maybe I'll just build the channel integration myself.“ Right? You really need to have the templating, the formatting, the rendering, all of that encapsulated as part of a higher level abstraction.

Wrapping up

Troy: You mentioned earlier that Twilio acquired SendGrid early last year $3 billion. In some ways, this completed the portfolio of channels that Twilio supports and that was also not too long after Twilio had gone public. I feel like you kind of came full circle. You started at a big, tens of billions of dollars public company and joined a small startup and then ended up right back where you were before.

Pat: Yeah, after having gone on that amazing journey, seven years at Twilio, I was super excited to jump back into the smaller startup world. Shortly after I left Twilio, you and I got to chatting. This is obviously an area I’ve been super passionate about for a very long time.

Troy: Pat, it was awesome to spend some time going through your time at Twilio and the evolving communication landscape. Thanks for spending time with us today.

Pat: Absolutely, thank you for having me and super excited about Courier and the product that you've built. I really think it's the right abstraction for developers in the world of notifications and couldn't be more excited to be partnering with you on this journey.