Wednesday, November 21, 2012

How Not to Demo

I had my first demo Monday night at our school's Inventor's Symposium.  While it wasn't a big pitch to VC's, it was fairly significant demo in that:

  • It was my first ever
  • Most of the people there were my target market
  • It was a large portion of my final grade
Everything went wrong.  My computer broke, the server wouldn't work, and I didn't have an internet connection.  While some of these were avoidable, others were my own dumb fault.  Before I go listing off all the terrible, horrible things I did wrong, let me brag about the one thing I did right.

I had a stack of papers that contained details about my product.  That's it.  While I didn't have a live demo, I was still able to go over my product and explain it's purpose, etc.  While I wasn't able to make any "sales" per se, it still was a confidence boost and prevented the evening from being a complete flop.
Lesson 0: Have an Apocalypse plan.  If everything goes boink, how will you demonstrate/sell?  Can you convince someone of the usefulness of your product without your product?

Astute readers will recall that I was looking for a cloud-based solution to host my project.  That never ended up happening (I was lazy, and didn't want to bother migrating databases).  Instead, I decided to cart my PC down to the hall where I'd be demoing.  When I got everything set up, it hung halfway through boot.  After some trial and a lot of error, I got a new error in BIOS.  Then it wouldn't start at all.
Lesson 1: Remain calm as everything explodes.  Worry about broken things later and focus on selling what's working right now (even if it's just a piece of paper).

I also tried to fix the problem during the symposium.  I found out quickly that people wouldn't come over to my table if I was elbow-deep into a computer's guts.
Lesson 2: Have two people to demo.  When something like this goes wrong, one person can perform emergency surgery while the other mans the booth.

When I finally got my computer running by some miracle, I realized that I didn't have an internet connection (duh).  This wouldn't have been a problem, except for the fact that I was loading one of my JS libraries from the internet, instead of local.
Lesson 3: Test your demo like you would an application.  Make sure it's as local as possible (even if there is internet, it'll be faster if the code's local).

When I finally got everything in a remotely workable state, there was only 10 minutes of show time left.  I quickly learned another important lesson as I watched people stare blankly at the app in front of them.
Lesson 4/5: Walk your users through the application.  Additionally, make sure the best part of your demo is the one they see first.  They probably won't have the attention span to see more.

I had brought my PC and two laptops to scale demoing and make it so everyone got the "hands on" feel.  Two people showed any interest in doing everything.  I ended up running through the demo (when it worked) almost every time.
Lesson 6: While an array of computers running your product may seem like a cool idea, one big screen is probably a better idea.

Despite the incredible amount of things that went wrong, I still got a very positive response.  I'll be taking this class project and (hopefully) turning it into a real project.  Stay tuned!


  1. This comment has been removed by the author.

  2. interesting article :)
    and what do you sell ?

    1. I'll be turning it into a real product soon, so I'm keeping it under wraps. Stay tuned for more details.

    2. RKoutnik, you just got a lot of exposure from the net. Now would be the perfect time to put a one paragraph description of your product and an email link. You'll kick yourself later otherwise. ;)

  3. Lesson 7: If you operate a computer in front of an audience on a screen, you instantly become an idiot. No exceptions. What's actually going on is that you're so focused on what you need to say that you'll hesitate and make mistakes, while the audience, who are hyper-tuned into understanding what you are doing, will spot mistakes instantly and get frustrated when you don't see them.

    There is no shame in showing a pre-recorded demo or using scripting/automation to ensure everything goes smoothly. No presentation has ever been enhanced by having to wait for the presenter to type out entire lines of commands or code.

  4. I think it would have helped you more if you rehearse before hand with a teacher or friend.