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!
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.
# 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.
3 comments
[ 3.0 ms ] story [ 18.7 ms ] thread1: 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.
# 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