How to demonstrate your software

Whether you need to close the sale, collect user feedback, display progress to your customer or simply demonstrate the process of your software in the near or distant future, you will have to demonstrate your software.

Over time I’ve had the chance to present hundreds of demos for audiences of varying sizes. I’ve also had the opportunity to take part in demos organized by other individuals. The following list of tips are the top 5 lessons I’ve learned in the past decade in regards to demos.

Manage Your Audience’s Expectations

Have you ever gone to see a film everyone talked about and come out completely disappointed? More often than not, moviegoers aren’t disappointed because the film was bad or not good, but because it was more disappointing than they expected. It didn’t meet their expectations.

Similarly, if people show for a demo scan to pay signs believing they’re about to see an actual product, they’ll expect it to be virtually perfect, beautiful and user-friendly. They wouldn’t be impressed by a web-based application that has typos or JavaScript mistakes when they’re under the impression that the application will be live in just a week. However, if they know beforehand that you’re showing a non-existent prototype, the same audience will be more accepting. They’ll be more than happy to give valuable feedback that will help to improve your work.

The ability to manage expectations of your audience is critical to the success of your presentation. If you want them to leave your presentation pleased be sure to set expectations for them prior to the presentation. Make sure you are honest with them. Do not try to sell your demo. Make it easy to sell it, and never strive to deliver it to the max.

One Bad Apple Spoils The Whole Bunch

The only thing needed to mess up a demo is just one person. If someone starts negatively critiquing every single widget in your program, or keeps interrupting you simply because he/she likes to hear the voice of their own, your presentation will turn into an absolute disaster. It’s your duty to ensure that these undesirable individuals don’t make it in your demo.

Unless you’re hosting a closed-door demonstration, it’s difficult to determine who’s going to attend the event. By removing someone from your invite list does not mean that they won’t be aware of your demonstration through word-of mouth and then attend.

Here are some ways to deceive the uninitiated into not attending your demonstration:

Make a schedule conflict for those who have a bad attitude. Make sure they are busy or even away from the office during the time your demo begins.

Book two separate demos. Invite those whose opinions you truly value to the first demo and the bad ones to the next. In most cases all of them will show to the demo that they’re respectively invited to. If it’s time to go to the second demo try giving the best you can, or, if you’re not able to make the time, you can simply postpone the demo.

I’m aware that these two tips are reminiscent of an extract taken from Scott Adams’ Dilbert And The Way Of The Weasel But unless you feel comfortable telling your peers, superiors or clients to not come to your demo the two choices are the only options you have.

Do A Practice Run

I went to a demonstration last week which was hosted by a CEO of an established local startup. After meeting him at a trade fair, I was convinced that his company had developed a solution to one of my clients’ needs. I agreed to grant him 30 minutes of my time , so he could demonstrate his product’s capabilities.

I didn’t have to wait for 30 minutes to decide that I didn’t want to conduct business with him. All I needed was just 30 seconds.

The guy was unable to log on to his own application that runs on the Web! He spent most of the demonstration looking for a password.

Always practice running on the system you’re going to use during the actual demo. You might know the application like the palm of the palm of your hands, however if someone else has access to your demo system, you don’t know what condition it’s in. They could have removed the services, updated components or as happened with this CEO the user’s login credentials without telling you.

Unless you don’t mind looking like a fool, try a run-through on the demo system prior speaking to your audience.

Pay Attention To Details

The hundreds of demos I’ve given over the years has taught me to pay greater pay attention to how an application looks than what it does. The program you’re using could provide the answer to hunger however if one of your target audience spots a glitch in your GUI and points it out, they will highlight it!

People are particularly distracted by readable content – as a matter of fact. Be aware of this by carefully reading the text on your interface and in your graphic designs. In the event that you do not have time to go through and edit the text, then use Lorem Ipsum.

Lorem Ipsum displays a regular distribution of letters, thus making it look like something that is readable English but not distracting your readers. I’m now developing new prototypes exclusively using Lorem Ipsum. I also add real text when whenever I am able to create content that I am sure won’t become a subject of discussion during my next demonstration. I strongly recommend that you use the same method.

Point Out The (Obvious) Bugs

Software contains bugs. It’s that easy. Anyone who disagrees with this statement hasn’t been in the software business for a long time. Although we’re often looking for defects-free products, the reality is that complex systems will always have imperfections, even when they’re generally available.

Conducting a test run prior to the presentation will enable you to pinpoint and eliminate issues that cause the most trouble, and using Lorem Ipsum to deal with those small-scale details that could otherwise make your audience uncomfortable. But what about the other flaws that are attributed to Murphy’s Law?

If you discover an obvious bug manifests itself in your demo Make sure you make sure you point it out!

Most likely, your target audience has already seen the problem. Any attempt to conceal it will make them believe that you’re not sincere. They’ll then consider what else you’re trying to hide.

Find the issue Explain that you have a solution, affirming that the fix will be implemented on a particular date and then move ahead. The sincere approach will convince your customers to know (a) that you aren’t trying to sweep it under the carpet and (b) this issue is going to be solved when they implement your system.

I’m not suggesting that you search for bugs during your demo. If you can circumvent them by any means then do it. But if a defect does show up in your presentation, don’t make it appear as if that it’s not there. The only person you’re in the wrong is you.


There you have it. Five ways to create a memorable demo of software.

Control the expectations of your viewers

Check that bad apples do not end up ruining the whole bunch

Do a practice run

Pay attention to all the finer details and use LoremIpsum

Note the obvious bugs.

Do these 5 tips represent everything I’ve learned from the hundreds of demos I’ve conducted? Absolutely not! The toughest part of writing this article was probably condensing it to just 5 points. I could have easily thrown five more suggestions for example: (a) take control of the situation in addition to (b) always keep a backup plan. But the goal wasn’t to point out all the tips that can help you out. Just the top five!

Add a Comment

Your email address will not be published. Required fields are marked *