Presentation Tips For The Technically Gifted

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Presentation Tips For The Technically Gifted

 


I had the opportunity to attend an event hosted by Y Combinator today.  Basically, the purpose of the meeting was to invite a number of angel investors (and some VCs) to see a presentation by the current portfolio of Y Combinator startups.  If you are not familiar with Y Combinator (or Paul Graham, who leads the group), you can Google them and read-up.  I’ve written several articles on them and their portfolio companies before.  If you got to this article through Reddit, you may know that Reddit is a Y Combinator portfolio company.

Twelve different startups presented, each within 10 minutes so it was a fast paced event.

Disclaimer:  This was a private event and I was invited as a potential angel investor (and in part because of  my affiliation with Common Angels, a well known angel investor group in the Boston area).  As such, I do not plan to reveal any “insider secrets”.  Many of the companies presenting have not launched yet.  So, I’ll remain focused on more general observations without naming specific companies.

Instead of just dumping my thoughts out in a stream of consciousness style, I thought I’d divide up my thoughts into multiple articles that are more organized.  This is the first in the series of such articles (there will likely be one or two more).

Each of the dozen startups that presented today were chosen in large part because they had particularly smart and technically gifted founders.  Paul Graham has a nose for this kind of stuff, and for the most part, I was impressed with the level of talent in the startups that presented.  So, I offer the notes below not to criticize the presenters – many of whom are deeply technical but have not had to present for a living, but to draw lessons from some of my experience and having made all of the mistakes below, at least a few times.  Note also that these are mostly “tactical” tips (and not strategic ones).  I think the world often undervalues tactics sometimes (because strategy is so much sexier).

Presentation Tips For The Technically Gifted
 
  1. Web Demos Shouldn’t Require The Web:  Most of the startups presenting had some type of web offering.  All of the startups did some type of demo of their product .  A couple of the companies had issues with their demo which were attributed to a “flaky wireless connection”.  Having been in this situation countless times before, I will share with you an insider’s secret on web demos:  Don’t rely on the web.  In my first software company (which generated much of it’s revenue through web-based products), I made it a requirement that anyone that was going to demo our product had to be able to do so “stand-alone”. This was a pain in the ass because it required installing  a bunch of software:  the legacy system with which we integrated, a database server, a web server and our application (along with a bunch of third-party stuff).  All of this had to co-exist peacefully on a single laptop.  In fact, it was a right of passage for someone to get all the pieces right and have it working on their machine.  But, this exercise was invaluable.  Back then, the issue was that many of the sites we visited didn’t have internet connectivity in the conference rooms.  Or if they did, it required access to the corporate proxy server and holding your nose just right in order to get a connection.  By being “self contained” we avoided all of this risk.  Moral of the story:  Your web application is too important to trust to the web (when it comes to demos).  Don’t get me wrong, if you have the app available on the web, that’s great (but you should always be able to demo everything off of a single laptop).  [Note:  One upside to using a real-live Internet connection is that it always gives you something to blame.  I have a sneaking suspicion that some of the demo issues had nothing to do with the network connection and something to do with the software].

  1. Write Out A Demo Script (And Try It Out):  We programmers get so close to our product that we know all of the features (and potholes) by heart.  As such, we are completely capable of “winging it” and showing off the features we want during a demo.  Despite this, I still strongly suggest that you write out a simple demo script (which is nothing more than outlining, at a high level, what you are going to show during the demo, in step-by-step form).  This exercise is not because you’re going to forget what the steps are, but because you can then do a walk-through prior to the demo.  I will bet you a dollar that if you wrote out a demo script right now, and walked through the steps in real life, you will encounter a small surprise.  Something you didn’t expect.  Moral of the story, write a script and try it out a couple of hours before the presentation.  The reason for doing this a couple of hours before is that you then still have time to fix that “one last bug”.  I cannot tell you the number of times I’ve come close to wanting to sell my soul for an extra 30 minutes to “fix things” when I realized something was broken before a big demo. 

  1. Control The Variables:  Once you your demo ready, you need to minimize the amount of change that occurs in the hours leading up to the demo.  This is why I’m so emphatic about #1 (i.e. demoing from a stand-alone laptop).  If you demo from a web server, there are weird things that happen in the night.  Some from your hosting provider, some from your co-founder (who may not admit it), some from gremlins that change configuration files or install a new build of the application 45 minutes before the demo.  In short, try to minimize the number of variables so you can control your environment.  If you are demoing off of your laptop, don’t install that fancy new video device driver that lets you pan as if you were on a 8000x6000 screen using mouse gestures and a road map.  Wait until after the demo to do that.

 
  1. Test With Lower Resolution:  If you’re like me, you’re used to running your laptop on a resolution that is likely non-standard (and pretty high). For example, my primary machine runs at 1400x1050 (which happens to be the native resolution of my Thinkpad).  Chances are, whatever LCD projector you’re going to demo from will not deal well with your native resolution.  The good news is that most projectors will now deal fine with 1024x768 (though I still encounter situations where even that is too much and I have to drop to 800x600).  The message here is very simple.  Try out your presentation at the lower resolution.  My heart goes out to all the presenters today that had to fiddle with their display settings to get their presentation up and running.  It’s very painful when you have limited time and a medium-sized audience.  It’s not that hard to try it out first and see what happens.

  1. Stage Space Is Precious:  Many of the presenting companies today had all of the team members up “on stage” even though in most cases, they didn’t have a speaking role.  I’m fine with one person running the demo and the other talking (though I personally like to do both myself as it makes the demo smoother), but I think it is ineffective to have extraneous people on the stage.  Note  I’m not suggesting that these people are extraneous all the time – just in this instance.  There will come a time when you need to demonstrate to people that someone more than yourself believes in your idea enough to spend their precious time on it.  But, in situations like this where time and space is limited, your core mission is to get your point across.  If having four people on the stage is necessary to do that, by all means do that – if not, keep it to a minimum.  Audiences are easily distracted.

  1. Play To Your Strengths:  Most of the presenters today did a really good job of this.  They stuck to the basics and talked about things they knew a fair bit about.  This was mostly the product, technology and possible user scenarios.  In a few cases, the presenters tried to address the issue of revenue generation and business models.  In these cases, it seemed a little weak (which is understandable, for very early stage companies).  My advice is:  If you haven’t thought through in detail how you might make money, don’t try and fake it.  Otherwise it sounds like the “look ma, I know how to say things like business model and revenue generation”.  It comes off as empty and indefensible.  There’s no need for it in these kinds of situations.  Focus on what you know better than everyone else in the room. 

  1. Invite Conversation:  At the end of the presentation, *ask for a conversation” (not money, as it’s not appropriate to do that yet),.  Something like:  “Sorry we don’t have time to tell you more out of respect for the schedule, but we’d love to talk to you in more detail about what we’re doing.  Please grab us during the break…”  Interestingly, all of the startup companies that presented today did a great job of this. 


If you were one of the presenting companies yesterday and happen to be reading this, my hat is off to you.  It’s really hard to do a 10 minute presentation.  I’d much rather do a 60 minute presentation than a 10 minute one.  10 minutes doesn’t give you a lot of time to build rapport with the audience or otherwise “get into your groove”.  The above tips are mostly to help all of you technical folks get the most out of your presentations and demos.  I am by no means the expert, but have done enough of these now that I’ve accumulated a few war scars.  

How about you?  What tips would you add to the above list of technical people doing startup presentations?  Would love to add to my collection of things to do and not do.

Posted by Dharmesh Shah on Fri, Aug 11, 2006

COMMENTS

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.

posted on Friday, August 11, 2006 at 9:34 AM by


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.

posted on Friday, August 11, 2006 at 9:41 AM by Donnie Hale


Donnie: My apologies. Will work on improving the grammar and try and invest more time in proof-reading future articles.

posted on Friday, August 11, 2006 at 9:54 AM by


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.

posted on Friday, August 11, 2006 at 10:16 AM by


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.

posted on Friday, August 11, 2006 at 10:24 AM by


Great writeup!

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.

posted on Friday, August 11, 2006 at 1:48 PM by Ollie Jones


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?]

posted on Friday, August 11, 2006 at 2:57 PM by Grammar Police


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.

posted on Friday, August 11, 2006 at 3:31 PM by David Cohen


Actually, it is "rite" of passage. Rite = traditional ceremony.

posted on Friday, August 11, 2006 at 3:35 PM by lsong


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.

posted on Friday, August 11, 2006 at 4:47 PM by John McGinnis


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.

posted on Friday, August 11, 2006 at 6:45 PM by fewquid


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

posted on Saturday, August 12, 2006 at 12:05 AM by Peter Theobald


Thanks for the presentation advice. I'm glad that you enjoyed the presentations. It makes all the hard work worth it.

posted on Saturday, August 12, 2006 at 2:21 AM by Sean McBride


Nice article.

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.

posted on Saturday, August 12, 2006 at 6:24 AM by Arnaud Rolly


Dharmesh,

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.

posted on Monday, August 14, 2006 at 9:20 AM by


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.

posted on Monday, August 14, 2006 at 11:40 PM by


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! :)

Simon

posted on Friday, December 08, 2006 at 3:27 PM by Simon Raybould


Comments have been closed for this article.