The demo. The holy grail of live, interactive presentation. The point where the rubber meets the road. The seductive allure of a live demonstration drives most technical presentations. Slide after slide gets boring, even with cutesy animations. Audiences can quickly get lost with the droning monotony of slide recitation. However, a demo give them something to focus on. A live system generates real data and shows what you can do. Questions come up and the answers are right there at the tips of your fingers. However, the demo’s siren song can lead to doom if you don’t navigate the waters carefully. Even the most polished demos can fail. Steve Jobs learned this during the launch of the iPhone 4. Tech presenters learn it every day when Mr. Murphy comes calling.
Demos are not inherently bad. In fact, the upside is astounding. The problem comes in the execution. Having been a veteran of many demo presentations, both good and bad as well as a presenter and demonstrator myself, I thought I’d share a couple of ideas I have about demos and how to keep yours from heading south.
1. Make Sure Your Demo Is Interesting – I can’t stress enough how important this bullet point is. Not all things make for good demos. Even things that you think may be the most awesome stuff on the planet can be boring or distracting for your audience. Watching someone type command after command into a CLI window is boring. However, watching a short command instantiate a software load balancer and kick back a list of the configuration is exciting. Watching someone pull up a screen on a phone and poke around is passe. Watching that same phone pull up live info from the Internet and book a reservation at a restaurant for you is much better. The key is to keep the audience on the edge of their seats. You must make the demo compelling and make them want to see where you’re going. The NFD4 Juniper Mykonos demo was exciting because you could see the build out of attack from inception to execution to response. Watching them put up a Google map projection of the attacker’s area with links to local legal council was a hilarious moment, but it illustrates the engagement aspect. On the other hand, the Aerohive BR100 iPad provisioning demo from WFD2 missed the mark a bit. Why? Because watching someone configure an AP is a pretty pedestrian to the audience. Screens full of config values make the eyes go blurry. I understand the power and awesomeness underneath the ability to provision 15 branch offices from a tablet. I just don’t want to see how the sausage is made in this case. Maybe instead having a script run automatically or making it flashier would keep attention focused on the “why” and not the “how”. And if your demo involves a task that needs some time to run to completion, please make sure to fill that time appropriately. Watching a status bar fill up on screen is like nails on a chalkboard to a presentation audience. Avoid long pauses if you can, but if you must you should kick off the first part of the demo and move on with your presentation while the magic is happening in the background. Infineta figured this out at NFD3. Since their long-distance vMotion demo was going to take twenty minutes no matter what, they let it run while they whiteboarded algorithms Don’t make your audience stare at boredom.
2. Test Your Demo Under Real World Conditions – This was Steve’s mistake during the iPhone 4 demo. People practice their demos and presentations religiously (or at least they should). They keep staring at screen after screen to ensure everything is automatic. But sometimes they forget that all those practice runs don’t represent reality. Yes, an iPhone will access the web just fine in an empty auditorium at Moscone. It’s a different story when the audience full of phones and tablets and laptops all melt the wireless with a tidal wave of packets. Steve forgot to make sure that his practice runs looked like the audience makeup that he’d see that day. Just as important, make sure that your demo environment doesn’t do wacky things. Hiccups in dry runs should give you a hint that you need everything to be ironed out before you do it for real. Make your demo setup simple because you also have to remember that you’re under the gun and nervous as hell up there. Derick Winkworth’s SIP demo failed not because of technology, but because he was typing the wrong password into the software. Derick knew the password. But he got flustered because we gave him a hard time about his password earlier in the demo. Doing a live demo is like a trapeze act without a safety net. Be sure you’ve tested your act enough under the big top so you won’t fall.
3. Have A Backup Plan – Just like the most recent SpaceX Falcon9 rocket launch, you can’t assume that everything is going to work right. You need a backup plan. That includes everything in your presentation. Backup slide decks in case your USB drive dies or the drivers aren’t installed. Backup video adapters in case you thought there was HDMI but there is really on VGA. However, if your presentation has a demo, you have *better* have a backup plan. As above, wireless networks can be unreliable in conference centers. VPN connections can fail at a moment’s notice. Files can get moved. Systems can be shut off. Be ready to roll when it looks like your demo is going south. Instead of tap dancing, move over to a local version. Spin up and backup VM on your laptop and show your demo from there. If your files are gone or your machine is down, have a simple animation showing what was going on. Or go for broke on the whiteboard. Diagram everything and make the audience help you out. Don’t let the hiccups derail you. Be ready to go. And in the event that even your backup plan fails, don’t tap dance around it. Apologize and move on. We’ve all seen demos that fail and we know that not everything goes right.
I love great demos. I love being engaged and seeing live systems work. But every time someone pulls out a demo at a presentation, I feel a bit hesitant. I’ve been fortunate enough to be on this side of some great demos. However, I’ve also seen and had some fail spectacularly. If you take into account the things I outlined above, you can minimize the chance that your demo will fail. That way the conversation will center around something awesome and not around shaking head and embarrassed smiles.
Pingback: When Demos Attack
Pingback: Passion, Engagement, Delivery « Cisco Inferno
I would add fourth point: stick to the script. It seems every time I am doing a demo and I get this great idea mid-demo to show something that I was not planning/rehearsing, Mr. Murphy sure walks into the room and causes havoc.
It’s a different if someone from the audience asks you to show something that was not planned – then sure go ahead and try your best. But don’t cause the demo to fail because you yourself came up with some great idea mid-demo that you did not validate beforehand.
Pingback: Brocade – Packet Spraying and SDN Integrating | The Networking Nerd