How to Explain Your Products to Developers

Hey folks, my name is Matt Makai. I serve the Developer Network at Twilio. We've talked a lot today about making the real, physical world programmable. We ask "what if we could modify the world using GitHub and Jira?" When we succeed in creating programmatic access to the physical world, what then? Is that the end goal?

No, that's only the beginning. We need developers to use those new capabilities and code with them.

How do you get developers to adopt what you are creating? That is a broad question so I am going to zoom in on just one small slice of developer relations that kicks off the whole adoption process. Unfortunately I see upwards of 90% of companies completely screw up explaining their products to developers.

Today we are going to look at how to appropriately explain and demo your product to developers to maximize developer adoption. This is the first step towards getting a developer to care enough to try out what you have built.

In addition to serving the Developer Network at Twilio, I am also a Python and Swift developer as well as the creator of Full Stack Python. My background provides me an opportunity to give insight on this topic because I am a software developer, I market to fellow software developers and I write a community-driven site that is widely read and trusted by software developers.

How do you explain your product? Fred Wilson of Union Square Ventures said it best in this quote, which we will roughly summarize as: show, don't just tell.

With Fred Wilson's quote in mind, it's demo time!

(This is where I do a condensed, approximately two minute version of my Twilio five minute live-coded demo. For a rough approximation of what I showed, check out the NY Tech Meetup Twilio demo from 2010.)

That demo represented the Twilio 5 minute demo from 2008 through part of 2011, when the phone calling voice API was the company's main product.

Let's break down the demo into its component pieces so we can learn from it. The demo narrative fits into a story arc. Yes, a story arc like from a novel. You may not have thought about explaining and showing your product in a couple of minutes to be similiar to a novel, but you should follow the same narrative structure because it is easier for the audience to understand.

1. software developers: a clear call out to who we are talking to
2. phone calling: what problem we solve by adding this feature to applications
3. programming languages that you already know: emphasizing that you do not have to learn some complicated proprietary syntax from the telecommunications world

Next in the exposition, we explain how it works using a diagram that shows inbound and outbound phone calls and how they interact with Twilio's service as well as your web server.

The inciting incident during the demo happens when I finish the explanation of how Twilio works and say "rather than just show you a little diagram, let's build an application together right now".

We move into the demo phase where I buy and configure a phone number then we all test it by calling the number on our own cell phones. The audience learns that to configure the phone number to do something useful in this case only requires two XML elements that can be stored in a static file or generated by an endpoint in their application.

The climax hits when we see outbound phone calling, everyone's phones in the room start ringing and we are all on speaker phone together. Finally, there is a short resolution where I re-explain what Twilio can do for developers and outro with my name and where you can find me.

The whole two minute demo, or however long we need it to be, has a narrative with a clear story arc.

In 2011, Twilio added SMS. This changed the 5 minute demo's explanation to "Twilio makes it easy for developers to send and receive text messages and make and receive phone calls using the programming languages that they already know". The overall structure otherwise remained the same because we used SMS for inbound action and kept phone calling for the outbound action.

Eventually your product line or features within a product line will reach a point where you need to determine if it changes your explanation and demo. In some cases there will be modifications that fit within the existing framework and do not substantially change the narrative.

As you continue to grow you will eventually reach an inflection point where you have too many products or features to explain, regardless of how much time you have for your demo. You reach a situation where if you try to tell the audience everything that your product does, they will zone out and ignore your laundry list of features.

If you are not intentional in the words you say and specific in the products and features you choose to show, then your pitch becomes spread too thin and no developer will care to listen.

Twilio now has dozens of products under the communications umbrella. I talk about specific products and tailor my explanation based on the audience. You should too! For example, if I am talking to a group of web developers, I will still use the classic Twilio 5 minute demo that shows off SMS and phone calling capability. On the other hand, if I am demoing to iOS and Android mobile developers then I will show off Programmable Chat or Programmable Video.

The explanation is tuned to "Twilio makes it easy for developers to add communications, such as phone calling, messaging and video, to their applications using the programming languages that they already know." I draw a broad theme by saying the word "communications" then give three specific examples of products that are the most widely used by developers because they are incredibly useful for implementing common application features.

It's time to reinforce why it is so important for you, as a founder, or as an investor that works with founders, to be the chief evangelist for your product. You cannot ever outsource this role. You cannot hire someone to lead an evangelism team and expect them to figure it all out for you.

If you are not excited about the product you are building or are unable to transfer that excitement to developers with a clear explanation and demo, then all of the other priorities for your company become useless. If developers are your customers and they do not adopt your product then you will not sell anything, you won't be able to set a great company culture and you won't need to worry about what snacks are stocked in your office's kitchen. If developers are the lifeblood of your company then you need to be the chief evangelist, period.

Here are a few more important points for how to perform this role effectively.

When you are early stage, be as specific as possible about what problem that you are solving. You are not "disrupting transportation by blah blah blah". No developer gives a shit. They want to know what problem you will solve for them right now.

Be specific, like the "add phone calling to your applications" line so that it is absolutely clear what you do.

When your company grows and your brand expands, then you may expand to include the general industry your company works in, such as "communications". Do not jump the gun in trying to become too grandiose with your ambitions because your developer audience cares about what problem you are solving for them, not who you imagine yourself to be in your future vision.

Refine the explanation you use and the demo under two situations.

First, when your products and features expand. Think critically if a new feature should be part of your explanation or it can be left as an answer to follow up questions that a developer asks you.

Second, developer ecosystems are constantly changing. If you tried to talk to me about containers ten years ago and I was not a Solaris sysadmin then I would not have any clue what you are talking about. Today, it's generally safe to assume most Bay Area developers have a working knowledge of what containers are and what they are useful for accomplishing. Use that type of context in your pitch to reinforce your technical credibility with your developer audience.

I get asked a lot about live coding because everyone is worried about demo fails. You should not demo fail, ever. To steal a line from Rob Spectre, former head of the Twilio Developer Network:

There is only one demo God, and her name is rehearsal.

You do not just rehearse and practice the happy path, you also practice what can go wrong. What happens when you mistype a character in your code? Find out and get used to it. If and when it happens during your live demo then you can incorporate that mistake into your narrative as a learning opportunity for the audience.

Magicians always have "outs" in their acts, essentially plan B, plan C, plan Z. You should too because something will always go wrong but if you are ready for it and know how to handle it then you will never demo fail.

That sums up my strong recommendations for this one small slice of the field of developer product adoption. To re-iterate, create a narrative for your explanation and demo that follows the classic story arc. The earlier you are as a product, the more specific your explanation should be in what problem you solve. Refine the message as your features and product lines grow, as well as when the industry around you changes. Rehearse your demo including what can and will go wrong.

There is a lot more to developer adoption than a good explanation and demo, but I see greater than 90% of companies never even get to this point so you will be way ahead of the pack if you heed the advice from this talk.

That's all for today. My name is Matt Makai, I am a software developer at Twilio and the author of Full Stack Python. Thank you very much.