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