

Ask HN: Demo tips - lpgauth

Hi HN, I'll be doing a demo of ReviewRobot (www.reviewrobot.com) @ CUSEC but I'm a fairly inexperienced presenter. I would love to make a great demo and for this I need your tips!
======
brk
For new products, there are two general approaches to developing a demo
script.

1: This is an entirely new app/concept that your audience didn't know they
needed. Your job is to convince them that they can't live without this thing
that they've managed to live without up until now.

2: This is an enhancement or optimization to something they're already doing.

Many times products fall a little bit into both categories, but usually fall
predominantly into one or the other. An example of this would be Tivo. It was
mostly #1 (A whole new way to manage your TV viewing), but had some of #2 (it
was in essence a glorified VCR).

Your App looks like (in my 4 minutes of review) it's mostly #1. iPhone
developers have not had this ability to do integrated simple user feedback in
their apps, and they've mostly managed to do OK so far. You need to convince
them they can no longer live without using your product.

Don't be overly dramatic, cheesy, or inaccurate in your presentation. It's
okay to be really excited about your product, in fact you should be, but don't
act like you just discovered the cure for cancer either.

I tend to start a lot of my demos from the back, and work forwards. Lead in
with showing developers some of the OUTCOME of using your product. Which, I
assume is some sort of charts or correlated feedback or something. This way,
when you then explain what it costs or what it takes to implement it, the
audience knows that the outcome is valuable enough for them to pay attention.
If you spend 15 or 20 minutes describing how to add the module into the app
and twiddle all the features you risk losing the interest of the people who
don't yet realize they should be paying attention.

Be prepared for something to go horribly wrong with your demo. Something won't
load or display or work as expected. DON'T apologize when this happens, and
don't get thrown off track by it. I can't count the number of demos I've done
by speaking to a frozen (or empty) screen or image or whatever. Just kind of
move through it with an attitude like it's Murhpy's law in action. It's
happened to everyone.

Leave time for questions, learn to spot people who like to play "stump the
chump". Haters are everywhere. If you get someone in the audience that is just
being a dick (vs. pointing out legitimate things), thank them for their input
and move on to someone else.

Practice your presentation, and speak slowly. Remember that your audience
probably has never seen or thought of your product, so things that by now are
second nature to you are going to be very new (and possibly seem overly
complex) to them.

Be sure to point out any high-level negatives up front (this also helps
eliminate some of the haters as well). If your product adds 500K to the code
base, or chews up some amount of resources, then work that in with a slight
spin. (By adding just 500K to your application size, you can get immediate
feedback and results, saving you valuable research and coding time in the
future).

If you want, you can hit me up via email (profile) and I'd be willing to
listen to your pitch/presentation via Webex or something and I'll give you my
feedback.

------
hboon
# Have a backup machine.

# Have a video version for backup.

# Run from localhost if you can.

# Identify goal of demo.

# Script the demo accordingly.

# Follow the script.

# Be ready to run an adhoc demo without the script (ie. be familiar enough
with the product).

# Go slow.

# Don't move your mouse unless you need to.

# Consider using something like OmniDazzle.

# It helps if the features you show have obvious visual impact (this may sound
obvious, but I'm sure everyone has seen demos of someone clicking a button,
waiting for 10 seconds and then say it has finished processing).

# It may help for 1 person to talk to the audience and looking at the audience
while another runs the demo. May be useful if the latter is a techie who also
happens to be not able to do the talking as well. Still having the latter on
stage allows him/her to help answer questions.

# Practise with _different_ groups of people.

# Don't use overly high resolution for demo. The projector (or whatever
display) you will get may not support it.

# Test run the demo through a few different screen resolutions.

# Bring your cables, charger, adapters, and whatnot.

# Sleep the night before, if you can't, practise more.

# If people fall asleep during the demo, ignore them.

PS: need Markdown or something similar

~~~
lpgauth
I think I'll make a checklist with all these. I'll post it later when it's
going to be more complete.

