Demo Mastery for the Technology Evangelist

In the same way that the finest presentations involve much more than the simple relaying of information, the finest software demos are much more than just presenting features.  

I've spent the last 10 years learning how to give good presentations and to give good software demonstrations. Here are several tips to take your software demonstration from informative to masterful:

1. Know your audience

Whenever you start a demo, make sure you have a good idea what the audience is interested in. That way you can focus the attention of the audience upon things that actively engage their imagination. You really, really want the audience to be thinking about how they're going to use the software that you are presenting. If it if you're not presenting on something that they're interested in, they'll mentally disengage. In some cases you'll even see them open their laptops and start to answer emails. That's the last thing in the world that you want to happen.

In many cases, I'll begin a presentation by asking my audience to tell me more about themselves. I want to know how much of their time is spent as a developer, as a DBA, as a designer. If nothing else, I can change the sort of examples that I use to be tailored specifically to the audience that are presenting to.

Truly bad software demos have problems. The code doesn't work. The beta software crashes. The screen shows the dreaded blue screen. But that's one thing. What you really want to avoid, is the truly mediocre software demo. The quickest path to a mediocre software demo is to simply show every feature and explain each in as much detail as you can. It's like those games that sit in our closet that no one likes to play. Most all of these games are ones in which one person takes a turn while everyone else waits. No one has any fun except for the three or four minutes in which it relates directly to them.

2. Start, but only start, with an agenda

It's always a good idea to inform your attendees of what you would like to present. What you present the agenda it's a great idea to confirm that this agenda is what the audience is looking for. Before I learned to do this on a regular basis, I found that my presentation might contain two or three lengthy sections of my software demo which were completely uninteresting to the audience.  The customer is really numbed by this waste of time. It's far better to tell the audience what you are going to tell them.

Here's my routine when I start a demo. Confirm that your agenda is of interest to them and recheck the time constraints of the meeting. Then, get to what they are interested in. This flexibility also provides you the opportunity to inject other software demonstrations that are much more pertinent to your audience. Audiences love a presenter who can think on their feet and are flexible to the interests of the audience.

3. Skip the lengthy intro

This is a aspect of demonstrations and presentations that I struggle with. I worried a lot that I hadn't demonstrated enough credibility with my audience. And so for many years of my technology evangelism role, I spent a lot of time telling the audience about myself and about the company. What I found over time though, is that audiences actually give you an initial dose of credibility. It's up to you to maintain and even enhance that credibility through a strong demo and a good presentation. Better to have a very short introduction and get straight to the meat of the presentation.

4. Show what is pertinent

One of the most important things a software evangelist can do is to show the most important and pertinent take away of their software. Let's you are trying to teach an audience about the extreme ROI (return on investment) of a particular kind of business intelligence strategy, it's crucial that you figure out in advance what are the key takeaways that you would like your audience to remember. Typically in audience will only remember two or three very salient points about your demo. If the BI presentation spends the first 30 minutes showing how to build a report but never once mentions ROI, what do you think the audience will remember? Once you know what is pertinent to your audience and what you want the key takeaway to be, you should focus the rest of your energies on building an airtight demo that supports those takeaways.

You will see the inverse of this many times in a mediocre or poor demo. At the end of the demo the audience will feel like they have sat through product training, rather than a call to action that inspires them to use the product. I've sat through demos in which the presenter carefully walk through several different menus, tabs, and wizards. And after 30 minutes of that, I now knew HOW to use the software, but I still didn't know WHY I would use the software.

In the worst cases, showing everything that your software can do may leave the audience feeling that it is too complex, too detailed, or too overwhelming for them to use effectively. Remember that a software demo is not design to train the audience. A software demo is designed to inspire the audience to use your products.

5. Don't get sidelined

We usually get sidelined in our demos by two things: questions from the audience and "technical difficulties" a.k.a. bugs.

Questions from the Audience

It's usually a good sign if your demo is provoking questions from the audience. However, you don't want to demo to turn into free consultation to solve one person's problem. Nor do you want to turn into fact-finding for one very narrow set of interests or to become the arbiter of some sort of political dispute between factions in the audience.

When taking questions, remember to repeat the question to the audience. This ensures that you fully understood the question, that the questioner asked for what they meant, and that if there is any recording going on the question will be picked up by the recording system.

But my typical rule of thumb is to only spend a couple minutes on a single question and questioner. Once a single questioner goes beyond a couple minutes, you can usually tell if you're heading for the sidelines. It's at that point that I asked the questioner if we can take the question off-line and come back to it afterwards so that everyone else can benefit from the time that we have set aside right now.

Technical Difficulties

Another form of sidelining are bugs in the software and outright crashes of your demo environment. Many times this simply can't be avoided. This is especially true if you are demoing a beta version of the software. But there are couple important things to remember if you are sidelined by a bug or crash.

First, mention if you're using a beta and that it might not be fully stable. Also, be sure to mention that the software WAS stable when you prepared the demo. Second, test your demo after conducting a full reboot of your demo environment. I've seen many demos crash because the presenter made other changes in the environment but only tested for the software demonstration itself. Third, Don't draw attention to bugs that you encounter during the demo, especially if they're just cosmetic. It's important not to do things like slap your four head and exclaim "what the hell is that?" If it's a bigger bug that hampers or interferes with functionality, you might state that it's normal functionality is… XYZ. Finally, if you experience a major bug or crash, immediately disconnect the projector or the desktop sharing application. There's nothing worse than seeing a presenter struggle with the bug in front of the entire audience.

6. Hit the jackpot

All good jokes have a punchline. All good action movies have a climax. All good newspaper stories have a headline. Your demo needs to have a jackpot, where the audience can clearly and immediately see how your software pays off.

Let's say you're doing a demo of the new columnstore features in SQL Server 2012. You could spend a lot of time showing the conceptual underpinnings of a columnstore index. You could show the state was to create columnstore indexes, to modify them, to drop them. You could admonish the audience and ways to build read-write systems so that they can easily get data into and out of columnstore indexes.

But what's the real payoff of a columnstore index? It is incredible fast for a particular kind of scenario on SQL Server. So in this example, your jackpot is to show how difficult that scenario is under normal circumstances and then immediately show how easy and fast it is with the columnstore index. Bingo! Your audience is hooked. They immediately see why they want this. There inspired to start using it. Now, they want to figure out how to use it and want to know when and under what conditions they should use.

Are you an SC, technology evangelist, or technology presenter?  What are your tips for a better demo? 

-Kevin

-Follow me on Twitter