Whether you need to close a sale, gather feedback from end users, show progress to your customer, or simply explain how your product works, sooner or later you’ll need to demo your software product.

Over the years I have had the opportunity to perform hundreds of demos for audiences of various sizes. I also had the opportunity to attend demonstrations organized by others. The following represent the top 5 tips I’ve learned over the last decade regarding demos.

Manage the expectations of your audience

Have you ever gone to see a movie that everyone was raving about and left totally disappointed? Most of the time, moviegoers are disappointed not because the picture was bad, but because it was worse than they expected. It did not meet your expectations.

Similarly, if people show up to a demo thinking they are about to see a finished product, they expect it to be virtually flawless, aesthetically pleasing, and easy to use. They would not be impressed, for example, with a web-based application containing typos or JavaScript errors if they were under the impression that it would be available in a week. However, if they know in advance that you are presenting a disposable prototype, this same audience will be much more forgiving. And they’ll be happy to provide much-needed feedback to help you with your work in progress.

Managing the expectations of your audience is critical to a successful demo. If you want them to walk away pleased with your presentation, be sure to set the right expectations beforehand. Be honest with them. Don’t try to oversell your demo. Just sell it and try to overdeliver.

One bad apple spoils the whole group

All it takes to screw up a demo is one person. If someone starts criticizing every single widget in your app or constantly interrupts you just because they like to hear the sound of their own voice, your demo will be a disaster. It’s your job to make sure these bad apples don’t show up in your presentation.

Unless you’re hosting a behind-closed-doors demo, it’s very difficult to control who will attend. Skipping someone off your invite list doesn’t guarantee that they won’t find out about your demo through word of mouth and just show up.

Here are a couple of ways to trick the bad apples out of your demo:

• Create a scheduling conflict for those bad apples. Make sure they are busy, or better yet, out of the office when the demo takes place.
• Book two separate demos. Invite the people whose feedback you really value to the first demo and the bad apples to the second. Most of the time, each group will appear in the demo they are respectively invited to. When it’s time for the second demo, go ahead and do your best, or if you don’t have time, just cancel it.

I’m well aware that these two tips sound like an excerpt from Dilbert And The Way Of The Weasel by Scott Adams, but unless you’re comfortable telling your peers, superiors, or clients not to show up for your demo, these two options they are pretty much all you have left.

Take a practice run

I attended a demo last week hosted by the CEO of a local startup. After meeting him at a trade show, he convinced me that his company had developed a technology that could solve one of my customer’s needs. Therefore, I agreed to give him 30 minutes of my time so that he could demonstrate the capabilities of his product.

It didn’t take me 30 minutes to realize I didn’t want to do business with him. All it took was 30 seconds.

This guy couldn’t even log into his own web-based application! He spent the first 10 minutes of the demo searching for a password.

Always do a practice run on the system you are going to use during the actual demo. You may know the app like the back of your hand, but if someone else has access to your demo system, who knows what form it’s in. They may have removed services, updated components, or, as was the case with this CEO, changed user credentials without informing you.

Unless you don’t mind making a fool of yourself, always practice on your demo system before presenting it to your audience.

Pay attention to the details

The hundreds of demos I’ve done over the years have taught me that people pay more attention to what the app looks like than what it does. Your software may be the solution to world hunger, but if a member of your audience notices a typo in your GUI, he/she will point it out!

Readers are especially distracted by readable content, and that’s a fact. Address it by carefully reviewing the text on your interface and in your graphics. If you don’t have time to proofread and finalize your text, use Lorem Ipsum.

Lorem Ipsum has a more or less normal distribution of letters, which makes it look like readable English but without distracting readers. Now I develop new prototypes strictly with Lorem Ipsum and add actual text when and only when I have time to write content that I know won’t become a topic of discussion in my next demo. I strongly recommend that you do the same.

Point out the (obvious) mistakes

The software contains bugs. It’s that easy. Anyone who disagrees with that statement clearly hasn’t worked in the software industry for very long. Although we sometimes strive to have defect-free products, the reality is that complex systems always contain defects, even when they are generally available.

Practicing before the demo will allow you to identify and resolve the obstacles, and using Lorem Ipsum will help you with the essential details that would otherwise distract your audience. But what about the other flaws attributed to Murphy’s Law?

In the event that an obvious error is displayed during your demo, please point it out!

In all likelihood, your audience will have already noticed the mistake. Any attempt to hide it will give them the impression that you are not being honest. Therefore, they will start to wonder what else you are trying to cover up.

Point out the bug, explain that you have a fix, confidently state that the fix will be implemented by a specific date, and move on. This candid behavior will assure your audience that (a) you’re not trying to sweep one under the rug and (b) the defect will be resolved when you implement your system.

I’m not suggesting that you look for bugs during your demo. If you can bypass them by any means, do so. But if a defect comes up during your presentation, don’t pretend it doesn’t exist. The only person you’ll be fooling is yourself.

conclusion

There you go. Five tips for a great software demo.

1. Manage the expectations of your audience
2. Make sure the bad apples don’t ruin the bunch
3. Take a practice run
4. Pay attention to details and use Lorem Ipsum
5. Point out the obvious mistakes

Do these 5 tips represent everything I’ve learned from the hundreds of demos I’ve hosted? Absolutely not! The hardest part of writing this article was probably limiting it to 5 tips. I could easily have added 5 more tips, such as (a) control the situation and (b) always have a plan B. But the point was not to point out all the tips that can help you. Only the top five!