How to give a perfect demo
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).
Grab this great general purpose checklist for giving great presentations.
What other common mistakes do people doing demos make? What other advice should they hear?
All excellent points. The only point I would add is an obvious one, but you’d be surprised how few people follow it: practice.
One of the fastest ways I know of to improve a demo is to videotape yourself rehearsing and then watch it back. I think this can be uncomfortable for many people, but you will pick up on the slow points and the cruft immediately and be able to make easy changes for the real thing.
Jeremy:
Good point on practice. I figured that the mention of recording a video forces some amount of practice, as to have a video you have to at least done the demo once before. And odds are high it will take a few tries to get the video right, and that repetition is a kind of practice.
Couldn’t agree more. I’ve lived through many presentations (including those of some Microsoft evangelists) where the code didn’t compile. At all.
Do practice. Several times. Don’t just come in and use the old student excuse “This worked last night.”
Demos with code are always incredibly tricky, no matter how good of a programmer you really are. I would add: prepare to give commentary while clicking/typing/coding etc. I think that’s actually one of the most difficult things to do and a place in which you can lose an audience very easily.
Maybe add “prepare online slides (with an easy-to-remember URL)”.
So you can give your audience a hint where to view your slides right at the end of your presentation (which is also nice for twitter-ing people… “Wow, just attending an awful demo of foobar… see slides at bit.ly/xyxyxy”)
Could we implement some “like” buttons and “subscribe to replies” buttons on this website? I’d love to just express my “Ahahahahaha… :)))))” on Klaus’ comment right now without sounding stupid.
Let me add four more.
1) If it’s a client/server demo, place the server component(s) on a separate machine and connect them by cable directly. A second laptop is cheap and relatively light (and provides a backup, since in a pinch either machine should be able to run the whole demo). But trying to run server apps on your demo machine just makes the whole system look slow. Who wants to hear apologies that “SQL is running a bit slow right now” or some such!
2) Start with a clean reboot. And practice that way, rebooting and then running only PowerPoint (e.g.) and the demo. Don’t surf the web, don’t check your mail, just run the demo from a known clean, reproducible, and practiced state.
3, or really 2b) Do NOT run Outlook, IM, HootSuite, GMail, a calendar sync, etc. during the demo, unless that’s the program you’re demoing. No one wants to see the blue translucent popup during your demo… especially when it asks if you’ll be home for dinner (or worse). If your demo shows a tie-in to EMail, set up a clean, for-demo-only account. You can control what’s in your inbox, when it polls for new mail, etc.
4) If your demo requires multiple personas, either have multiple demoers or simplify it. It only takes one “Now I’m Charlie, the service agent” to totally confuse the attendees.
Hi Steven,
thanks, nice points.
For 4), how would you recommend it if multiple demoers cannot be avoided and you demonstrate on a projector? Probably multiple projectors would be best, but in case that is not feasable … I think connecting/disconnecting projector is not quite an option either.
What typically works well for me is logging out and in as the other user. I have the impression most attendees can follow that.
Cheers
One of the things that I find cringe-worthy is in development talks where the presenter often switches between PowerPoint and Visual Studio – or more specifically those awkward moments after the demo when switching back into PowerPoint and locating the tiny button to resume the slideshow. Sometimes it doesn’t quite work out and they end up launching the slideshow from the very beginning.
In fact, I was so opposed to doing this myself in a user group presentation on Regular Expressions that I took inspiration from Bea Stollnitz and integrated my demos right into the slides (they were the same custom application). Apart from removing the friction of these transitions, they allowed a greater degree of flexibility so that audience members could suggest their own spontaneous test cases and I could run them without any fuss.
Most all of these rules flagrantly violated in Fred Wilson’s favorite demo: http://www.avc.com/a_vc/2010/08/how-to-pitch-a-product.html
Kevin:
Well, Yes and No. He had a typo at ~ 2 minutes in. Had the guy in the audience not yelled it out, he’d have been debugging it himself.
He could have copy/pasted most of that code and saved 60 seconds, and reduced the odds of errors.
It’s also important to note this was a developer audience. They can appreciate coding live and give kudos for it, but no one else would have cared. They care about the payoff.
The payoff is he made a live conference call specifically for the people at the event – a custom demo – where he called everyone’s phone at the same time (around 6:20 in the video). He could have achieved the same effect with much less risk.
One point I want to add is: Know your audience and try to imagine possible remarks from them.
Clearly, you can never imagine everything, but some preparation and setting up expectations helps.
What happened to me recently during a presentation, I wanted to highlight how the software is capable of searching for text both in latin and cyrillian letters, disregarding in which script it was entered. In order to involve the audience, I asked for some sample input, and “find customers from Banja Luka” was mentioned.
Alright, I typed in “Ban” as search string – and got only latin results. Bloody what’s wrong – ‘it worked the night before’.
Problem was, only ‘nj’ matches the correspending letter in cyrillica, but ‘n’ is completely different a letter …
So, the point is … there is simply no excuse for not being prepared for user input other than anticipated.
One way to get out of a dependency on WiFi is to have a local copy of your network traffic available. When I run “live” demos, I use Fiddler’s AutoResponder tab to play back previously-captured traffic. Fiddler can stay out of the way in your system tray, but so long as you don’t stray from what you captured to playback, your demo will always work even without a network connection.
Always stay calm! There is nothing like someone trying to show something and having them freak out about the issue. I once was on stage in front of my CEO and 2000 resellers and coworkers when someone stole my IP address. I tried for less than a minute to fix it then explained in simple terms what my piece of the demo was then handed it off to the next person. (I was not the main part of the demo, just a key piece.) Having stayed calm and collected allowed people to see what I was trying to demo without having to actually do it. (I should have made a video!)
This is a wonderful thread!
Speaking of “don’t trust Wi-Fi”: as I was going to launch penveu (www.penveu.com) at DEMO 2012 in Santa Clara, I was coming from backstage, when I realized there was a microwave oven operating backstage (preparing hot wet towels for the presenters). I immediately asked them to “kill” the microwave oven before I get on stage. They did. Do you know what can a microwave oven do to a Wi-Fi connection??? Anyway–the demo went well. I didn’t have the option of Ethernet to replace the wireless link to the product…