There is a moment in bad product demos when everyone knows the speaker is in trouble. We watch them move their mouse, and click a button, and see the uncertainty in their eyes. Will it work? And when it fails, they fall into the downward spiral of live troubleshooting in front of a crowd. How sad. These are often smart people, representing decent websites or products. There is a better way.
Most demos fail for the same reasons. While it’s true demos are a public speaking challenge, with a few pointers anyone can do it well. Here’s a list of the most common mistakes – if you work to avoid them a solid demo experience awaits:
- Don’t trust wifi. When you practice you are likely in your nice office, with great bandwith. Most demos are done in unfamiliar places, where you are sharing web access with dozens or hundreds of people. Plan for slow or no-bandwith. Have a contingency demo that requires no web access at all.
- Really, don’t trust wifi. Even in a great venue, 100 iPhone users will slow all web connections to a crawl. Some venues provide a seperate router for speakers, or a Ethernet cable at the lectern, but most don’t. Ask for it. If they don’t provide it, consider bringing your own (Its worth $200 to your company to ensure your demo does not suck).
- Have a video of you doing your demo. Your default contingency plan for any demo is to have a screencapture of it on video, on your laptop. This means that no matter what goes wrong, you can show the video of the demo. You’ll lose points for it not being live, but people will get to see the demo work properly, which is what they want to see. Your primary goal is to guarantee they get to see something, even if it’s canned.
- Keep it short (Don’t confuse the steps with the payoff). If it takes 10 steps to add a widget to your web app, do you really need to show them all? All the audience wants to see is a couple of steps, and then the payoff. You can skip many of the individual steps. Write a script. Get a developer to make you a custom version that preloads some data. Avoid the dead air of filling out long forms, or waiting for things to load. Keep the demo short and use time to answer questions, or do extra impromptu demos based on questions people have. The key parts should be live code, but not every single step has to be.
- Have a clear, and real, problem to solve. There is a big difference between demoing what a product can do, and showing a working solution to a problem the audience cares about. Know who you are speaking to and pick an example problem they care about it to use in the demo. Don’t resort to just showing off a list of features, that’s an inventory, not a demo. Watch an infomercial (e.g. Shamwow) – behind all the shtick, good infomericals define clear problems and demo how their product solves them.
- Don’t make them watch you type. Typing takes time. Typing is boring. No one wants to watch you type. Find ways to avoid typing and to either fake or skip steps that are simply you typing in a password, a URL, or anything (If you must have things that are typed, have them in copy/paste, or on a sheet of paper so you don’t need to remember them). It’s very hard to type and talk at the same time, and you should be providing commentary as you go through the demo.
- Practice in the venue. Ask the organizer to find you 10 minutes during the day, or the day before, to do a test run. Odds are good you’ll find a few small problems you can work around, but that you’d be blindsided by if discovered for the first time during the actual demo.
- Have a backup machine. For high profile demos, have an entire backup laptop or cellphone ready to go. This level of redundency will protect you from internal problems (conflicting code, bugs, etc.) but not external problems (wifi, power outage, etc.)
- Never troubleshoot in real time. It is cringe enduing to watch somewhere debug their demo live in front of a crowd. Don’t do it. 45 seconds is the most I’d spend. With everyone watching, your debugging skills will be severely compromised. If you can’t fix it in that time, drop it. Never ask anyone for help unless you are certain of what the fix is. Instead, just fall back to your video (#3).