The 4 S’s of a Good API Demo

Guy Kawasaki’s “The Macintosh Way,” is packed with good advice and is a quick read that you should absolutely check out. You can get The Macintosh Way as a free download. In it, there’s a chapter called “How to Give Good Demo,” where Kawasaki suggests that good demos should be short, simple, sweet, swift, and substantial, and that starting with a script that satisfies these requirements is the foundation for success.

As sound as Guy’s advice is, we face different limitations than he faced in 1983. Our audiences have a way to tune out a bad demo instantly by grabbing their smartphone and giving their attention to the internet. They aren’t going to go crazy over animated icons like they did in 1983. The bar for creating excitement is higher, because someone in the room is going to pull out Google Glass or an Oculus Rift or a drone or some other awesome future toy that’s way cooler than what you’re trying to show.

Shiny new features aren’t as impressive because users are used to new features being constantly delivered over the air. With this new context and these new challenges, let’s revisit Mr. Kawasaki’s advice and see if we can modernize it:

Short

Kawasaki says: “A good demo lasts about 30 minutes with an additional ten minutes for Q and A – giving you a total length of 40 to 45 minutes.” That doesn’t work in our world. When demoing at a hackathon, you’ll rarely get more than 5 minutes for a demo, and you’ll have to make time to A all the Q’s on your own afterwards. Keeping things short is still good advice, but the definition of short has drastically shifted.

Simple

“A good demo is simple and easy to follow. It should communicate no more than one or two key messages.” This advice was true 20 years ago, and if anything it’s even more important now when faced with short time frames and short attention spans. You need to present your thesis quickly, clearly, and reiterate it several times. If necessary, you can have a few potential messages prepared such as scalability, reliability, and ease of integration. Then focus on one depending on the demographics of the audience.

Sweet

Guy says that a sweet demo “[s]hows the hottest features and differentiates your product from the competition’s.” This is the most subjective and least actionable of Guy’s pillars of a good demo. A sweet demo can take many forms; sometimes you don’t need to show the hottest features, you need to show the most valuable features. If the audience isn’t aware of the problem you can help them solve, then showing basic features but highlighting their importance might be more important than showing the greatest new thing. Sometimes convincing your audience that they are wasting money or missing out on opportunities by not using your product is more important than features or differentiation.

Surprising

So “sweet” is out. Instead, strive to make your demo surprising. With the difficulty of capturing and keeping someone’s attention nowadays, you have to start by making a splash. There’s a lot of ways to do this. We have some evangelists that demo while wearing capes or sunglasses with LED lights in them. Some have used Arduino-based hardware demos even though we’re an email company, because they capture the audience’s attention. Once you’ve got the audience’s attention, keep it by making your demo interactive. Turn the smartphone into an ally by asking people to help you by interacting with your demo from their seats. Award random prizes to those that participate, and tell them you’re going to do this to increase engagement.

Swift

Guy’s next “S” is swift. I’m throwing this one out. In modern evangelism, a fast pace is table stakes. When you’ve got 5 minutes to convince a developer to consider your solution, you damn well better use every second.

Substantial

Guy’s final “S” is substantial. This means your demo should “[s]how how your product builds a solution. Customers want to do things with your product so they want to know how the product works.” This is timeless advice. Show, don’t tell. That’s the whole point of the demo.

Considering how much has changed in the last couple decades, it’s impressive that so much of Guy Kawasaki’s advice has stood the test of time. But now that we’ve explored how to lay the foundation for a good demo in the context of modern evangelism, the script for your next demo should focus on being:

1. Short
2. Simple
3. Surprising
4. Substantial

Those 4 S’s will help you Give Good Demo in the age of SaaS, APIs, and connected audiences.

Quotes from Guy Kawasaki, The Macintosh Way, 1989.