June 16, 2020
Ep. #57, The Next Wave of Developer Tools
In episode 57 of To Be Continuous, Paul and Edith explore the vast differences between the devtools community of yesteryear and today, from ...
My name is Sara Varni, and I'm the CMO at Twilio. I wanted to share with you my learnings from the last three years that I've been at Twilio. A topic that's near and dear to my heart, and that's how a developer relations team and the sales organization can partner well together. I hope by the end of this session that you learn something, that there's something that gets you excited. I think if I had to sum it up, the TL;DR of my three years is that at the end of the day, these organizations aren't as different from each other fundamentally as people might think or people assume. Hopefully some of the tips I've learned over the last three years will be helpful, but let's just jump into it.
Just a little bit about Twilio for people who aren't familiar with the company, we started in 2008 and it started actually when Jeff Lawson Rickrolled someone on the stage of TechCrunch Disrupt, and it started with a voice API but led to a series of communications APIs across a number of different channels from SMS to video, to email. We even have an IoT product, and most recently we've entered the contact center space, given our history in communications channels. Today we're proud to be operating in over 100 countries and we have over 170,000 customers. Most importantly, we have 8 million developers that know and use Twilio.
Twilio was really built on developer love.
We've always been a super developer-centric
company and were almost entirely
self-service up until about three
years ago. But over time, as we started to move
from SMB to mid-market and then up into the enterprise,
we realized that we needed more hands-on
account support. As customers began
to spend more and more with us, we
found that some of them might disappear without
a lot of communication with us because we didn't really have the
relationships in place. Seeing
that, we decided to build out a
go-to-market team and the sales team more in
earnest. Our joke because of that
is that Twilio is now a 12 year old company with a
3 year old sales team.
So when I came to the company, I saw a huge opportunity to connect this developer community and our incredible developer relations team with this growing sales organization, and really use both of those teams' superpowers to drive the most impact that we could for Twilio. But as you can imagine, that's a dance that you have to do. You have to be careful not to lose your credibility with that developer audience, also while being action-oriented and making sure that you're aligned to corporate goals and to what that new sales organization is trying to do.
So, over the next 20 minutes or so I'm going to walk through some of the tactics that we've used to really bridge that gap between developers and the business. I think it starts by finding that unifying metric.
I think often when you go down this road and
are trying to think about, "Alright.
How can I make the most of all of
this great developer activity I have in my company with this
go-to-market organization?" There's
sometimes this perception that it's just oil and water and there's
no way that you're going to get the teams to
ever align, so as I was thinking
through this presentation I thought through some
of the people internally at Twilio who have
been instrumental in driving this change with the company.
We have someone like Greg who runs our developer community, he's super passionate and has been at Twilio for a number of years. He can name some of our earliest customers and just has a great reputation with our developer community and customers in general. Then we have Stevie, one of our most prolific enterprise sales leaders. She is great at creating a vision for our customers, great at being side-by-side with them and really helping them think through some of their customer engagement challenges. They're both just great, phenomenal leaders at the company.
But obviously, when they wake up in the
morning they're motivated by very different things.
You think about Greg and what motivates him in his role,
he's going to be focused on things like developer sign-ups. How
many people is he adding to that Twilio community?
Developer activation, once he gets them into the community are they
actually doing something with the
tools? Are they making it to meaningful milestones with Twilio?
Then, are they coming back to do more?
Or did they just do a project and we never
heard from them again? But are they
coming back on a regular basis to see what's new with Twilio and
to do more on our platform?
Then you think about Stevie as our sales
executive, she's got a completely
different set of metrics that motivate her. It
might be enterprise pipeline, how is she building
more and more opportunities for her business so that ultimately
she's going to hit her quota. New
bookings, and ultimately revenue, after she's signing on
these customers are they meeting their forecasts? Are
they continuing to build on Twilio and
drive usage of the platform?
Just looking at these two, it might be hard to figure out. "Alright, how can we really align these two worlds and get people working together?" So we all teamed up, we came at it from both sides, coming at it from a humble perspective of not knowing everything that we know about the respective functions, and we decided "What is that intersection of these two groups? Twilio is trying to move to the enterprise, we're trying to move to bigger and bigger customers."
It could be easy to go at it from a number
of different ways, you can think about, "Let's
just go after certain programming language, let's go
after a certain territory." There's
so many different ways that you could slice and dice it.
We decided we wanted to eat the elephant one bite at a time
and we landed on developer sign-ups in a particular segment
of our enterprise customers.
Now, this might sound simple and you're like "Yeah, of course. This is not rocket science." But it was really critical and we spent a lot of time getting to that metric so that everyone was clear on what the priority was. If we're going to do an event, who's it geared at? It really helped us fine tune the programs that we were going to deliver. Also, I think a byproduct was just having the conversations about what's meaningful to these two groups of people and figuring out where these intersections exist in the first place.
The second piece is really identifying the pivotal moments in a developer journey. One of my long standing jokes is that "Rule number one of marketing to developers is 'Don't market to developers.'" I think you really have to come at it from a place of being helpful and unblocking parts of your process so that developers can continue to do what they came to your website to do and get moving with their project.
I anonymized this particular opportunity, but at Twilio we do a lot of opportunity journey analysis. We look at all the activity from when someone first comes to our website and signs up for one of our APIs, to when they actually become a sales opportunity in Salesforce. We look at a lot of these just to see the patterns and trends, and to see how we can fine tune this journey.
A couple of things that I think have come
out in this experience for me--
first off, if we see a sign up and
then there's five different content
downloads or people are looking at docs and then they go to an
event and then they ultimately become an
opportunity, we're always trying to think
about what are the ways that we can optimize that journey and really
shorten that fuse between developer sign up and an enterprise
Arm both sides of that equation, making sure the developer has all of the tools and resources to skill up and to learn what they need to know about your platform. But also on the enterprise side, are we communicating the value to the enterprise buyer and the person that might ultimately hold the budget to say, "This is why you should be thinking about contactless delivery right now." Or, "This is why you should be thinking about moving your contact center to the cloud," so that when the developer does go to their PM or vice versa, they both know what value Twilio brings to the table.
But a couple of things that we've learned
over the course of the way, I think it goes without
saying is, when it comes to developers, you need to earn the right to
communicate with that audience. You
need to make sure that you're not leading too much
with your products and features and feeds and speeds, and really coming
at it from a place of helping them.
I think a lot of that can be done
by recognizing how they came into your site, what they were looking
to do, and then providing the right nurture and follow up
to make sure that you're helping them along that journey.
I think another thing
that bridges that gap and shortens that fuse between that developer
interest in what's happening in the business, is packaging
up things like your documentation and packaging up things like
blog posts that really get to a use case as
opposed to an individual API.
I think that helps the product managers and
solutions architects that sit in middle, picture
how some of your individual
products could come together.
I like to
say that the scenarios I'm talking about are very Twilio-centric
and centered around are our
products, which are API-based. But
I think there's different approaches-- if
you're supporting a product that's completely out of the box, or if
you're more of a SaaS solution. I'm
happy to talk through some of that
during the Q&A, as I spent 10
years at Salesforce and have definitely lived in the SaaS space.
I think another important component, and I've seen this across the board in my experience as a marketer is
The more you can connect your existing community members to new members I think the better off that you are. I see some people hesitate to do this because they're nervous about what a customer might say to a prospect, but I think if they're going to invest the time to engage with your community most often they're going to have positive things to say.
I just think it's a way to accelerate
development on your platform, and I think it's a great way
to cut through some of the marketing
fluff and get to really what a developer is looking
to solve and to help get them through their problems. I
think there's also an argument to provide tools for
developers to sell the value of the
project up the chain to the business
owner or the person that's holding the budget, so
things like ROI calculators where you can show comparatively
if they're to implement your tool, what
the value that is going to bring to the
You really want
to be as hands-off as possible and helpful, pushing
and helping them along the journey, making sure that they're not
reaching any blockage in your product.
But when they do appear to be looking for help,
and we look at a lot of signal in
our base of developer sign-ups,
there is a moment when you do want to bring that sales team
in so that they can get them the right support. Especially
as you are dealing with bigger and bigger customers, they
might want intros to your professional services team and they might need
help with solutions architects on your
team, or solutions engineers.
To the extent that you can identify when a developer really does want to engage with your customer-facing teams, I think it's important to make that connection. But I think it goes without saying, when a developer signs up for your product. the first thing you shouldn't do is get your inbound sales team to go and qualify that. Because that is going to be not a great experience for either side, and I think you need to figure out other ways to move them through your product funnel.
The third area that we've really focused on
is how you can empower and train
people that are learning about your
platform and getting up to speed.
I think sometimes when you have
started as a company focusing on SMB
and mid-market, there's a perception that enterprise
developers don't want to be innovative. That
they don't want to focus on new cool projects, and
I think it's been really interesting to see our developer evangelists at
Twilio start to engage more of
their enterprise accounts and watch how that perception
We do what we call Enterprise Hackathons at
large enterprise companies, where we'll bring
some of our developer evangelists
on site to our customers, pre-Covid
of course. But we've actually
created a virtual version too.
Back when it was in-person, the customer would
come with a set of use cases that
they wanted to tackle and they would
hack together on them all day. At
the end of the day, they do a presentation back to the business
and it's a great program in that these teams get
scaled up on Twilio in the course of a day,
and for their counterparts in the
business, they're excited to leave the session with some
early proofs of concept of what Twilio can do.
I have this this image up because at
one of these enterprise hackathons, we went to
a large customer-- they'll remain
nameless, but in the break room
they had this sign by the actual
television that said, "Please do not try and change the channel."
One of our developer evangelists commented on
the fact that these enterprise developers,
they want to do cool and innovative
things at their company but they're not even allowed to change the
channel of their TV.
It was just a joke that we had internally, but I bring it up because I think once our team had gotten on-site with some of these enterprise customers and teams, they realize that they're not all that different from the startup developers and some of the smaller developers from smaller companies that we've worked with in the past. They want to be innovative, they want to bring new ideas to their company, they're just not always equipped with the tools and the freedom to do that.
So we really tried to design programs
with that in mind, and how we can give them
new tools in their tool belt to use
and create the best customer experiences that they can.
So, just three programs to walk through that we've
established here. One is our
Superclass program. We do this in
parallel with our road show. We have a road show
called Engage where we go and give an overview of
what Twilio does, our platform, the business value of it. It's
really generally geared towards product manager or
head of contact center or more of a business audience.
But alongside that, we have a Superclass which
runs in the morning and we encourage developers
from the same companies to come and to get hands-on with the product.
We take them through our virtual
learning platform called TwilioQuest.
It's a gamified platform where they learn through different
challenges and earn points over the course of the day.
We love having this approach of having both
this technical session as well as this line of business session,
to bring both groups together and to hear
the sides of Twilio that are going to be most
relevant to them.
The second is foundry workshops, so we're a platform company and sometimes we come to customers who know they've got customer engagement challenges, but they don't know exactly how to solve them. So we'll bring in a team of design leaders from Twilio and we'll sit down with both developers and the line of business to map out a customer's cool customer journey and say, "OK. Here are the rational places where Twilio can help. Here's where some of our partners or other solutions could help."
We like to make developers a part of that process, so early on they can weigh in and say what's going to make the most sense for their business and in the context of what they're already using.
Then a third way we do it is those Enterprise Hackathons. I talked a little bit about it already, but it's just meant to get people on-site and engaging with customers, helping accelerate some of those proofs of concept that they otherwise might delay or might take longer had they not had the hands-on expertise right on-site. This has been a win-win for both our customers and our sales organization. It's been great for these customers to get scaled up on Twilio in the course of a day. It also helps accelerate that proof of concept cycle for go-to-market teams, and keeps projects moving along much more quickly.
I would just say, just some commentary on how to execute it. I think everything can look good on paper, but at the end of the day you need to make sure that people are motivated to do this, that they don't feel forced to change the way that they've been operating for years, and I think that there's an art to that.
I see a lot of our developer evangelists
super willing to help out with our sales
organization and to get in the trenches
with deals, but sometimes they don't know
always how they should insert
themselves. I think it's important
to be prescriptive. How do you want
them to participate in a meeting? How
do you want them to be part of the process? I
think rightfully so, some members of the DevRel
team might be concerned that they're going to just be in this deal
monkey cycle where they're constantly having to
work on demos or PowerPoints.
You want to make sure that you're setting the
ground rules early so that doesn't
happen, and that people are still able to do
the core of their day job and really what their
job description looks like.
think bringing your DevRel team
into your sales organization or blending
the two, it's not a fit for everyone. You
have to recognize the people who are interested in this kind of work,
and then there are people that aren't.
I just don't want people to walk away saying,
"OK. I'm going to turn my DevRel
team into this Secret Squirrel sales
team tomorrow," because I don't think that that's the right approach.
But I do think having your developer evangelists
do a tour of duty with some of these customers can be really helpful
and help them in their day to day, even
if they're not, moving forward, going to be exclusively
focused on working with enterprise customers.
Again, it always comes back to
that helping versus selling. I
would think of using your developer evangelists and your developer
relations team as more of an extension
of solutions engineering. I've seen
some incredible work happen across our two teams at Twilio during Covid,
where our documentation team and
our developer evangelists are building a lot of content at the
API and product level, but our solutions
engineering team who's out in front
of customers quite often-- we're hearing about
new use cases that were coming through Covid.
So we married those use cases we were hearing with the content that we already had in our developer library to repackage things aligned by use case. Instead of having things at the individual API level, what is the tutorial to help someone deliver on contactless delivery? So I've definitely seen a lot of great synergy coming out of those two teams in the wake of Covid, and I just think it's something to keep on your radar and think through as you're trying to think about how you can bring these worlds together.
Finally, I just want to add some final thoughts on scale. I know many of you are operating companies that are that are smaller, relative to a Twilio.
But I want to assure you that we don't
actually have a huge army assigned
to this as an effort at Twilio. I
think we've still been able to achieve some pretty
phenomenal results, but a couple of things that I was thinking
about as I was building this out, it's very easy for me to say
this now given that everything is digital. Always
think about digital first, so for all the programs I was talking
about, whether it's Superclass, whether it's Foundry
or whether it's our Enterprise
Hackathons, we have virtual versions
of these. That will only help you
If you always have
to fly people to a city, fly to
people to do something, that's just not going to scale to thousands
and thousands of customers if
that's what you need. For all of these, I would just think
about "What is the digital--?" Of
course, sometimes face-to-face interaction, there's nothing
that can replace it. But I do think
for all of these things you should be thinking about "How
will this transfer digitally, and can it scale?"
I also encourage you to find leverage points in your community. We have some people who are so super passionate about Twilio, and we have often packaged up some of the material that we have. Whether it's that Superclass curriculum for some of our big influencers and community members to drive that on their own, so that they can host their own Superclass or they can even host their own virtual hackathon.
I think you'd be surprised at, especially for people who have huge brand affinity for you, the lengths that they'll go to, to share what they've been doing with your products.
I would just be on the lookout for who those
influencers and key committee
members are. Then I always advise
people to really think about a "Train the trainer" method.
At Twilio our sales organization is
growing much faster than our marketing team, for example,
or our DevRel team. So I'm trying
to think about ways that I can put this program in the hands
of other teams that are growing faster than mine.
For things like the Enterprise Hackathons, while our first iterations of them were very heavy in terms of our DevRel participation, we've tried to increasingly think about, "what are the tools, what's the playbook and checklists and all those things that we can hand to our solutions engineering team, so they could deliver them without us being in the room?" Because their team is growing, like I said, more quickly than ours. That's just another leverage point for us as a marketing team.