Demo tips for software

Whether you need to close an offer, gather user feedback, demonstrate progress to your customer, or simply explain the way your product functions at some point or another, you will require a demo of your software.

Over my career, I’ve had the opportunity to present hundreds of demos to audiences of different sizes. I’ve also had the chance to take part in demos organized by other individuals. These are the top 5 tips I’ve picked up over the last decade about demos.

Manage Your Audience’s Expectations

Have you ever been to see a movie that everyone has raved about only to walk away completely disappointed? The majority of the time moviegoers are disappointed, not because the picture was bad however, it’s because it was worse than what they had hoped for. It did not meet their expectations.

Similar to when people show at a demonstration link shortener believing they’re about to see the final product, they’ll expect that it’ll be flawlessly perfect, beautiful, and user-friendly. They wouldn’t be impressed for example with a Web-based application with typos or JavaScript mistakes when they’re under the impression that it’s going live in just a week. But, if they’re aware beforehand that you’re presenting a throwaway prototype, the same public will be more accommodating. They’ll be more than happy to give much-needed feedback to help you in your ongoing work.

The ability to manage expectations of your audience is critical to the success of your presentation. If you want your audience to leave your presentation feeling satisfied it is important to establish the right expectations beforehand. Be honest with them. Don’t try to oversell your demonstration. Sell it as it is, and do not make sure you over deliver.

One Bad Apple Spoils The Whole Bunch

The only thing needed to mess up a demo is one person. If someone starts negatively critiquing every single feature of your application or constantly interrupts you simply because he/she likes to hear his/her own voice, your demo is likely to be an absolute disaster. It’s your responsibility to ensure that these undesirable individuals don’t make it to your presentation.

If you’re not hosting a closed-door demonstration, it’s a challenge to determine who’s going to attend the event. By removing someone from your invite list isn’t a guarantee that they won’t be aware of your demonstration through the media or simply show up.

Here are two methods to entice bad apples into not attending your demo:

Create a scheduling conflict for the bad apples. Make sure they are busy or even out of the office when your demo begins.

Book two separate demos. Invite the people whose feedback you value to the first demo and those who have bad ones to the next. In most cases the two groups will show at the demo they’ve been invited to. If it’s time to go to the second demonstration try giving it your best shot or, if you’re not able to make the time, simply cancel it.

I’m fully aware that these two tips are reminiscent of an extract from Scott Adams’s Dilbert And The Way Of The Weasel, but unless you’re comfortable telling your peers, superiors or clients not to come to your demonstration, these two options are pretty much the only options you have.

Do A Practice Run

I was able to attend a demonstration this week, which was hosted by the CEO of an established local startup. After having a conversation with him at a trade show he managed to convince me that his company had developed a technology that could solve one of my clients’ needs. I also agreed to allow him 30 minutes of my time so that it could demonstrate the product’s capabilities.

I didn’t require 30 minutes to realize I didn’t want to deal with him. The only thing I required was a few seconds.

The guy was unable to log into his own online application! He spent most of the demo trying to find a password.

Always do a practice run on the machine you’ll be using during the actual demonstration. You may be familiar with the application as well as the palm of your hand, but in the event that someone is able to access your demo system, you don’t know the state it’s in. It could be that they have removed features, updated components, or, as was the case with this CEO the user’s credentials without notifying you.

If you’re not afraid of looking like a fool, you should conduct a practice session on your demonstration system prior to speaking to your audience.

Pay Attention To Details

The hundreds of demonstrations I’ve conducted throughout my career have taught me that people pay more pay attention to how an application appears than to what it does. The software you choose to use could provide a solution to the world’s hunger but if a member of your audience spots a mistake in your GUI then they’ll point it out!

The attention span of readers is heightened with text-based content, and it’s true. Deal with it by carefully reviewing the text on the interface and within your graphic designs. If you don’t have the time to finish reviewing and rewriting the text, make use of Lorem Ipsum.

Lorem Ipsum features a more or less normal distribution of letters, creating a look that is readable English but not distracting your viewers. I now develop new designs using Lorem Ipsum. I add text only when I have time to write content I know isn’t going to be the topic of discussion at my next demonstration. I strongly suggest that you follow the same procedure.

Point Out The (Obvious) Bugs

Software contains bugs. It’s that straightforward. If you don’t agree with this statement isn’t in the software business for a long time. Although we’ll often try to make defect-free products, reality is that all complex systems have imperfections, even when they’re widely available.

Conducting a test run prior to the presentation will enable you to identify and resolve the showstoppers, and using Lorem Ipsum, you can deal with those small-scale details that could otherwise make your audience uncomfortable. What about the other defects attributed to Murphy’s Law?

If an obvious bug manifests it during your demo Please be sure to point it out!

The majority of your readers will have noticed the bug. Any attempt to cover it up could give the impression that you’re not truthful. In turn, they’ll begin to consider what else you’re trying to cover up.

Highlight the problem, explain that you have a solution, be confident that the fix will be implemented by a specific date, and move to the next step. This sincere behavior will reassure your customers in the knowledge that (a) you’re not attempting to sweep the issue under the carpet and (b) the problem will be addressed in the near future, when they launch your system.

I’m not suggesting that you look for bugs during your demonstration. If you’re able to avoid them by any means you can, do it. If there is a problem that does show up during your presentation, don’t try to pretend it doesn’t exist. The only person you’ll be making fun of is yourself.

Conclusion

That’s it. Five tricks to make a great demo of software.

Set the expectations of your audience

Make sure that bad apples don’t ruin the bunch

Make a practice run

Pay attention to all the finer details and use Lorem Ipsum

Make sure you spot the obvious bugs

Do these 5 tips represent all I’ve learned over the hundreds of demos I’ve conducted? Absolutely not! The toughest part of writing this article was condensing it to just 5 points. It would have been easy to throw five more suggestions such as (a) control the situation, or (b) always have a plan B. However, my goal was to not give all the suggestions to help you. Only the very top five!

Related Posts

Leave a Reply

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