Thoughts about Twilio Studio and the Future of CPaaS

How does Twilio Studio fit into Twilio's Ask Your Developer campaign?

Last month I participated in Twilio’s Signal event that took place in London. I was invited to speak there on test automation in WebRTC. You can watch my video session on YouTube. That isn’t the point of this article though.

Signal is where Twilio announces most of its major new releases. Last time, earlier this year, it was all about the engagement cloud - a restructuring of how Twilio explains its services - and a migration from a single channel world into an omnichannel one. I’ve written at length about it in Is Twilio Redefining CPaaS (hint: it is). I wrote there:

Twilio has introduced a new paradigm for the way it is layering its product offerings.

In the process, it repositioned all of its higher level APIs as the Engagement Cloud. It stitched these APIs to use its lower Programmable Communications APIs, adding business logic and best practices. And it is now looking into machine learning as well.

It is a powerful package with nothing comparable on the market.

Twilio are the best of suite approach of CPaaS – offering the largest breadth of support across this space. And it is making sure to offer powerful building blocks to make developers think twice before going for an alternative.

I think that at Signal London 2017, they outdid that with the introduction of Twilio Studio.

Before We Begin

You might want to take the time to watch Signal London 2017 keynote by Jeff Lawson.

https://www.youtube.com/watch?v=Opm7I_dF7Ec

A large part of the London keynote was a rehash of what was said in San Francisco earlier this year. It was about the shift towards omnichannel and the engagement cloud. The words that struck to to me when explaining the engagement cloud were BEST PRACTICES, BUSINESS PROCESSES, REINVENT THE WHEEL (=what not to do).

I’d like to touch in this articles a few main themes and approaches that Twilio is taking, which are shaping its vision and execution at the moment.

“Ask Your Developer” is The Wrong Approach

I’ll start with where I think Twilio is missing the mark.

Ask Your Developer took center stage. Jeff Lawson wanted companies and the business people inside it to go ask their developers what they can do. How they can improve the business.

It gives us developers a great feeling of being in control. Of being valued. But for the most part, and for most developers, this is probably the wrong approach.

Most developers would be happy to work by spec.

The few that aren’t will be promoted quite fast to system architects, managerial roles in development or god forbid to product managers. Why? Because they can see the big picture.

They are the people that get asked. Or the people that answer without asking.

We should be asking our developers, but it should not be our strategy.

Which is where the miss came.

Twilio announced later on in the keynote Twilio Studio. A tool that takes some of that control from developers, putting it at the hands of decision makers.

You no longer have to ask your developer. You can work with him. Together.

More about this later.

The Code that Counts

Some 20 minutes into the keynote, Jeff Lawson invited Patrick Malatack. He started with this:

It was core to how Twilio approaches its customers. Patrick explained that this is the most important code - it is the code that counts.

The idea being that your life as a developer should be made easy, so Twilio is adding not only APIs that serve the functions you need, but also a runtime behind it to facilitate rapid development and deployment - from helper libraries, to logging and debugging facilities, the new Twilio Functions, etc.

I think the code that counts here is developers focusing on their specific business problem - abstracting everything else.

It ended up being a concept of what Twilio Runtime is:

The yellow parts in that screenshot above are the newest announcements. The rest were there earlier. Twilio isn’t only adding more features to its platform - it is beefing up its runtime, making it another competitive advantage in front of many others where it comes to pure SMS and voice capabilities.

The message here is an interesting one, but it wasn’t polished enough. I think this is where we will see more in future Signal events from Twilio.

Twilio Studio

At about 1:24:00 of the keynote, Jeff Lawson introduces Twilio Studio.

It starts by explaining that building is fun but maintaining isn’t (he is correct).

The goal, based on Jeff Lawson, is to massively accelerate roadmaps of Twilio’s customers.

I think it is a lot more than that.

Because this is so new and fresh, still in developer preview (and something I’ve started playing with a bit), it is hard to write this in an ordered fashion. Which means I’ll be going for a bulleted list instead :-)

• This is a really cool tool. From the demos and the time I’ve spent with Twilio Studio, it is really powerful
• Getting UI tools that handle state machines for developers is not easy. The Twilio Studio experience has a nice feel to it - I liked the experience
• Twilio Studio reminds me of Zapier. But where Zapier has a 1D linear approach to tooling and integration, Studio is its big brother, offering 2D visualization to communication state machines
• There’s no support for the visible communication parts in Twilio Studio. Yet
  • You can send and receive programmable SMS and voice with it
  • A bit of messaging as well
  • But you can’t connect it to the voice in your SDK or manage a video chat room with it
  • This will need to be added later at some point to complete the puzzle
• Is Twilio Studio the centerpoint of a customer’s flow or a corner piece of it?
  • Twilio Studio can be used to express your whole business process, fleshing out the important parts and branching away to your integrations
  • It can also be used to solve a minor piece of your bigger puzzle
  • It is up to you to decide how you use it
• At the hand of an experienced architect, Twilio Studio will offer super powers
  • There are many ways to define and template what you need
  • Some approaches will work better, offering more flexibility
  • The focus should be around inclusion of as many stakeholders in the company as possible - being able to show them and interact with them by looking at a Twilio Studio Flow
• Here’s a question: Is Twilio Studio a tool for Developers? Designers? Implementers? Analysts?
  • Twilio Studio today is fit for developers, but it won’t stay that way long
  • It can be used by implementers that know a bit about code but aren’t developers
  • It can be used to open a discussion between a developer and a business analyst
  • This is a way for expanding the target market within a Twilio’s customer from solely one of developers towards a larger audience. The motto is no longer “Ask your developer”
• Twilio Studio can be enhanced
  • It is a great first step, but the next ones are a lot more interesting
  • They are also a lot more threatening to competitors
  • If Twilio succeeds here, it will dominate this space with the companies that matter the most
• Twilio Studio is the ultimate vendor lock-in
  • Enterprises will adopt it, due to its many benefits
  • They will find it hard to switch because of these benefits
  • Enterprises won’t want to switch… Twilio Studio will be too valuable. Too transformative

This tool can do to contact centers what marketing automation is doing to email newsletters. If I were a contact center vendor… I’d consider Twilio Studio my biggest threat moving forward.

Pricing

There were 3 price points for Studio:

1. FREE - up to 1,000 Engagements. To get developers hooked up to this tool and make them not bother with actually “developing” using “code”. It is also a great way of getting developers to NOT look at other competing vendors
2. The minimal plan, at +$100/month price point. Covers up to 20,000 Engagements. This is probably where most small companies will be “living”, which is just fine
3. The enterprise, unlimited plan, at $10,000/month or more. Expensive, but it depends how much traffic you’re handling

Then there’s the question of what an Engagement is exactly. Is it a flow of a single event in a Flow? Is it a widget being accessed inside a Flow? In a 2-way bot conversation, each message exchange is probably an exchange I am assuming - the more talkative your app - the more Engagements it will eat up.

Not sure if I am missing a tier between PLUS and ENTERPRISE here. There seems to be too big of a gap in there.

Positioning

One last thing - Twilio Studio has been positioned by Jeff Lawson inside the Engagement Cloud, below all of its current logical components:

I’d place it as a vertical bar next to the whole Twilio stack. Probably adding Functions write next to it:

My guess? Product management had a lot of internal discussions on this one, trying to decide where to place Studio - inside the engagement cloud, above it, right next to it. They ended up picking inside it.

A Word About GDPR

GDPR stands for General Data Protection Regulation. It is a piece of legislation that will become effective May 2018, in less than a year. A period of two years of grace has been given to reach that date.

It deals with the protection and processing of private information of citizens of the EU, which practically covers any global player out there, and even many who aren’t.

In a nutshell, it is a headache. Especially if you’re making use of analytics, personalization, automation, chat bots, AI or any other big data related technology. It is also relevant if you just hold an SQL database of your customers.

If you were working in a specific regulated vertical, such as healthcare or finance, then you might be used to such things. If you’re not, then you should start paying attention. Especially with the communication part of whatever it is that you do - this is where personal information gets passed along with the metadata that needs to be handled with care.

Twilio pushing GDPR this early on means two things to me:

1. They are looking at the enterprise, and making sure their platform is fit for their purpose (large multinational enterprises will be the first to adopt and adhere to something like GDPR)
2. They are making sure that they are leading the CPaaS pack here. I am unaware of any other CPaaS vendor who has been pushing GDPR besides stating that they will be ready by May 2018. Twilio is trying to make sure it is synonymous with “GDPR compliant CPaaS”.

It also means that communication - telecom or IP based - is becoming slightly harder to handle. Something that works well for a vendor like Twilio whose purpose in life is simplifying complexity (=the more complexity the more value derived by Twilio).

Where do we go from here?

Twilio was and still is the undisputed CPaaS king. They are bigger than anyone else by a large margin and they are working hard on maintaining a technology edge on everyone else.

Twilio’s stock has been somewhat volatile lately with Uber’s announcement and later Amazon’s text messaging announcement (which ended up about Amazon using Twilio). Twilio seem vulnerable.

The two main announcements here were Studio and GDPR. Studio brings Twilio to a larger audience and increases their vendor lock-in, whereby reducing the effectiveness of their competition. GDPR is put in place as another headache Twilio solves for its customers - the more regulatory and bureaucracy like GDPR the better for a company like Twilio - it reduces the competition from in-house developers - which is doubly important now.

These two announcements are there to deal with its perceived vulnerability. They make developing using Twilio easier than ever - almost risk-free. And it makes it harder for competition to succeed in future land grabs trying to go after Twilio’s bigger accounts.

It will be interesting to see how competitors would react to this in the long run, and even more interesting to see what will Twilio Studio grow into.