A little addition to #2, the need for a script: it should start with telling what your system is all about, what problem it solves..etc.
If you start flashing screens and showing different features while your audience still does not have a clue about what you are trying to do, you'll lose them in the first minute.
I tuned out at "Us programmers". I know it's finicky, but if you're going to be writing a lot, you need to be accurate with your grammar.
Donnie: My apologies. Will work on improving the grammar and try and invest more time in proof-reading future articles.
In re #1 and #3: VMWare is awesome stuff for running a disconnected demo. The server can run virtually inside the laptop, meaning that the number of things that can go wrong goes down sharply.
And how about #0: Start by describing the pain. The temptation is to launch in with what salespeople call "F&Bs", but by articulating the problem that is being solved, one is giving insight to the business model question without having to get into the details of the transaction itself.
Ray: Both very good points.
I think VMWare (or something like it) is a great to isolate an environment and reduce the number of varialbes.
Also, can't believe I failed to mention Point #0. (I think I was overly focused on the tactical stuff). Point #0 deserves an article of it's own. It's critical for presenters to first describe the pain before jumping into a demo. Thanks for reminding me of this.
Some additional points.
(-1 = before you start) Figure out the six-word phrase you want your audience to say when their business partner or spouse asks them what your demo was about. Write it large on a piece of paper, and stick it where everyone developing the demo can see it.
(0) Try to put a little dramatic tension in your demo. Make it present a problem and offer a surprising solution.
(1) Make sure sound is turned off ("No Sounds") on any computer you use. Otherwise that idiotic fanfare will announce to the world that you had to reboot.
(2) Ten minutes doesn't leave time for ANY powerpoint slides. Don't use them. Not even one. Make your demo tell your story.
(3) If onscreen text in your demo is worth presenting at all, it's worth making large enough for people to see.
Reiteration of some blogging advice: copyedit your posts.
it's != its
(generated much of it's [its] revenue)
right != rite
(right [rite] of passage)
Once you your demo ready [huh?]
Thanks for the informative post.
I just wanted to say this: Please don't worry about your grammer. Sure, a quick proofread is always good. But blogging is best when it's informal and we appreciate the time it takes to get something perfect. I'd rather have your quick (and dirty) thoughts than have you limit what you say because you're afraid of an incorrectly placed apostrophe.
Sorry to chime in off topic.
Actually, it is "rite" of passage. Rite = traditional ceremony.
My first suggestion is -- DON'T make the demo your presentation. The old saw 'live by the demo, die by the demo' comes to mind. If 90% of your 10min is a demo and it does not work then what? Much better to lay the market prospects and how the startup intends to service that market. Lay that out in 6-7min. Do the demo at the end, and I would do it as a video clip. You can do as many takes as you need to get it right and make it look professional rather than fumble at the keyboard in an unfamiliar environment as a live man dying.
The next suggestion is can you package your entire demo to a CD or DVD? If you can do that (say with something like Windows PE) then your entire presentation is somewhat bulletproof from the vagarities of the hardware. And the added bonus for all that additional pain? When the prospect asks if they can see the demo again you can merely say take it home and play with it. You will blow the socks off your competition for doing so. Just be sure your package is sufficiently protected to give them a taste without giving away the store to a wiley competitor. Or take the video clip to a CD/DVD if you fear IP theft.
Live Demo's are always good. If there's no live demo, I ALWAYS assume that either (a) the product is broken or (b) the presenter can't use the tools. Early stage presentations like those by Y-Combinator Companies, are ALL about the proof being in the proverbial pudding.
Dharmesh makes some excellent points (with the addition of point (0)). I learned (1) after having to do an impromptu 1000' network cable run in order to do a demo for the CEO of a multi-billion dollar corp. Thank god we had taken steps (2) and (3) the day before so we had time to lay the cable.
One critical point about notes: Word by Word notes don't tend to work very well. You spend all your time looking at the notecards and not at the audience. Better to lay out cards with bullets or short sentences that remind you what you want to say.
Last but not least BE SURE YOU NUMBER YOUR NOTE CARDS. I had some bad experiences with stacks of notecards that got out of order. If you're already nervous about presenting, this is a disaster waiting to happen.
if you ever want to do power point presentations properly, check out the book (and website) "Beyond bullet points".
I began using it after 10 years of powerpoint - and - it is awesome.. requires lot of one-time background work, but its worth it.
Cheers and thanks for a nice post - Peter
Thanks for the presentation advice. I'm glad that you enjoyed the presentations. It makes all the hard work worth it.
For the demo, I suggest to use a pre-recorded flash movie created with a tool like Wink (http://www.debugmode.com/wink/). And it's also a great idea to ditribute a (mini)CD's with the flash movie, resumes, vCards...everything that the angel/VC need.
As always, excellant article.
A few comments from a guy who’s done way, way to many live demos.
2. Folks, just make the script. Even if you don’t use it, it’ll still be fresh in your mind and will help. A great test of your script is to practice your presentation on a friend who is not technically savvy and does not know a lot about your product/idea – i.e.: a clean slate viewer. Their feedback can really help you polish your message. Their help can really help you dial in the pace, clarity, and message.
Re: pre-recorded demos. Don’t do it. You want to engage your viewers – if someone asks a question that causes you to stray from your planned walk through, you need to be able to react to their detour. Canned demos always feel too produced. Everyone wants to see something “live” – even if everything is running on your laptop, as it should be.
11. Supplies – be prepared for the almost everything.
a. If you’re bringing your own projector, bring an extra bulb. While the catalyst for this entry was the YCombinator presentations, where they most likely supplied a projector, this is an important point for those of you who take your demos on the road. Have an extra bulb. Sure, many have advertised life spans of at least 1K hours, but you really, really want to avoid not being able to make your pitch because your projector died. Trust me on this one. No C-level exec is going to want to sit next to you to view your tiny, high-res laptop screen.
b. Extension cord & powerstrip. You never know how well equipped a board room will be, or what might be missing from their board room on a Monday morning because someone borrowed it for the weekend.
Depending on what you're presenting, sometimes it helps just to say what you're getting at rather than hope someone can read between the lines.
For instance, I will say things like,
"Here's the business value: [enter value here] "
"This is why this saves you money: [enter $ saving bit here]
"This is what sets us apart: [you're not really different, but fake it]"
For an added bonus, you can make a dramatic pause in between the setup and the delivery and use it to regain eye contact.
Good post - and an interesting one because most of the people we train (we do presentation skills training in the UK
) are into sales-based presentations rather than technical-based presentations. Personally, I see the overlap between them as huge but most people don't.
Can I pick up on a comment from earlier? The advice was never to give "canned demos" but running a genuinely 'live' demo is fraught with nerve-induced errors. Simple typos can be embarassing and even serious (I once forgot which OS I was using and typed RM for 'remodulate' on a system with read RM for remove - deleting the directory with my data in it right in front of my audience!).
Can I suggest a compromise of some kind of macro-based presentation, so that (say) half a dozen commands are held in one file which your application reads? That way you can see it wizzing past on the screen, looking exciting, while you explain what it's doing - and let's face it, the explanation is *more* important than what it looks like while it's working.....
.... which is a point most geeks/programmers/etc tend to forget: the product is more important than the processes, no matter how elegant it might be and no matter how many nano-seconds you've shaved off the loop! :)