Twilio’s Developer Marketing: Solve Problems, Share Code
Twilio CEO Jeff Lawson refers to the communications API provider he co-founded in 2008 as a “third-wave company”—one launched in the era of the platform. Companies like Twilio, which provides messaging and voice APIs, create the building blocks to help others build new digital experiences for their customers.
Twilio’s focus is on telecom services, but it's whole existence revolves around the developer. It’s a company built for developers, by developers. In fact, new hires are required to build a Twilio app as a rite of passage (it also includes the receipt of the trademark red Twilio sweatshirt).
So Twilio knows a thing or two about marketing to app builders. We recently spoke with Twilio developer evangelist Matt Makai about building APIs developers love, the pros and cons of hackathons, and some of the cool things Twilio does.
What kind of mistakes do you see companies make when they design APIs?
A major mistake companies make when designing APIs is not dogfooding them. API developers need to wear the customer’s shoes and actually use the APIs in their own apps. When you have your "building and designing" hat on, you aren't wearing your "consuming and integrating" hat, which can degrade the developer experience.
A good developer evangelism program can also help to provide feedback to API builders. Software developers in an evangelism program should be constantly giving feedback from their own experience and from external developers who are using the APIs. Sending a message that “Hey, this onboarding experience isn’t quite right,” or “This step could be simplified,” or “This paragraph in the documentation was really confusing” is much easier to give when you're in the middle of developing an app that uses a particular API.
How about on the marketing side?
On the marketing side, developers cut through marketing B.S. really quickly. If you’re going to market to developers, you have to solve a hard problem. You provide the simplest solution that's possible with your tools. Then you have to be honest and you can’t use a lot of buzzwords or marketing speak, like "digital-first" or whatever phrases consultants are pushing nowadays. You just have to cut all that stuff out. Code with clear, concise comments speaks louder than anything else.
That’s what developers look for first: a clear explanation of what problem your API solves, followed quickly by an example solution in code. Developers looking at your documentation are going to immediately want the code then after they test it out may or may not read the prose.
What makes for an API that developers love?
Code examples in the languages that the developers are working in are critical. API companies should provide working open source code examples at a production-ready quality level. A developer can take the code, drop it into their development environment and see that you solved their problem.
When a developer has to build a requested feature in their sprint, you should not be the reason they are working late that night. Bonus points if a developer gets to go home early because the API integration was far easier than they originally anticipated.
Documentation is a key piece of this developer-first puzzle part. At Twilio we have Quickstarts, which, in five minutes or less, get you started with a new product. Then there are Guides, which provide a logical next step into more advanced bits of an API or additional architectural considerations such as security settings. Finally, we have Tutorials, which are full-blown applications written in all the major programming languages.
How does Twilio make money?
Our pricing model with products is usage-based. That model works well with developers because when you’re trying out an idea you have very little volume so you don't pay much, if anything. You don't need to talk to a salesperson who says: “Well you really have to pay $10,000 a month to get a license,” and you don’t know whether it’s going to solve your problem or not.
What are some unusual things that you’ve done to attract developers to your APIs?
We have a team here called Developer Community, which is a part of our broader Developer Network. The Developer Community team writes about the stories of developers that create amazing coding projects that deserve to be amplified to a larger audience. Here's a good example of telling a developer's story. A friend of mine in Washington, D.C., Shannon Turner, emailed to say: “Hey Matt, I wrote this fun app—whenever my bird at home chirps, my camera will take a picture of my bird and send a picture message to my phone."
I just thought her story was awesome and as a developer I wanted to see the code behind it. Shannon told the full story to my colleague Kyle Kelly-Yahner on the Developer Community team, and he wrote it up for the Twilio blog. The best part was, we put the code in the blog post. It’s not only a story about the person who built it or her pet. The post is also about the code that went into building that hack.
When developers see something tricky, the next logical step is how do they create that themselves? So we try to put as much code into the posts as possible to both inspire and equip our fellow developers.
What’s your take on hackathons?
Our team goes to dozens if not hundreds of hackathons each year. Hackathons can be a great place to learn. There has been some push back against hackathons lately but the events aren’t inherently good or bad. Some hackathons are better-run than other ones.
Developers that go to a hackathon need to ask themselves what they want to get out of it. Some attendees want to win a hackathon, so they go in with that mindset. Other developers say "I just want to learn." Computer science majors at college hackathons can put their classroom lessons into action. They get out of academia for a couple days and they just go at the code to make their ideas into something tangible. There’s an inspirational component in hackathons; you carve out a block of time and just get to work on your idea.
Is there a downside to hackathons?
There is a downside to hackathons because if you stay up for 48 straight hours it's not going to be good for your health.
The only other bit that I would add is that while it’s okay if recruiters go to hackathons, but you need to also send your developers. If you don’t send anyone technical—a software developer that’s able to work with other developers—then why are you there? Developer to developer interaction is what helps attendees build their hacks. For companies, hackathons should be able mentoring and assisting attendees, not sales pitching or standing around observing.
Matt Makai is a Python and Swift developer on the Twilio Developer Evangelism team based in San Francisco. Matt is an active contributor to open source projects such as Ansible and Full Stack Python and writes tutorials on the Twilio blog. He can be reached on GitHub or Twitter as @mattmakai.