Preventing the Demo of Doom

I learned quite a few lessons from my disastrous demo on Monday.  Reflecting, I'm glad that it was so bad.  In the grand scheme of things, there was very little at stake and my teacher was very forgiving (unlike a VC). I'd much rather have a colossal failure at this level than in the future.  Problem is, not everyone can demo at this class level.  I mentioned testing your demo like you would your app.  While we can't write unit tests for reality (man, wouldn't that be nice?), we can run through the demo under certain situations to find faults.

Test 0: Create a failsafe presentation
One of the comments from yesterday brought up a great idea that would have helped enormously:

Lesson 7: If you operate a computer in front of an audience on a screen, you instantly become an idiot.

Steven goes on to suggest that a video of the demo running makes for a much better presentation than actually running through the demo.  This allows you to focus on the sales pitch without worrying about technical glitches (at least with your software)>

Test 1: Practice ideal conditions
I practiced my sales pitch a lot, to many different people, so I had it down.  I understood what questions and objections may be raised and how to respond.  What I didn't do was practice the pitch in front of my product demo.  I threw myself for a loop several times because I hadn't practiced moving from the theoretical to the practical and back.

Test 2: What could fail (generally)?
Many things went wrong during my demo.  I could have made it go a lot smoother had I looked at what could fail and how to insure against that eventuality.  While I would have preferred to have my PC there for speed, I should have had at least one other option to access my product.  It could have been on my laptop (Fairly easy to set up with Dropbox) or in the cloud (I had wireless internet but no wired for my PC, so I could have loaded a cloud version on my laptop).

Some general failure states you should look out for (roughly from most to least likely): Slow/no internet (have a local copy), projector failure (don't depend totally on slides),  code failure (have an alternative way to sell/demo), machine failure.  Practice your demo under each of these conditions until you're confident.  It doesn't have to be as good as the original.  All you need is effective communication of your message.  People are surprisingly forgiving if you show you're prepared for failure.

Test 3: Product/presentation flaws
Your product is world-changing, sure, but it has flaws.  What are they?  Unit testing can help reveal some of them.  Others can only be found by putting someone who didn't work on it in control of the demo.  What assumptions have you made about your product and the audience?  For instance, I assumed that people would understand how to use a simple search box.  Most people stared blankly at it until I prompted them even after the elevator pitch describing it as a search product.

Usability testing can also reveal fundamental assumptions about your code, as well.  Running a friend of mine through the demo uncovered a major mistake I'd made with callbacks.  10 minutes of panicked programming later, the bug was fixed and I'd learned an important lesson.