Product Demos for Dummies
This post originally appeared on BetterProjects.net on April 14, 2010.Something I’ve been doing a lot of recently is giving product demos for a new packaged software application my company is considering for purchase. Because I was the lead in requirements elicitation for the project, I was kept on to manage the requirements for the implementation phase as well. Because the gap process required someone who knew the requirements inside and out to participate, I spent a lot of time learning the potential software applications as well. Once a vendor was tentatively selected, I ended up being the logical person to demo the solution to the user community.
What I didn’t realize at the time is that I would end up giving the exact same 5 minute demo dozens of times over the course of several days. I’ve done this same demo so many times now that I’m better at doing it than are the employees of the vendor!
I’ve given demos for all kinds of software packages over the years, so I’ve had a lot of practice finding ways to give an interesting and informative demo to people with a limited amount of time to listen. Too many people have presented a bad demo by not giving me the right type or amount of information. Seeing so many bad demos has made me very conscious of not making the same mistakes I see from others. What follows are my ‘rules,’ gleaned from sitting through many bad demos, for giving a great demo.
Do Your Homework
Before you show up to give the demo, understand the audience who will be in attendance. If you’ve got a mostly technical crowd, don’t waste half your demo time on a company overview. If you’ve got executives, don’t dip into technical details that differentiate your platform from the 400 other vendors in your market segment. If you’ve got a mixed audience, try to bring something for both, but not so much of either that you lose everyone.
It is tempting to show off the whiz/bang functions of the application, especially the ones that make the audience oooh and aaaaah like they’re watching a July 4th fireworks display. Include these items only if they can directly build the case that the application you are demoing can directly improve the lives of the audience. Don’t waste time showing items that are irrelevant to the subject at hand, no matter how cool they might look.
Consider making a short list of 'anchor points’ for your demos. These are items that you know will be of extreme interest to the audience and must be included for the demo to be a success. Having a list of these items will help you to focus on what is important when you start to write your demo.
Script It then Rehearse It
Once you know what you’re going to say, you need to know how you are going to say it. The best thing you can do, especially if you’re new to giving demos, is to write out the demo. I’m not suggesting you outline it, although you might start here, but write it out word for word how you plan to say it. User your 'anchor points’ as a starting point. Place the points in logical order and then add in the appropriate and necessary details for each point.
Once the demo is written, practice saying it out loud. Talk through the entire demo without the system in front of you. You’ll quickly realize that while some things make a lot of sense when written out make no sense when you have to say the words. Time your demo and see how long it is in comparison to the time you’ll have to present it, then adjust the text accordingly.
When you know you’re comfortable with the words, add in the demo system. Walk through the demo at least half a dozen time from start to finish with no breaks in the flow. Ensure that your demo environment is configured correctly and matches the flow of your speech. Don’t get caught trying to demo something that doesn’t actually work. You’ll lose creditability with your audience by spending precious minutes trying to figure out why that really cool thing just won’t isn’t working right.
The last step in preparation is to give the demo to your peers. Grab some coworkers and pull them into the room with you. Ask them to write down the areas you did well and the areas that need some additional polish. Take their feedback and incorporate those changes into your demo. Make sure that the audience includes both people who are familiar with the system and processes you’re covering along with people who have little to no idea what you’re talking about. You need multiple viewpoints to be able to accurately assess if your presentation will be understood by all in attendance.
Lights, Camera… Action!
You’ve researched, you’ve written, you’ve practiced and now the doors are about to open, releasing a flood of stakeholders into your midst. It is now prime time and all eyes are on you. Don’t make them cut to a commercial early just to get you off the stage!
Remember that this is your demo; you own it and are responsible for it. Cover the content you need to cover and don’t get distracted into politics or let someone bully you out of the way. Stand-up comics don’t let audience members take over their show and neither should you. Make sure you know how and when to correctly interrupt someone asking a question and how to draw out a question from a person who is having trouble articulating their thoughts.
Even the best moderators will occasionally still be derailed from their script. If the subject brought up is pertinent to the demo and you are prepared to speak to it, then by all means, do so. You’re there to meet the needs of the audience, so answering questions they all have is usually a good idea, provided you answer in a way that doesn’t simultaneously torpedo your presentation.
Its always nice to have a few 'extras’ items you can show off if no one asks questions and the scheduled demo ends early. Because these 'extras’ are not part of the official demo, you don’t lose anything by leaving them out of the script.
My last suggestion is to always leave a little time for questions at the end. If no one has any questions, you can always dip into your 'extras’, you can release the crowd or you can even ask them to come up and test drive the application themselves. The last option works especially well if you have a good ratio of systems to people, the closer to even the better.
What about you? What suggestions do you demo pros out there have for the rest of us?
Image courtesy of bestofasseenontv.com.
