Five Tips For A Great Software Demo

Whether you need to close a sale, gather end-user feedback, show progress to your customer, or simply explain how your product works, sooner or later, you will need to demo your software product.

Over the years, I've had the opportunity to perform hundreds of demos to audiences of various sizes. I've also had the chance to attend demos hosted by others. The following represent the top 5 tips I've learned over the last decade regarding demos.

Manage Your Audience's Expectations

Have you ever gone to see a movie everyone raved about and walk out totally disappointed? More often than not, moviegoers feel let down not because the picture was bad, but rather because it was worse than they anticipated. It didn't meet their expectations.

Similarly, if people show up to a demo thinking they're about to see a finished product, they expect it to be virtually defect-free, aesthetically pleasing, and user-friendly. They wouldn't be impressed for example with a Web-based application that contains typos or JavaScript errors if they're under the impression it's going live in a week. However, if they know beforehand that you're presenting a throwaway prototype, this same audience will be much more lenient. And they will gladly provide much-needed feedback to help you with your work in progress.

Managing your audience's expectation is critical to a successful demo. If you want them to walk away from your presentation pleased, make sure you set the right expectations beforehand. Be honest with them. Don't try to oversell your demo. Just sell it, and try to over deliver.

One Bad Apple Spoils The Whole Bunch

All it takes to screw up a demo is one person. If someone starts negatively critiquing every single widget in your application or constantly interrupts you simply because he/she likes to hear the sound of his/her own voice, your demo will be a disaster. It is your job to ensure that these bad apples don't show up to your presentation.

Unless you're hosting a closed-door demo, it's very hard to control who will attend it. Omitting someone from your invitation list doesn't guarantee they won't hear about your demo through word-of-mouth and simply show up.

Here are a couple of ways to trick bad apples into not attending your demo:

• Create a scheduling conflict for those bad apples. Make sure they are busy, or better yet, out of the office when your demo takes place.
• Book two separate demos. Invite the people whose feedback you truly value to the first demo and the bad apples to the second. More often than not, each group will show up to the demo they're respectively invited to. When it's time for the second demo, go ahead and give it your best shot, or if you don't have time, simply cancel it.

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

Do A Practice Run

I attended a demo last week hosted by the CEO of a local start-up. After meeting with him at a trade show, he managed to convince me that his company had developed a technology that could solve one of my client's needs. I therefore agreed to give him 30 minutes of my time so he could demonstrate his product's capabilities.

I didn't need 30 minutes to realize I didn't want to do business with him. All I needed was 30 seconds.

This guy couldn't even log in his own Web-based application! He spent the first 10 minutes of the demo looking for a password.

Always do a practice run on the system that you're going to use during the actual demo. You might know the application like the palm of your hand, but if someone else has access to your demo system, who knows what shape it's in. They might have removed services, upgraded components or, as was the case with this CEO, changed the user credentials without informing you.

Unless you don't mind looking like a fool, always do a practice run on your demo system before presenting to your audience.

Pay Attention To Details

The hundreds of demos I've performed over the years have taught me that people pay more attention to how the application looks than what it does. You software might 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. Deal with it by carefully reviewing the text on your interface and in your graphics. If you don't have the time to review and finalize the text, use Lorem Ipsum.

Lorem Ipsum has a more-or-less normal distribution of letters, thereby making it look like readable English yet not distracting your readers. I now 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 subject of discussion at my next demo. I strongly advise you to do the same.

Point Out The (Obvious) Bugs

Software contains bugs. It's that simple. Anyone who doesn't agree with that statement clearly hasn't worked in the software industry for long. Although we sometimes strive for defect-free products, reality is complex systems always contain defects - even when they're generally available.

Doing a practice run before your demo will allow you to identify and resolve the showstoppers, and using Lorem Ipsum will deal with the nitty-gritty details that would otherwise distract your audience. But what about the other defects attributed to Murphy's Law?

In the event that an obvious bug does display itself during your demo, point it out!

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

Point out the bug, explain that you have a solution, confidently state that the fix will be implemented by a specific date, and move on. This sincere behavior will reassure your audience that (a) you're not trying to sweep one under the rug and (b) the defect will be resolved by the time they deploy your system.

I'm not advocating that you go hunting for bugs during your demo. If you can circumvent them by any means, please do so. But if a defect does surface during your presentation, don't pretend it doesn't exist. The only person you'll be kidding is yourself.

Conclusion

There you have it. Five tips for a great software demo.

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

Luc Richard holds an MBA with a major in high technology. For the past 10 years, he's been managing the development of software applications. He is the founder of The Project Mangler (http://www.projectmangler.com), an online resource that publishes free articles, stories, and other ready-to-use tools to help developers, team leaders and managers deliver software projects on time, according to specs, and within budget.