I’ve been responsible for more trainwrecks than I'd like to admit and my biggest learning has been that you can never be too prepared. Some factors are going to be out of your control (someone’s cell phone going off, for example) but there are a handful of ways to optimize for a smooth demo. Here are some learnings to consider next time you’re pitching a product to investors or presenting a new feature to your product organization.
These things are the devil. There are three big challenges with projectors: severely limited resolution, severely limited contrast, and an unpredictable connection to the demo machine. Mitigate the first by bumping up the resolution as much as possible and using browser zoom to position your (web) product correctly. Regarding contrast, be prepared for your product to be less visually impactful than it is on your cinema display; if your product has a dark background with lots of sleek grays (think Spotify), you may need to explain why the app looks like a pile of melted driveway sealant on the big screen. As far as the peripheral connection is concerned, make sure you know how to configure the display and that you've tested that particular projector with the demo machine in advance.
It’s shocking how often a fatal flaw in a demo happens because the development team is completely unaware that their product is being demoed. Starting about an hour before the demo, advise your team to stop shipping for that period. It’s painfully obvious to an audience when the presenter is surprised by what’s being projected.
The best demos clearly explain what the user’s problem is and how this given product will solve it. The most powerful way to do this is to keep the narrative concise, speak in the first person, and describe the experience as you walk through user flows. By focusing on use cases and illustrating real user feedback, the end-user benefit of all the slick new stuff you’re showing will be obvious.
If there are any stakeholders in the room and you demo software that is running locally, you are willfully deceiving them (as far as I am concerned). You might be surprised how sharp the audience’s eye is; I once heard a sales rep catch that a demo was of a QA environment (from the URL). People will notice if you are demoing from localhost or QA, or showing mockups (ew! How could you sleep at night?!) so remember: production software or it didn’t happen.
Or one just like it. If you rehearse on a Mac, demo on a Mac. If you rehearse on a PC, demo on a PC. Switching to an interface and system that isn’t second nature right before giving a demo is going to be much more stressful than you think. Even if you have to swap presenter roles, it’s worth it. And don’t forget these small, quick tricks:
If you show up to give a demo and your audience is already seated and ready to go, prepare for a big healthy serving of fail. Ideally, you should give yourself about 15 minutes to prepare before the demo is scheduled to start. Edward Tufte, who’s written extensively about giving presentations, makes this recommendation, too. His point is that getting a sense of the audience as the room fills up can help you stay calm and in control. Maybe people will be standing when you thought they’d sit, or they’ll want to stop and chat with you as they walk in. Preparing ahead of time will give you a chance to pivot and solve last minute issues.
Test all features within 10 minutes of the demo. Obsessively.
Are you demoing beta software? Are these new features in general release? Whatever the status of the product is, be clear about it so you maintain and grow credibility with your audience over time. A simple and effective guideline is to avoid demoing anything that doesn't have at least one active user in the wild.
Really. Wi-Fi can be a finicky thing and you don’t want to be reminded of that when all eyes are on you and your product. Along those lines, beware of Bluetooth. Wireless technologies work much better in empty rooms than in rooms full of fellow web geeks. That one hasn’t burned me (yet), but I learned this lesson at the expense of the GoogleTV team who suffered through a tremendously embarrassing product reveal at Google I/O 2010. Sadly, they hadn't accounted for Bluetooth working once there were 10,000+ techies in the room on their devices.
It’s natural to get invested in the things we make. Development teams spend countless hours building, fixing, and discussing what ultimately gets shipped. By the time a product gets demoed, a lot of love and pain has already been poured into it. But it’s important to check any personal baggage at the door and just tell the story of why the software will make your users’ lives better. That’s all anyone wants to hear.
Finally, to take your demos to the next level you have to show real impact. Explaining why you did something or what it looks like to the user isn’t enough; you have to demonstrate what the actual result of the work was. The easiest way to do this is to talk about how usage increased, but for your demo to make it to black belt level mastery you need to tie it back to the bottom line. How does this product impact your business? How has it made customers more successful? Here’s how to think about showing that impact:
The nerves that go along with giving a product demo will always be difficult to master. But being prepared makes a huge difference in demoing with confidence and minimizing potential potholes. What else helps you prepare for product demos?
A variation of this post was originally published on Markitechture, Chris's personal blog .