How to demo software

The demo starts out nicely enough...

In a dark conference room, the vendor lays out a simple user scenario and starts walking me through the experience. But before he gets to the second click, he needs to mention the cool feature that he isn't clicking on, which leads to a short discussion of the underlying technology, which evolves into a few key points about their design process. When he finally finishes telling me about their unique value proposition and returns to the screen, I can't remember anything about the scenario, which is irrelevant anyway, because now he's running through the menu bar telling me about each of the features.

The thing that's screwed up about this story is that the story gets lost.

Stories are perhaps our most powerful tool when demo'ing software. As human beings, stories grab our attention--we can't help it. Stories are sticky. They stick in our minds much more than explanations, descriptions, or data, and once they get into our brains, all kinds of powerful things start to happen. We intuitively fill in gaps in the narrative; we make connections with other parts of our lives, and--very importantly--we remember. If you want your audience to remember what you said, tell a story.

A good story tends to have some typical components that can all be included quite easily in a software demo, even in a short demo that lasts only 60 seconds. Be sure to include:

1. The main character, your user--give him or her a name (let's use "Bored Bob")
   
2. The setting/context--when and where is Bob using the software (Bob's at home, sitting on his couch with his laptop on the coffee table and the tv on across the room)
3. The central conflict--every story needs a conflict, and for demos, the conflict is usually a problem the user is having that the software will help solve (Bob wants to go to a movie, but he doesn't know which movie to see)
4. The plot--what happens (Bob googles "movies near me" and clicks on my web site. He starts by browsing through a list of new releases, gets drawn into a couple of previews, purchases a ticket for the one he wants, and buys the soundtrack on a whim.)
5. The resolution--in a demo, this is the "so what" part--what are the benefits to Bob and to the owners of the software? (Bob loves his movie and finds a new favorite musician on the soundtrack; my movie site grabs a customer that would have otherwise gone elsewhere, and we make an extra $5 profit from the soundtrack sale)

Five elements sounds like a lot, but it doesn't have to be. Here's what we ended up with in my simple example:

Bored Bob is at home, sitting on his couch with his laptop on the coffee table and the tv on across the room. He wants to go to a movie, but he doesn't know which movie to see, so he googles "movies near me" and clicks on my web site. He starts by browsing through a list of new releases, gets drawn into a couple of previews, purchases a ticket for the one he wants, and buys the soundtrack on a whim. Bob loves his movie and finds a new favorite musician on the soundtrack. And my movie site grabs a customer that would have otherwise gone elsewhere, and we make an extra $5 profit from the soundtrack sale.

A good demo of my web site will tell this story very early on and, very importantly, without interruptions. If I stop the story to explain a feature or why we did something the way we did, the story gets lost--much better to tell the story beginning to end, simulating Bob's experience on the screen, and then go back for explanations and details. When I'm done with the story, I can talk about the incredibly cool matching algorithm we developed to push the right movies to Bob, and the subtle up-sell techniques that prompted him to buy the soundtrack, and the projected increase in revenue due to these enhancements. Those are important things to tell my audience about, but they should never detract from the star of the show.

The star of any great demo is the end user experiencing the product.