A Twilio evangelist stands at the front of the room expectantly, as a hacker quickly taps ten digits into their phone and sends a text message. A minute later, every phone in the room erupts in a chorus of ringtones. The audience is witnessing one of the best API demos in the world, and participants are eager to hack.

API demos can be the best or worst part of a hackathon. Participants are all sitting in a room, probably hungry, and almost definitely bored, waiting for opening ceremony to end so they can start hacking. Then, someone stands up at the front of the crowd and demands everyone give them five minutes of attention. They might drone on and say nothing, wasting everyone’s’ time, or they might show something cool, inspiring hackers they can build anything.

Twilio arguably set the gold standard for API demos. They created something that converts like crazy and years later, people still call it the perfect product demo. It inspired my own live code demo at SendGrid.

Demos like this see a response like no other. They engage, invigorate, and create followers. They feel like magic.

A few simple steps can help you create one of the most memorable product demos for your next hackathon.

Introduction

Start by Introducing yourself, your product, and what it does, quickly and clearly.

SendGrid is a API for developers to send and receive emails easily.

Then move on to what you plan to do.

Slideshows are boring, so I thought I’d show you some live code. I’m going to jump into my text editor…

Live Code

Live code is all about showing rather than telling. No one wants to watch a Powerpoint presentation if they can see your hack in action.

In fact if Powerpoint is open, you’ve already failed.

Live code doesn’t mean a 200-line script in Eclipse that you mouse over. In fact, if you have Eclipse open you’ve already failed.

Live code does not mean boilerplate that you insert two lines into. In fact if you have code preloaded on your screen before your demo starts, you’ve already failed.

Live code means creating a script from scratch (or seemingly so). You can use boilerplate code, but you need to include/require it. You shouldn’t show a mess of code and comments. Remember: you’re trying to create something that’s easy to follow and feels attainable.

Your code shouldn’t be longer than can fit on screen at a glance (about 15 lines). It should do something obvious and be clear about how it does it.

Hook & Banter

Watching someone type is boring. It’s your job to make it exciting.

I gave high energy demos with an excess of jokes. That worked for me, but you should find your own voice. Some offer coding facts coding and development tips. Others tell anecdotes.

1090955_807308475986499_6541452912041276273_o-1

Product Facts

While talking and typing, make sure you’re giving product facts. Every line of code has an explanation that can tell people more about your product.

“web” tells SendGrid we’ll be using the “Web API”, we have two different APIs, “web” and “SMTP”.

The audience will disregard most of these, but a few will stick.

Audience Participation

Audience participation is what turns a presentation into an experience. It’s the secret sauce to a winning API demo. No matter your product, you can add audience participation. Microsoft shoots T-Shirts at you, Twilio calls you, SendGrid has you play bird calls.

Pro tip: Whenever possible, try to engage folks who aren’t participating. This is easier than it sounds. For example, even if someone in the audience doesn’t text Twilio, the person sitting next to them might, so when Twilio calls back, everyone is engaged by virtue of proximity.

Fallbacks

Inevitably, your demo will fail. You’ll miss a semicolon, the internet will go down, or worse, your API will have “unplanned maintenance” five minutes before the demo (all true stories). Plan for it and you’ll be fine.

Having fallbacks for when you or your product mess up will ensure you always give a great demo.

I also make sure to have a repertoire of jokes on hand for failures and know all the places my code could potentially fail so I can debug quickly.

Pro tip: bugs are a great way to engage the audience. Developers like to be right. Everyone will start yelling and pointing out where your mistake is.

Call to Action

You’re not just demoing because it’s fun. You want adoption, so make sure you give developers a clear call to action

Go to hack.sendgrid.com to signup for a free account.

Follow Up

Demos are great, but even the best demo can be forgotten once participants are hacking.

If you collect contact information during the demo, follow-up with the participants once they’ve started hacking. Give them directions on how to get going and how to get in contact. adds a personal connection, opens a support channel, and reminds participants of your API.

IMG_9488

Trackability

If you can track your demo, you’re even better off. Most links I gave during demos were links I only gave during demos, so we were able to track the conversion rate. If you can track a conversion rate, you can track some very basic, very fuzzy revenue numbers.

Practice

The key to a live demo is practice. You should be able to type your code with your eyes closed while having a conversation with someone else. You should be able to spout your spiel with perfect timing while unicycling.

My first day on the job at SendGrid, Swift told me:

The first time I gave my live demo, I spent the night before reciting it to myself for hours. The bartender thought I was crazy.

Practice will make your timing perfect, it will make your demo flow and ensure participants stay engaged.

Remember, your live demo may be the first and only time someone sees your product. Make sure it sticks in their mind as a great experience.

 

Today, I’m proud to work with some of the best evangelists and live demo experts in the world. If you want to talk more about how to do a product demo, email us hi@mlh.io.

Related posts:

No related posts.