While Twilio is the focus of this essay, this essay is not just about Twilio.

It could be about about ANY potentially disruptive company with brilliant founders, venture-scale ambitions, great products, a top-notch team, and traction to die for.

It could be about you.

Disclosure: I worked at Twilio as its first product marketer from 2010-2011. I don’t currently own any stock in the company.

Twilio is still a relatively young company. It has yet to turn a profit, and as it aims to become a sustainable business, it faces a handful of serious risks.

Based on my reading of the company’s recent 10-K annual report, Twilio’s management team is aware of many these. Here are the three biggest risks they’ve articulated:

1. Twilio’s revenue relies heavily on a small number of customers. According to Twilio’s 2016 10-K, its 10 largest customers are responsible for 30% of its total revenue. Its two biggest customers (Uber and WhatsApp) accounted for nearly 20% of Twilio’s 2016 revenue all by themselves. WhatsApp has no long term contract and could leave at any time, while Uber could substantially reduce its spending with no penalties.
2. The market may not “get it.” From Twilio’s 10-K: “The utilization of APIs by developers and organizations to build communications functionality into their applications is still relatively new, and developers and organizations may not recognize the need for, or benefits of, our products and platform.”
3. The company has minimal expertise selling to the enterprise. More from the 10-K: “Historically, we have relied on the adoption of our products by software developers through our self-service model for a significant majority of our revenue, and we currently generate only a small portion of our revenue from enterprise customers…We have limited experience selling to enterprises and only recently established an enterprise-focused sales force.”

However, my reading of that same filing suggests three risks the company did not include:

1. Twilio may not fully grasp the nature of the $53.5 billion opportunities in front of it.
2. It does not appear that the company has developed a compelling strategy to seize those opportunities.
3. The leadership may not be aware of the reasons for #1 and #2 or what to do about it.

And these three issues may be the biggest risks of all..

Later on in this essay, I’ll explain exactly where those $53.5 billion opportunities come from and present three potential paths Twilio could take to capitalize on them.

But for now, it’s important to understand how Twilio achieved its current position of strength in the first place, and why the go-to-market strategy and company culture that got it here may now be holding it back.

To understand Twilio’s focus on developers, you need to understand its origin story

In Twilio’s earliest days, multiple angel investors and VCs told Twilio’s founders that focusing on software developers would never lead to a venture-scale business. To make their case, Twilio’s skeptics pointed out that software developers have no control over budgets in the enterprise.

But Lawson, Cooke, and Wolthius were undeterred. They believed deeply that software developers held the keys to the future…and not just of telecom, but perhaps the whole world.

They charged ahead, eventually landing a $1M seed round from a group of angels (including Chris Sacca, Dave McClure, Mitch Kapor, and Manu Kumar) and one VC (Bessemer Venture Partners’ Byron Deeter).

Under Jeff’s leadership and the stewardship of Twilio’s first employee, Danielle Morrill (now CEO and co-founder of Mattermark), the company built the startup world’s most effective developer marketing program.

Specifically, Twilio hired a traveling team of developer evangelists, sponsored hackathons, published world-class documentation on the website, and offered in-depth coding tutorials on the blog.

The developer-focused strategy paid off big time when Jared Hecht and Steve Martocci used Twilio’s SMS API to prototype a group messaging app during the TechCrunch Disrupt NY hackathon that Twilio sponsored in 2010.

The app was called GroupMe, which went on to raise $11.45 million and become Twilio’s single largest customer at the time–by FAR.

And though GroupMe eventually sold to Skype for north of $30M, moved off of Twilio, and petered out into irrelevance, it made for one hell of an appealing story to Twilio’s target market of entrepreneurial software developers.

The strategy paid off again when Tiago Paiva and Cristina Fonesca finalized a prototype of cloud-based call center software they called TalkDesk during the hackathon at Twilio’s first developer conference.

TalkDesk won a cash prize at the conference, quickly raised a $450,000 angel round from 500 Startups, and went on to become a hyper-growth success story.

In the nine years since more than 20 angel investors and VCs told Twilio’s founders that focusing on developers was a dead end, the company acquired over 28,000 paying customers, raised $233.7 million in venture capital, and launched a nearly $2 billion IPO on the NYSE.

And as an added bonus, Twilio’s IPO happened in 2016–a year that saw one of tech’s billion-dollar “unicorns” lose half its value, another get acquired for less than it raised, and a third turn out to be a flea-infested dog in unicorn’s clothing.

The doubters were wrong: You COULD build a venture-scale business focused on software developers, and Jeff Lawson, John Wolthius, and Evan Cooke did.

How Twilio’s history and culture create strategic inertia

Twilio went from nothing to IPO by focusing on developers. Jeff Lawson and his co-founders achieved this success DESPITE warnings from early doubters who told them it would never work.

Take this history, mix in Twilio’s deeply engineering-driven culture, and blend it all with the founders’ natural affinity for the developer audience, and it is not surprising that Twilio’s latest annual report emphasizes the developer-first strategy above all else.

Indeed, the report clearly states that that “our go-to-market model is primarily focused on reaching and serving the needs of developers.” Along with that:

• The word “developer” appears 114 times in the document. 13 of those happen in the report’s opening section.
• Twilio defines its mission statement and value proposition around developers: “we enable developers to build, scale, and operate real-time communications within software applications.”
• The company lists “Grow our developer community and accelerate adoption,” as its number 2 priority in the “Growth Strategy” section, just under “Continue significant investment in our technology platform.”

While I have no insight into the leadership team’s current thinking, the content of the report strongly suggests that they believe Twilio’s company and products are built for developers, by developers…full stop.

The relentless focus on Twilio’s developer-first approach is not merely a top-down strategic emphasis: it is deeply-rooted in the culture of the company. Take a look at this Glassdoor review from October of 2016:

While Glassdoor reviews from current employees are not necessarily a clear window into a company’s culture, this one rang true: The sense that non-technical people muck up the Twilio vibe was small but apparent five years ago, when I joined the company as its first product marketer and employee #50.

And while at that phase of my mental development, I was a loud, impolitic, and overly-aggressive presence (my since-retired “well-intentioned-but-misguided asshole approach”), I often had the sense that it wasn’t just me. Much of Twilio’s rank-and-file seemed to consider ALL of the non-technical business-side employees as inconvenient necessities.

Why the forces creating that inertia have turned from assets to risks.

Company cultures tend to develop their own sort of collective immune systems, and these immune systems naturally react with aggression and hostility towards ideas and people that threaten to change the way of things.

For Twilio, a go-to-market strategy focused on developers has been the way of things for a long time. It has the support of the company’s origin story and the weight of an entrenched engineering-driven culture behind it.

And let’s be clear: focusing relentlessly on developers has been essential to Twilio, whose success has rested on the company’s ability to build APIs and SDKs that developers love.

But now, the history and culture that give the current “developer-first” strategy inertia risk transforming from invaluable assets into potential liabilities…because at the moment, Twilio has at least $53.5 billion of market opportunities in front of it, and staying the course will put the whole kit’n caboodle at risk.

This is because most of the $53.5 billion opportunities in question are concentrated in big enterprises, where software developers are typically not the economic decision makers.

In a strange twist of irony, this is where Twilio’s early skeptics were right: trying to sell big enterprise deals via the developers who work at big enterprises is a losing strategy. Where these skeptics went wrong was doubting that that the company could get to an exit anyway.

More concretely: by building a remarkably powerful-yet-simple set of APIs and SDKs and evangelizing the hell out of them to software developers, Twilio achieved nearly $300 million¹ in annual revenue and a $2 billion IPO.

It hit both of these milestones on the back of fairly simple use cases and more complex point solutions.

But getting to $300M in annual revenue and no profit is quite different than getting to $10B/year and lots of profit. And to get to $10B and beyond, use cases and point solutions won’t cut it.

Twilio’s riskiest mistake: Conflating its early adopters and its mainstream markets

To understand why Twilio’s developer-first go-to-market strategy is putting market opportunities worth $53.5 billion at risk, let’s recall Geoffrey Moore’s famous “chasm” model of technology adoption. Here it is again:

Right now, Twilio is on the left side of the chasm. Over the last 10 years, it has successfully dominated the market of “early adopters” of cloud communications platforms.

Given that Twilio’s product portfolio consists of APIs and SDKs, its natural early adopters are software developers, tech startups, and tech-savvy product teams at larger companies.

But generally, these early adopters have used its APIs and SDKs to power the telecom functionality in their own SaaS products and to build apps, tools, and point solutions to a wide array of tactical problems.

Among the former, you see Twilio powering the voice and SMS capabilities in SaaS products like TalkDesk, RingDNA, and Zendesk Talk. In the latter, you see the “Phone number verifications,” “Dispatch notifications, and “Masked Phone Numbers” that constitute WhatsApp’s and Uber’s primary use cases.

But the big game (that $53.5 billion game I keep talking about) is NOT in the early adopter segments. It is across the chasm, in the mainstream markets. For Twilio, the mainstream would be the enterprise.

But in the enterprise, where Twilio’s potential revenues and profits get measured in billions, potential customers demand COMPLETE SOLUTIONS to their huge, expensive strategic problems.

So here’s that chasm diagram again, with some Twilio-specific details included:

And while Twilio has made a few promising in-roads, trying to convince decision makers at multibillion-dollar companies to build complete solutions to their biggest strategic problems on top of a bunch of APIs and SDKs is a SUPER HARD sell.

The fact is that the decision makers in these markets don’t really care if an API or SDK is elegantly-designed and simple to use.

These are C-level execs, SVPs, and VPs at companies doing hundreds of millions, billions, tens of billions, even hundreds of billions of dollars in sales every year. Many of them don’t even know what “API” or “SDK” means.

And while the decision makers in large companies may look to their company’s software developers and product teams for input, they’re ultimately focused on a completely different set of problems, desires, goals, and risks.

More concretely, the technical details of Twilio’s products mean shit to big company executives compared to whether or not these products can deliver tremendous savings, create huge process efficiencies, open major new revenue streams, and unlock massive new profits.

To enter its natural mainstream markets and win a significant share of their value, Twilio needs to find a reliable, repeatable, scaleable way to help them do all of these things.

And while I’m always open to being proved utterly wrong, I am extremely skeptical that a developer-first go-to-market strategy will do the job.

Fortunately, there are at least three ways Twilio can adjust its go-to-market strategy to serve its natural mainstream customers, deliver them the complete solutions they demand, and win significant chunks of those $53.5 billion market opportunities in the process.

Before we go there, though, let’s put some meat on these “$53.5 billion” claims I’m making.

The $53 billion market opportunities in front of Twilio are a mix of big existing markets ripe for disruption and new markets without existing solutions.

Given that Twilio’s core products offer voice, text messaging, and video conferencing capabilities, let’s start in existing markets where those capabilities readily apply:

Unified Communications and Enterprise Collaboration ($35-50 billion)

Unified Communications is a fancy, enterprise-y way to say “collaboration software that combines email, messaging, voice-, web-, and video-conferencing into a single solution.”

Analysts from Global Market Insights predict that the worldwide Unified Communications market will grow from 34.8 billion in 2016 to $96 billion by 2023, with the “cloud-based UC” segment expected to grow at a 16% CAGR.

Gartner is more conservative. Their analysts believe that the current UC market is increasingly mature and will grow at less than a 1% CAGR over the next few years. But they too, are bullish on cloud software, and predict 8.1% growth in cloud-based conferencing and 12.5% growth in cloud telephony.

The big players in Unified Communications are Cisco Spark, Microsoft’s Skype for Business (the software formerly known as Lync), and Mitel. Avaya used to be a player, but filed for Chapter 11 protection in January of 2017.

Like the big, lumbering behemoths that offer these products, leading Unified Communications solutions tend to be powerful but clunky, expensive, hard to integrate, and confusingly-packaged and messaged. Some (especially Skype For Business) also suffer from chronic video and audio quality issues.

Given that the entire point of Unified Communications is to facilitate collaboration and increase employee productivity in global companies, clunky software that doesn’t interoperate well with anything else and has chronic audio and video issues seems less than ideal.

In fact, the whole market seems ripe for disruption.

Contact Centers and Customer Care ($15-24 billion by 2022)

Including services and software, the global market for contact center solutions is large ($4-5 billion in 2015) rapidly-growing (22% CAGR until 2022) and seriously fragmented.

To get a sense for how and why the contact center market is the way it is, it helps to understand what’s involved.
First, there are inbound call centers (where agents answer sales and support calls), outbound call centers (where agents make sales and debt collection calls), and call centers that do a mix of both.

Some big companies run their own call center operations, while others outsource parts or the whole thing to vendors called Business Process Outsources (BPOs).

Along with a CRM, the software infrastructure in a call center consists of a bunch of different, inter-connected components.

Here are just the components relevant to this essay:

• The phone system (PBX). Short for public branch exchange, the PBX handles the contact center’s connection to the telecommunications network or uses VoIP. It also manages the phone numbers and/or extensions of all the contact center’s phones. Every phone call that comes in or goes out goes through it.
• An automatic call distributor (ACD). In inbound call centers, the ACD routes incoming calls to contact center agents. At the simplest level, the ACD’s job is to connect the caller with the first available agent as fast as possible. In more complex scenarios, ACDs can also route calls according to the agent’s skills or the callers’ particular profile and needs.
• An interactive voice response system (IVR). An IVR is that machine that answers the phone when you call a company for support and then asks you what you’re calling about. A simple IVR is like an “auto-attendant” that tells you the “press 1 for sales, press 2 support.” But in more sophisticated environments, IVRs will gather more data before routing the call through the ACD. This might include looking up your phone number in the CRM or asking you for your account number, birthday, or the last 4 digits of your social security number.
• A Computer-Telephony Integration (CTI). As the name suggests, CTIs connect the phone system (PBX) to the agents’ computers. When the ACD routes the call to a particular agent, the CTI pulls relevant data on the caller from the CRM and the IVR and puts it on the agents’ screen.
• Call recording software. If you’ve ever heard “This call may be recorded for quality and security purposes” when you call a business, that’s the call recording software going to work. Recording calls allows call center managers to keep a log of every agents’ interactions with customers. These recordings can be used for training, dispute-resolution, and disciplinary purposes.
• A predictive dialer. Used in high-volume outbound call centers, predictive dialers systematically dial through lists of phone numbers, detecting busy signals and answering machines. When a human answers the phone, the dialer instantly connects them to an agent. Predictive Dialers eliminate the need for agents to place calls themselves, allowing them to focus 100% of their time on their main tasks.

Cisco, Genesys, and Avaya are the incumbents here, and their solutions typically combine all of the above components under one, somewhat janky roof.

But contact center operations that have been running for a long time have often cobbled together “complete solutions” by buying and integrating some or all of these components from a variety of different vendors.

In either case, the result is a messy, fragmented market full of expensive, inflexible “solutions” that are ill-equipped to adapt to the rapidly-evolving demands and challenges of the 21st century.

This is another market just begging for disruption.

So those are the existing markets. What about new ones?

The Internet of Things ($3.5 billion, $7 billion, $470 billion, or $32 TRILLION).

In the consumer world, the Internet of Things (IoT) has been dramatically overhyped. Other than the well-received Nest thermostat, the IoT’s much-ballyhooed consumer applications have so far been a wash.

As it turns out, most human beings don’t see the value in internet-connected washing machines, coffee makers, or toasters. The long-promised “refrigerator that knows when your milk’s gone bad and orders more from the store” is both nowhere to be seen and of questionable utility to begin with.

But in the enterprise, the IoT has huge, massively-valuable applications that are both untapped and poorly understood.

So what’s the worldwide potential of these applications over the next few years? It depends whom you ask. Predictions range from $3.56 billion by 2020 at a 32.6% CAGR (McKinsey) to $7 billion by 2020 at a 21.11% CAGR (IDC) to $470 billion by 2020 (Bain & Company) to $32 TRILLION by 2025, 70% of which will go to B2B solutions (General Electric)

So there you have it. Based on just the conservative estimates of these market opportunities, Twilio is well-positioned to attack markets worth around $53.5 billion over the next 5 years.

But just saying these opportunities exist is a bit hand-wavy for my tastes. So to make it all concrete, here are the reasons Twilio would have a compelling competitive edge in these markets, followed by a range of solutions it could offer and three different go-to-market strategies it use take to get there.

Before we dive into the specifics of each market, let’s start with Twilio’s high-level advantages over the existing and potential competition in all of these markets.

Major Advantage #1: A market-leading portfolio of products

The original gangsters of Twilio’s product portfolio are its Voice, SMS, and MMS APIs and its Twilio Client Software Development Kits (SDKs). All of these products take what used to be a complex set of technical and operational challenges and abstract them away.

In concrete terms, Twilio’s core APIs and Client SDKs make it easy for software developers to build voice calling, text messaging, and picture messaging capabilities into their web and mobile apps…without buying complicated hardware, negotiating deals with telecom carriers, signing contracts, or spending a dime upfront.

From that foundation, Twilio added video conferencing and IP messaging SDKs. Like the voice and text messaging APIs and SDKs before them, Twilio’s Programmable Video and Programmable Chat SDKs simplify and accelerate the process of building, launching, and scaling new communications features and products.

Twilio’s Voice, SMS, and MMS APIs and its Client, Video, and Chat SDKs constitute the company’s core products, but they are far from the whole story. In fact, it’s actually Twilio’s Elastic SIP Trunks, TaskRouter API, and Programmable Wireless services that position the company to attack those $53.5 billion market opportunities.

Because despite their boring, jargon-y, and obscure-sounding names, these products are potential game changers.

SIP Trunks are boring, but Twilio’s Elastic SIP Trunks are awesome

At a high-level, a SIP Trunk connects a hardware-based business phone system to the internet, allowing it to use VoIP instead of the traditional phone network to make and receive calls.

Conventional SIP Trunking vendors typically offer their SIP Trunking services with a number of issues, headaches, and strings attached.

• Slow deployments. SIP Trunks from most vendors take anywhere from a few days or weeks to provision and set up.
• Package deals. Many SIP Trunk providers are also trying to sell you a complete phone system, with all of the expense, process headaches, and risks involved.’
• Recurring and upfront costs. The majority of SIP Trunk vendors charge monthly subscriptions for every Trunk and insist that you purchase a minimum number to get started.

Unlike the SIP Trunks offered by most of their competitors, Twilio’s Elastic SIP Trunks can be provisioned instantly: either programmatically via APIs or with a few clicks in a web interface.

The product allows enterprises to add unlimited capacity, failover capabilities, SMS, MMS, and hardware-free call-recording features to their call centers or business phone systems without ripping out and replacing any of their existing infrastructure.

Most notably, Twilio’s pay-as-you-go pricing model make it possible to prototype and test everything before dropping a lot of cash and committing to a big process transformation.

I’ll go into more depth about why this matters below. For now, let’s move on to the TaskRouter.

Twilio’s TaskRouter API is brilliant

To understand the TaskRouter API at the most basic level: picture yourself calling the phone number of a company you’re doing business with, getting the machine with the automated menu options, and pressing “3” for technical support.

When you press that “3,” the phone system routes you to the pool of people waiting for technical support (the “call queue”), where your call gets picked up by the first available agent.

Before Twilio launched the TaskRouter API, anyone who wanted to write software that could route calls or messages in even this simple way had to build all of the logic from scratch.

But like every API Twilio builds, the TaskRouter API distills nearly all of the coding work involved into a super-simple set of commands.

And despite its simplicity, the TaskRouter can handle dramatically more sophisticated workflows than the basic one described above. In fact, many of the workflows that the TaskRouter API facilitates can create tremendous value.

We’ll cover those in more depth further down.

For now, let’s look at the last piece of Twilio’s product portfolio that could help it access large chunks of those $53.5 billion market opportunities I keep talking about: Programmable Wireless.

Programmable Wireless is Twilio’s potential doorway into multiple soon-to-boom Internet of Things solutions.

Programmable Wireless enables software developers to buy, activate, and manage LTE wireless access via an API and SIM Cards that come pre-connected to Twilio.

The current product is still relatively immature: connectivity is offered only through one carrier (T-Mobile) and only in the United States.

But if and when Twilio expands it, anyone with access to software development talent will be able to use Programmable Wireless to rapidly prototype, test, launch, and scale a whole range of connected devices, products, and services that work anywhere with LTE coverage.

The possibilities it this unlocks are vast.

I’ll expand on those more soon. For now, let’s move on to the rest of Twilio’s core strengths.

Major Advantage #2: Near-complete flexibility and adaptability

Most on-premise solutions and every SaaS product (even highly customizable ones like Salesforce) force significant constraints on the company buying and integrating it.

This is by design: building a scaleable and profitable software business requires SOME degree of standardization. This generally means common interface conventions and a limited (even if large) range of potential configurations, integrations, and workflows.

To implement a new solution from an on-premise or SaaS vendor, the company in question must adjust, re-configure, or rip-out and replace a significant number of its existing processes and infrastructure JUST to fit the design, integration, and workflow constraints baked into the software it is buying.

One can address some of the limitations and shortcomings of the core product with add-ons and complementary solutions from third parties. (Think: Marketo and Salesforce).

But even then, you’re still stitching together an array of products from different vendors—each with its own interface, workflows, and database—into a complete solution.

Despite the tradeoffs and hassles, these solutions still can (and often do) deliver returns on investment. But they also push up the costs, increase the risks, extend the roll out times, and cause the investment to take longer to pay off.

But platform-first services like Twilio (the jargon is Platform-as-a-Service, or PaaS) impose no such constraints.

In the right hands with the right plans, platform-first products like Twilio allow companies to build and customize solutions that MOLD THEMSELVES to the company’s processes, people, and workflows, not the other way around.

They offer the benefits of fully-custom software without the drawn-out times to market or the high maintenance and upgrade costs.

For smaller companies, this flexibility and adaptability may not be worth the tradeoff against something off-the-shelf. But for bigger ones, it’s a game-changer.

Major Advantage #3: Rip-and-replace not required.

The big buzzword ploughing through the enterprise world these days is “Digital Transformation.”

Many big company executives are fully aware that they are facing a world of perpetual disruption from tech startups and tech-savvy competitors alike. They know that digital technology promises literally billions of dollars in potential savings and new revenue streams.

But they also know that implementing the technology and process changes necessary is really hard, really expensive, and FULL OF RISKS. (Remember: big companies are run by human beings, and human beings usually want to keep their jobs.)

Advocating for and then rolling out a “digital transformation” project that goes off the rails is a great way to lose your company millions or tens of millions of dollars and your cushy C-level or VP job at the same time.

Given these risks, one of the most compelling benefits of Twilio’s products and its pricing model is that it allows companies to start small and expand at their own pace.

In practice, this means if a company has already sunk millions into its existing systems and the top leadership isn’t ready to go all in on Twilio and the cloud, it can simply use Twilio’s Elastic SIP Trunks to prototype new solutions or extend and improve its existing infrastructure at much lower cost and with much less risk than “rip-and-replace” alternatives.

So if you’re a VP who believes that switching from a centralized call center operation to a virtual one will solve some huge problems, but don’t want to risk your job, you can use Twilio to run a small-scale test.

If and when that test gets great results, you can go back to the C-suite and show them how much better your virtual call center experiment performed on the metrics they care about.

Major Advantage #4 Infrastructure, redundancy, and scaleability.

Even five years ago, when I still worked there, Twilio’s back-end infrastructure could handle significant spikes in demand without missing a beat.

But back then, Twilio—which is built on AWS—was only running in one AWS region. So even if Twilio’s own architecture was rock-solid, it remained vulnerable to localized AWS outages that would be outside of the company’s control.

But in the 5 years since I left the company, Twilio has created a lot more resiliency and redundancy. It now operates in 22 data centers across 7 regions on 5 continents around the world.

Now, even if all of the AWS data centers in the Northern Virginia region go down at the same time, Twilio can re-direct the load to to any of the other 6 regions, dramatically reducing the likelihood of service outages.

This kind of scaleability, redundancy and resiliency is essential in an enterprise context, especially when you’re talking about mission-critical applications and workflows. And along this axis, none of the other “telecom API” companies come close.

While Twilio has a handful of other advantages, those four are enough to give them a compelling edge in the markets in question.

But what about the solutions themselves?

 

For Contact Centers

Problem: Contact centers have a MAJOR problem retaining agents.

While there is no shortage of big, expensive problems in the contact center market, one of the biggest is the boring-sounding but actually quite human-centered problem of “Agent Retention.”

So here’s a few weird facts about contact centers:

• Most of the call centers in the United States are located in large warehouse-like buildings with rows and rows of cubicles and minimal natural light.
• An agent’s daily commute to work might be anywhere from 30 minutes to 2 hours each way.
• If they work at an inbound contact center, they get paid $10-16/hour to answer calls from frustrated, angry, and lonely customers
• At at outbound contact center, they get paid the same amount to interrupt people’s days with sales or debt-collections calls, turning a lot of people into angry, frustrated versions of themselves.

And here’s an insight that MAY SHOCK…no one:

Very few human beings want to commute 1-4 hours per day to sit in an industrially-lit warehouse of cubicles, answering calls from frustrated, angry, and/or lonely people–all while being required to follow a tight script and maintain a positive attitude.

Even though they often NEED the money, many contact center agents find this scenario so demoralizing that they quit or their productivity collapses and they get fired.

The result is that the average attrition rate of contact center agents ranges from 30% to 50%, and every agent that quits or gets fired costs the company $5,000-15,000.

Solution: Switching from centralized call centers to virtual (“at-home”) agents

Faced with the high labor costs and huge attrition rates of centralized contact center operations, a big company has essentially three options:

1. Outsource. There are many overseas markets with plenty of English speakers but much lower labor costs that would love to take all those nice American jobs. The downside, of course, is the risk that your customer Bob from Arkansas gets mad when he hears an Indian or Filipino accent on a support call. Also: Trump.
2. Automate. While the time horizon on this is longer, the medium-term future will likely have plenty of voice-assistant robots that would love to take all those nice American jobs. The downside here is that the tech still has a long way to go, and you’d be contributing to the robot-led boom in unemployment.
3. Go virtual. This is the slightly counter-intuitive option: keep your call center operation in the US, but put your phone system in the cloud and let your reps work from home. With a low-end Chromebooks costing $70 and a perfectly good USB headset costing $20 you can deploy agents at home for less than $100 per agent in equipment.

Another insight that MAY SHOCK NO ONE: when people don’t have to commute 1-4 hours to sit in a warehouse of cubicles and can stay at home and spend more time with their families, they become WAY more willing to tolerate calls from pissed off customers and the drudgery of responding with scripts.

In fact, simply decentralizing a contact center operation and allowing agents to work at home reduces attrition from 30-50%, increases agent productivity 10-20%, and decreases costs in many other ways.

Meanwhile, when a contact center is virtual, the hiring pool is no longer constrained by geography. Instead of having to source candidates within driving range of its cubicle warehouse, a company can extend its search up and down the time zone.

With Twilio, a large enterprise that might want to create a dramatic reduction in its contact center agent attrition by going virtual can start the process slowly, tying together Twilio’s Elastic SIP Trunks, its TaskRouter API, and its Programmable Voice products to route a small percentage of its volume through Twilio without ripping anything out.

For Managing Enterprise Assets

Problem: Managing enterprise assets with analog systems and processes sucks (time).

Enterprise Asset Management is jargon for software, people, and processes that big companies use to catalog, track, maintain, upgrade, and replace their capital equipment.

In many companies across many of the world’s biggest industries (energy, aviation, defense, construction, shipping, manufacturing, just to name a few) these processes have long revolved around a messy mix of paperwork, data entry, back-and-forth phone calls, faxes, and other manual tasks.

As you might imagine, all of that stuff sucks up a lot of time that might be used for higher-leverage work.

But, thanks to a mix of technology limitations and the slow pace of change in these industries, analog is still the way things are done.

Solution: Digitize, streamline, and/or automate most of them

These days, a wide variety of those analog processes can be digitized, streamlined, and automated with technologies made possible by the smartphones, tablets, and the Internet of Things, creating truly gigantic efficiencies and savings.

Even without adding any new products, there is already a significant potential role for Twilio in all of this. Specifically, clever applications of Twilio’s Programmable Wireless and its various APIs and SDKs can dramatically simplify, streamline, and automate nearly all of the communication workflows involved.

When I worked in product marketing at Twilio, a small example of this sort of thing just landed in our lap: A leading soft drink company was rolling out its latest breed of vending machines, futuristic-looking contraptions that let soda-drinkers create their own blends.

Each of these new machines came with on-board diagnostic software and a wireless connection to the internet. Sort of like a new HP printer that orders its own ink when supplies get low, these vending machine tracked their supplies of soda and could also tell when there was a glitch or other issue messing things up.

Normally, if the soda vending machine needed attention, the on-board software would simply create a new ticket in the soft drink company’s IT service management application. That ticket would get added to a list of other tickets until someone noticed.

This process worked, but it was inherently reactive and slow.

So the company’s systems integration vendor built a notification and escalation workflow on Twilio. Now, whenever one of these vending machines needed refills or maintenance, the local service company instantly got a text message or a phone call with the details…no human intervention required.

That same core mechanic–using software-enabled communications to enable proactive and predictive maintenance and support–applies to all kinds of inefficient manual processes in offices, factories, and airport tarmacs throughout the world.

And as more and more office equipment and industrial machinery gets connected to the internet, the opportunity to create dramatically more responsive support and sales processes just gets bigger and bigger.

Indeed, the transformations enabled by Twilio-powered proactive and predictive service and support could create hundreds of billions of dollars of value in reduced repair costs, increased labor productivity, and regained time every year.

For Improving Marketing, Sales, And Customer Support

Making sales teams MUCH more responsive to qualified inbound leads

Research from the lead-gen industry suggests that the likelihood of getting a qualified inbound lead on the phone is HIGHEST BY FAR within the first five minutes of their expressing interest. The odds drop off steadily after that, and basically collapse between 25-30 minutes:

Right now, most inbound lead workflows move A LOT SLOWER than that. But with Twilio’s TaskRouter, the software side of this problem is not too hard to fix.

Here’s an example of a workflow for a high-quality inbound lead:

• Someone on your website fills out a contact form. According to the data in your CRM/Marketing automation app, they’ve consumed a bunch of your content, visited your pricing page, and watched a demo video.
• Based on that data, they are probably a strong lead, the TaskRouter sends a text messages or phone call to the available SDR or account with the highest qualification or closing rate on the team.
• If it’s a phone call, the rep answers and Twilio’s text-to-speech engine reads them the details on the new lead, then asks them to press 1 to accept or 2 to decline.
• If the rep presses 1, Twilio dials the person who requested the contact and bridges both sides of the call.
• If it’s a text message, the system just texts the rep the lead’s details and includes a clickable number to call.
• Meanwhile, you want to show your junior reps how your high-performing reps handle great leads, so you use Twilio’s call recording capabilities to record the call.
• When the call is done, the system transcribes the recording and attaches both the audio and the transcription to the customer record in your CRM.

Implementing that kind of workflow with an off-the-shelf SaaS product would typically require stitching together a lot of different apps and rapidly become a headache. With a PaaS product like Twilio, it becomes a lot simpler.

Giving sales reps WAY more insight when a potential customer calls

In Silicon Valley, the idea of putting a phone number on your website with a live person at the other end is typically considered grounds for involuntary commitment. However, this is how most of the rest of the world likes to do business.

But when you have a “conventional” phone number on your website, the main info you get when someone calls is whatever you can get from their phone number (if you even have it in your CRM).

But with Twilio, you have better options:

• One-click-to-call. With Twilio Client, you can enable people with a modern browser place a call straight from the webpage they’re on. The sales rep who answers will know exactly which page they were looking at when they called. If you implement it cleverly, the rep will also know exactly which pages they looked at before calling.
• Call tracking: If your company advertises its phone number in multiple places or includes it on different landing pages, you can use a unique virtual phone number from Twilio on each ad or landing page. You then use Twilio’s API to forward calls to your main business line. The difference? Now you’re capturing data on the source of every call–which can automatically be passed to sales reps before they answer. This way, your reps know what a prospect is calling about without having to ask.

In either case, the sales rep starts the call with far more insight into the prospects’ needs, enabling her to build rapport faster and avoid wasting time. The result is more qualified leads and more closed deals.

Maximizing the productivity of customer support agents

One of the most important metrics that customer support teams at large companies get measured on is “agent productivity.” One of the biggest metrics in this measurement is “first contact resolution,” which calculates the percentage of support requests that were successfully managed on the first try.

While an agent’s training, competence, and mood all play a large factor, one of the biggest contributors to long resolution times is actually the customer on the other end.

Specifically, most people just aren’t great at describing the problems they’re experiencing in a succinct or even accurate fashion.

But Twilio has two products that help companies selling software, apps, and other digital products address the problem of the “inarticulate narrator:” its video SDKs and Twilio Sync.

 

The video SDKs make it relatively easy to create video support systems like the one picture above. Meanwhile Twilio Sync makes it simple to pass data to the agent about the customer’s product, current configuration, and the screen they’re looking at while they’re on the support call or chat

This way, support agents no longer have to rely on the customer to describe the issue or to capture and send in screenshots. Instead, they can just get permission to access the customers’ screen and see for themselves in real time.

These problems, solutions, and markets are just a slice of the $53.5B pie

The markets, problems, and potential solutions described above represent just a sample of the opportunities that await Twilio across the chasm between its early-adopters and its mainstream markets.

Of course, understanding these market opportunities and crossing the chasm to seize them are not the same thing. And pointing out holes, risks, and problems in a company’s strategy is easier than offering ways to address them.

But no essay that expounds on the value of “delivering complete solutions” would be truly credible without…you know…offering some complete solutions. So here are three different go-to-market strategies Twilio could use to cross the chasm and attack its $53.5 billion opportunities.

These are almost definitely not the only possible options, and every one of them comes with tradeoffs, risks, and downsides. I will do my best to elucidate those here.

Potential Strategy #1: Pivot to a “partner-first” go-to-market strategy

The ecosystem of systems integrators is large and full of niches.

It contains consulting behemoths who serve big enterprises across nearly every industry and boutique shops who focus on a single specific industry, software platform, technology, or business problem…and everything in between.

Twilio currently has a partner program that includes some systems integrators, but the details are buried deep on its website and there seems to be very little public-facing activity coming out of it.

So with the “partner-first” strategy, Twilio takes its partner program out of the backseat and makes it the driver.

Specifically, the company overhauls its positioning, story, and messaging to focus on serving the goals, desires, and needs of partners. Even more specifically, it shifts the majority of its sales, marketing, customer success, and support efforts and resources into building, educating, enabling and supporting an ARMY of systems integrators.

Why focusing on Systems Integrators makes sense

Systems integrators (SIs) compete with each other across a number of axes, but one of most important is their ability (or not) to help their customers conceive of, build, and launch new systems that successfully maximize profits while minimizing risks.

Given the advantages of Twilio’s products outlined earlier, Twilio has a whole lot of value to offer systems integrators: SIs can use Twilio to prototype potential solutions to big enterprise problems without sinking months into development or investing much cash upfront.

They can then use these proofs-of-concept to demonstrate value and appease the risk-averse stakeholders on their clients’ leadership teams. They can also build these low-cost, low-risk prototypes to win new deals and expand existing ones.

And when it comes time to turn their prototypes into production solutions, the SIs won’t have to search for a reliable and scaleable communications-back end…since they already built the prototype on one.

For Twilio, pivoting to a “partner-first” strategy that focuses on SIs comes with a number of compelling benefits. Among them, it would let Twilio:

• Build an enterprise salesforce…without the enterprise salesforce. Successful systems integrators already have the expertise and relationships necessary to sell big, complex solutions to enterprise companies. Partnering with them gives Twilio a proven enterprise sales channel that doesn’t require figuring out how to recruit, hire, train, and retain a large enterprise salesforce.
• Deliver complete solutions…without building complete solutions. Complete solutions to enterprise problems require a lot more than software building blocks like APIs and SDKs. They require user interfaces, databases, authentication protocols, sophisticated permissions controls, and a whole host of complicated integrations. These are exactly the kinds of things that systems integrators build. With the help of SIs, Twilio can deliver solutions to a huge variety of major enterprise problems without building, marketing, selling, and maintaining a huge variety of solutions themselves.

As an added bonus, focusing on partners allows to Twilio to protect and maintain most of its engineering-driven culture.

First, since it won’t have to build a big in-house enterprise sales team to sell to big enterprises, the company won’t have to staff up with more non-technical business types that dilute the vibe.

But perhaps more importantly, empowering partners lets Twilio maintain its focus on what it loves to do and has done so well so far: building and launching products that give software developers lots of power in simple, elegant packages.

Indeed, the concept that partnerships with systems integrators will help Twilio sell to the enterprise got a bit of validation as far back as 2012, when I still worked there.

Specifically, Fruition Partners, a Chicago-based systems integrations consultant that specializes in ServiceNow implementations, discovered Twilio and has since used it to build a variety of sophisticated service-management workflows for big enterprises.

These include:

• Replacing a global retailer’s pricey after-hours customer support service and error-prone manual data entry processes. Fruition’s solution saved the retailer $25,000/month and eliminated the frequent data errors that allowed customer requests to slip through the cracks.
• Streamlining the equipment support and maintenance processes at a national particle physics lab. The original process required scientists to discover an issue with a piece of lab equipment and file a support ticket. With Twilio and ServiceNow, Fruition made the process proactive. Now, the moment a piece of lab equipment has a problem, the on-call technician automatically receives a call with the details. He can can press “1” to accept the ticket or “2” to escalate it.
• That soft drink vending machine support system highlighted above.

Given all of this, the mutualistic symbiosis between an API/SDK-first platform company like Twilio and the systems integrator ecosystem is so natural that it almost seems obvious.

Of course, no great strategy comes without tradeoffs, downsides, and risks.

The risks and downsides of going all-in on a “partner-first” strategy

While I’m sure I’m missing some risks and downsides with the list below, here are a few big ones:

• Relying on partners means leaving most of the value on the table. Even if Twilio’s APIs and SDKs are THE keystone components of a solution that saves a given enterprise $100 million over five years, the systems integrator that designed, sold, built, and implemented that solution will get most of the credit…and capture most of the revenue. The SIs would also likely believe that this revenue was rightfully theirs, since they took on most of the risk.
• Pivoting ain’t easy. Like any significant pivot, shifting from a “developer-first” to a “partner-first” strategy means breaking with a long-standing identity and dealing with the internal and logistical repercussions involved. Some of those repercussions are just a lot of work–like redoing the website and sales materials. Others can be a lot more painful–like parting ways with longtime employees who no longer fit with the strategy or reject the change.
• The developer audience could get mad.  If you’ve ever observed what happens on a Hacker News thread when anyone suggests prioritizing a big financial outcome or even hints that great marketing is just as important as great code, you know there’s a good chance that any shift in focus away from developers will create vociferous and painful backlash.

I’m sure there are more big ones. But even if there aren’t, each of these are substantial enough on their own to make rocking the boat with strategy pivot a scary proposition.

Of course, there are a number of ways to test the waters first before diving in headfirst. I’ll leave those to a future post.

For now, let’s move on to strategy #2.

Potential Strategy #2: Segmentation and personalization

Should Twilio want to cross the chasm into the enterprise market WITHOUT shifting its positioning, story, and messaging away from developers, it could segment its potential audience and personalize its marketing and sales materials.

Specifically, instead of a “one-size-fits-all” website, blog, and new-user sign-up flow, Twilio could segment its target audience into 3-6 different “buckets” and systematically adapt the messages on its website, its calls to action, and its sign-up flows and follow-up campaigns accordingly.

To make this concrete, imagine:

• Person A is a software developer. Every key page Person A visits contains messaging about the amazing simplicity and joys of developing or enhancing software with Twilio’s APIs and SDKs. The pages also include code samples in multiple programming languages and testimonials from developers. The calls-to-action are about creating a developer account, getting an API key, or downloading an SDK. When they sign up, the emails they get are all about implementing these APIs or SDKs.
• Person B is product leader at a mid-sized tech company. When they visit Twilio’s website, the key pages focus on how Twilio eliminates the risks, hassles, and upfront costs normally required to prototype, build, and launch high-value new communications-enhanced products and features. Instead of code samples, the pages highlight the wide variety of products and features that Twilio makes possible, the results these products deliver, and how fast they can be launched. The testimonials are all from product leaders from recognizable companies who back up those claims. After the product leader signs up, the sign-up flow identifies the kind of apps or features they want to build and lets them email (or text!) the relevant documentation to their tech team with one click.
• Person C is the owner of a large Business Process Outsourcing firm that specializes in outsourced call centers. And for them, Twilio’s website focuses on the benefits of using Twilio to build complete call centers or enhance and expand the capabilities of existing ones. Instead of code samples or potential apps, this person sees case studies about call centers. And instead of trying to get them to sign up for a “developer account,” the initial calls-to-action offer white papers or webinars about building innovative new call centers that deliver huge ROI, adding powerful new functionality to existing call centers without ripping anything out, and winning big outsourcing contracts.

See the difference?

Why segmentation and personalization make sense

Right now, Twilio’s website assumes that everyone who visits is either a software developer who might want to see documentation and get an API key or some amorphous “enterprise buyer” who might want to watch a webinar, download a white paper, or “talk to sales.”

With a product portfolio as deep and complicated as Twilio’s, this super-broad, binary categorization of its potential audiences has resulted in a confusing, multi-tentacled beast of a website.

To get a sense for what I mean, watch this quick video I made of me trying to learn about Twilio’s Video SDKs from the fictionalized perspective of the owner of a Business Process Outsourcing firm:

 

As you can see from the video, the BPO owner’s experience on Twilio’s website didn’t go so good.. But with well-executed segmentation and personalization, that experience would be quite different.

Segmenting its target audience and personalizing its website in sophisticated and thoughtful ways would allow Twilio to customize its marketing messages, proof points, calls-to-action, and follow-up campaigns based on the specific prospect’s most deeply-felt needs, goals, and desires.

In concrete terms, effective personalization would allow Twilio’s website to speak in compelling terms to every audience for its products AT THE SAME TIME…without the kind of broad, high-level language that resonates with no one.

It would allow to Twilio to position itself and its products as the IDEAL OPTION for systems integrators, product managers, CMOs, sales managers, customer support executives, enterprise IT leaders AND software developers WITHOUT leaving any of them in the cold.

Segmentation and personalization avoids SOME of the risks and downsides of pivoting to a “partner-first” strategy, but it comes with its plenty of risks and downsides of its own.

The risks and downsides of segmentation and personalization

First, there’s just the sheer amount of content involved.

For a company with as many different products and potential audiences as Twilio, doing segmentation and personalization RIGHT involves A HUGE amount of upfront work and A LOT of ongoing upkeep.

Every key page on the website would need a messaging and design overhaul for every target persona. Multiple new sign-up flows would have to be designed and coded from scratch. The number of different email messages, sequences, and branches is almost staggering.

And that’s just to get things started.

Every time Twilio launched a major new product and created a new page to explain it, that page would messaging and design for every relevant persona. A full website refresh (already a daunting proposition) would become a waking nightmare.

But the work involved in segmentation and personalization may actually be less problematic than the lack of focus it ensures.

In Geoffrey Moore’s classic book, Crossing The Chasm, Moore argues that a singular, hyper-intense company-wide focus on winning the ideal “beachhead market segment” is essential to successfully cross the chasm into the mainstream.

Whether Moore is correct in all cases or not, some degree of focus almost certainly reduces the probability of failure. Trying to market, sell to, and support all of the different high-value audiences Twilio can address would strain the resources of even a large company.

But for a company of Twilio’s size (less than 800 full time employees), the loss of focus would likely slow down the company’s execution at best. At worst, it could be lethal.

Potential Strategy #3: Productize and sell its own solutions

With its array of APIs and SDKs, Twilio has built many of the building blocks necessary to prototype, build, and launch fully-baked communications-focused apps.

But with the exception of a short-lived self-hosted business phone system called OpenVBX, the company has never used these building blocks to offer fully-baked applications itself.

With the “productize” strategy, Twilio’s tradition of leaving the software-building to other companies would come to an end. In its place, Twilio would use its APIs and SDKs to build SaaS products of its own.

Of course, this is Twilio, so these wouldn’t just be run-of-the-mill communications-focused SaaS products: they would be fully extensible, developer-friendly platform-style products: a bit like Salesforce, but without the proprietary programming language, slow load times, and clunky UI.

And if building a complete, platform-style SaaS solution is just a bridge too far, Twilio could start with extensible software apps or deeper abstractions that allow it to move up the ladder of value and capture more of that value for itself

There are many possibilities. Here are just two for now:

• An extensible softphone. With the advances in WebRTC, the traditional desk phone+CTI setup is wasteful and unnecessary. But if a company wants to use Twilio to build its own software phones and integrate them with its existing apps, it has to do it all from scratch. Twilio could build an extensible “plug-and-play” softphone that integrates easily with any relevant SaaS product (like CRM and Helpdesk apps) and sell it on a subscription plans.
• An extensible phone, messaging, and video communication system for businesses. While Twilio’s OpenVBX never got the love or attention necessary to make it viable, it actually offered a hint of the possibility here. Though I’m majorly biased (while at Twilio, I pushed hard to invest in OpenVBX and got shot down), the opportunity to build an ecosystem around a highly-customizable business communication system (like WordPress.org, but for phone, messaging, and video communications instead of websites) still seems huge and untapped. And four years later, Twilio is STILL well positioned to tap it.

Why productizing solutions makes sense

Building, marketing, and selling its own complete solutions would allow Twilio to capture way more of the value of those solutions for itself. Done right, it would also mean higher margins, less risk of commoditization, and much “stickier” products overall.

Specifically, delivering its own complete solutions would simultaneously:

• Make it easier for Twilio to price its products based on the revenue, savings, and profits those products generate.
• Make it a LOT harder and more expensive for Twilio’s customers to rip it out and replace it with a comparable competitor.

In blunt terms, it requires far less work, time, and cash for a company to swap out the code that makes the API calls than it does to rip out the entire communication suite that powers its sales, support, and internal collaboration processes.

If Twilio’s primary role in a company’s communications stack revolves around a bunch of API calls that could be replaced with a functionally-equivalent and lower-cost alternative with 1-2 weeks of development work, that role is perpetually at risk.

But if that role revolves around BEING THE WHOLE COMMUNICATIONS STACK, any lower-cost alternative would have to deliver a fairly gigantic reduction in costs to be worth the trouble.

So if Twilio wants to cross the chasm into the enterprise while generating substantially larger margins, lowering the risks of commoditization, AND entrenching itself in its customers’ businesses in ways that are hard to rip out, productizing its own solutions offers a compelling way to do that.

But like the other two strategies, this one comes with big downsides and risks, too.

The risks and downsides of productizing solutions

While the bigger margins, lower risks of commoditization, and strong lock-in that productizing solutions can offer Twilio might sound great on paper, in practice there are significant concerns:

• Building SaaS eliminates one of Twilio’s strongest competitive advantages. To re-state what I wrote above: building a SaaS product with a scaleable business model requires enforcing some degree of inflexibility on your customers. And Twilio’s near-total flexibility and adaptability is one of the critical factors that makes it so compelling.
• Selling SaaS to the enterprise is quite different than selling APIs and SDKs to developers. As Twilio’s annual report indicates, the vast majority of its current revenue comes from its self-service funnel that focuses on developers. And as that same report says, Twilio has minimal experience selling to the enterprise and only recently started building an enterprise sales team. But a large, competent (and expensive) enterprise sales team will be essential if Twilio wants to sell SaaS to the enterprise.
• Offering SaaS would mean competing with its own customers. While it may be the fate of any huge platform to eat its own children, it’s not clear that the owners of those platforms enjoy that part. And based on what I know about Jeff Lawson, he would find competing with his own customers radically unpleasant. Jeff puts a high value on integrity and trust, and he knows that entering into competition with his customers would betray their trust.

I’m sure there are other big downsides here, too, but this essay is long enough.

So 10,000 words later, here we are.

Twilio stands on the near-side of the chasm while markets worth at least $53 billion (and possibly much more) are waiting for it on the other side. But if the company continues pursuing its “developer-first” go-to-market strategy, it may fall into the chasm and get trapped there.

I’ve offered three different strategies the company could use to cross the chasm, and there are surely more.

None of them are easy. In fact, all of the strategies I’ve suggested and all of the strategies I did not are really, really hard. Each one has its own upsides, pitfalls, downsides, and risks.

But as Netflix’s CEO Reed Hastings told The New Yorker’s editor-in-chief, David Remnick, at last year’s TechFest.

The thing that most people don’t understand about strategy is that strategy is pain. And if your strategy is not profoundly painful to you and uncomfortable, you’re not very strategic.

The fact is that everything about building radically successful companies is hard and full of pain. Joys, too? Yes. But tons of pressure and uncertainty. To lead such a company means carrying these burdens while walking a lonely and occasionally terrifying road.

And all of it–the pressure, the loneliness, the fear–gets compounded because you can’t let the people you’ve asked to follow you see that you’re in pain, lonely, or afraid. But it is exactly this gigantic difficulty that makes building a radically successful company so gigantically special…and so vanishingly rare.

Twilio has already achieved remarkable things, but the road ahead of it is still quite long. If it can find its way across the chasm, the company will look back years from now and realize that everything that has happened so far was just the beginning.

Back when I worked at Twilio and the company was a total of 60 or so people, I sent the entire team an email about why I joined the company.

Here’s what it said:

“I joined this company because I think Twilio is a central actor in the story that ends with the democratization of telephony for the whole planet.

This story is the one I think we might tell more of, both internally and (massaged and polished a bit more) externally. Jeff speaks directly to this vision when he interviews potential hires and draws a diagram of Twilio’s role in the telephony stack on the white board: Twilio enters an old, stodgy, uber-powerful and widely-despised industry (aka telecom) and brings the party.

But software developers are not the only people we’re bringing to the party.  It’s everyone.

In fact, software developers are simply the intermediating layer between the bulk of humanity and the circuit-switched and wireless telephone networks. These networks have, since their inception, been managed by monopolistic forces that have generally worked hard to keep humanity out and tax it mightily for the smidgens of access they allow.

Well fuck that.

In my eyes, Twilio represents a disruptive force that will – should it manage to reach the apex of its potential – blow open one of the world’s most impenetrable black boxes, create a bridge between the PSTN and the fiber network and give ever-larger swaths of humanity access to the subsequent benefits.

In the process, Twilio could simultaneously make a ton of money and maybe (just maybe) help the world to become a more open place.”

What I wrote to my then-colleagues and bosses feels as true now as it did back then, in 2011. More true, even.