Whether you need to close a sale, secure end-user feedback, show progress to your customer, or naturally clarify how your stock works, sooner or later, you will need to demo your software product.
Over the years, I've had the opportunity to accomplish hundreds of demos to audiences of discrete sizes. I've also had the opportunity to attend demos hosted by others. The following laid out the top 5 tips I've learned over the last decade concerning demos.
Office Outlook Web Access
Manage Your Audience's Expectations
Have you ever gone to see a movie every person raved about and walk out totally disappointed? More often than not, moviegoers feel let down not because the photo 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 complete 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 furnish much-needed feedback to help you with your work in progress.
Managing your audience's expectation is indispensable to a flourishing 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 man starts negatively critiquing every singular widget in your application or constantly interrupts you naturally 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 man from your invitation list doesn't warrant they won't hear about your demo through word-of-mouth and naturally show up.
Here are a merge 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 great yet, out of the office when your demo takes place.
- Book two detach 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, naturally cancel it.
I'm well aware that these two tips sound like an extract 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 industrialized 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 company 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 law that you're going to use while the actual demo. You might know the application like the palm of your hand, but if man 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, all the time do a practice run on your demo law 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 considered reviewing the text on your interface and in your graphics. If you don't have the time to chronicle and finalize the text, use Lorem Ipsum.
Lorem Ipsum has a more-or-less normal distribution of letters, thereby development it look like readable English yet not distracting your readers. I now create 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 field of seminar at my next demo. I strongly propose you to do the same.
Point Out The (Obvious) Bugs
Software contains bugs. It's that simple. Anything who doesn't agree with that statement clearly hasn't worked in the software manufactures for long. Although we sometimes strive for defect-free products, reality is complex systems all the time comprise defects - even when they're generally available.
Doing a practice run before your demo will allow you to recognize 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 inevitable bug does display itself while your demo, point it out!
In all likelihood, your audience will have already noticed the bug. Any effort 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, clarify that you have a solution, confidently state that the fix will be implemented by a definite 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 flaw will be resolved by the time they deploy your system.
I'm not advocating that you go hunting for bugs while your demo. If you can circumvent them by any means, please do so. But if a flaw does face while your presentation, don't pretend it doesn't exist. The only man you'll be kidding is yourself.
Conclusion
There you have it. Five tips for a great software demo.
- Manage your audience's expectations
- Ensure that bad apples don't ruin the bunch
- Do a practice run
- Pay attention to details and use Lorem Ipsum
- Point out the inevitable bugs
Do these 5 tips laid out all I've learned over the hundreds of demos I've hosted? absolutely not! The hardest part about writing this report was probably limiting it to 5 tips. I could have absolutely thrown in 5 more tips such as (a) control the situation, and (b) all the time 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!
Five Tips For A Great Software DemoHouse Session 2011-07-18 (20:43:40-21:31:53) Tube. Duration : 48.23 Mins.To be announced.
Keywords: C-SPAN
No comments:
Post a Comment