How to Demo
After running the NY Tech Meetup for over three years, and personally curating and coaching over 250 demos, I've learned a thing or two about what makes a successful software demo. First, let's define a a "successful software demo." A successful demo is comprised to two important outcomes, no matter the audience:
- As a whole, the audience comes away with some level of consensus that you're a smart, self-aware person doing worthwhile things.
- At least 1 person in the audience has an "ah-ha" moment and comes away with a mission to help your product succeed, either by providing a critical feature idea, a hire candidate, potential partnership, or -- in the case of a demo to investors -- the desire to fight to invest.
So, how can you deliver the best demo possible, no matter what time you're given? Follow these rules:
The Core: Software is Magic. A Demo is a Magic Show.
All software have this in common:
- There are inputs.
- Those inputs get processed by all of our hard work and labor that goes into our software.
- And there are outputs which are nothing short of magical.
For a product like Aviary, the magic is quick, visual, and has a lot to do with the complexity of the software. Drag an image over a filter (that's the input) and a totally new image pops out the other end (that's the output).
It's magic.
For Meetup.com, it's the same, but different. You have inputs, which comprise the creation of a group and scheduling a time to "meetup," but the output (the magic) is -- in the case of the NY Tech Meetup -- 860 passionate people in a room all at once.
Aviary and Meetup -- both have inputs, both have magical outputs. That's software at work.
So, it's pains me when people come to demo and, instead of putting on a magic show -- showing off how humans (themselves) and software interact -- they try to inspire the audience through their words and by speaking about their ideas; or, just as bad, they flip through a bunch of preloaded tabs in an effort to "show" the product, as if pre-loaded tabs are any better than PowerPoint slides.
Flipping from tab to tab is like showing a tiger in a cage at a magic show, but having never shown the audience that the tiger wasn't in the cage in the first place! Yes, that will save some time -- 5 seconds of page-loads here and there certainly add up -- but what people don't understand is that those 5 seconds of page-loads are the magic we're looking to see. A magic trick is about experiencing a process, not looking at a before and after picture.
You put in an input (a click? a swipe?) and the output was magic (a new page? interesting restaurant recommendations? a room chock full of people?).
Success. (Want to see one of the NYTM's best demos ever? Check out John Britton's famous Twilio demo here.)
The Preamble: Demo the Problem. Don't Talk to it.
There are many people for whom demoing their software comes very naturally. Still, there is one major mistake they make leading up to the part of the program where they show their software: they talk about why they built it.
Talking is always a mistake during a demo. If you're talking, you're not showing, and while anyone can talk a good game, not everyone can show one.
More practically speaking, telling the audience about why you're in business is not nearly as powerful as showing them why you're in business.
Instead of spending the first 10% - 20% of your demo telling your audience why what you built matters, take the time to demo the current state of affairs: the "why" your software matters.
A great example of this recently at NYTM was the Matchbook demo. When Jason showed up at the May NY Tech Meetup, he asked to spend a few seconds talking about "why" they made Matchbook. When we dug into the issue, it seemed that most people were keeping lists of places they needed to checkout on the iPhone's native Notes app.
When I heard that, I thought like it sounded like the perfect problem to demo. Jason then loaded his iPhone's Notes app with a lot of tips, opened his demo by showing them, and stole the show.
At the end of the day, it's okay to demo someone else's application if it helps illustrate why your app is so great. Most great products are alternatives to existing hacks, so show the existing hack -- get the audience on your side by relating to a pain they already experience -- and dive right into the meat of the demo: the way you change everyone's life for the better.
Two small but still important points: Keep it Simple and Stay Cool
Keep it Simple Some services are barebones and elegant, and others are feature rich. For the barebones, it's easy to focus on the big main idea behind the process when demoing. However, for the feature rich, people always seem to get bogged down by the nitty-gritty. "And we have the ability to share this new 'doodad' on Twitter."
Even if your app has a lot of features, leave many of them out of your demo. Leave something for the users to discover on their own while browsing. Anyway, sharing on Twitter is useful to some people, but it's magic to no people -- so just leave that kind of stuff out.
Stay Cool Lastly, when it comes to demos there are so many points of failure. The Internet connection of the venue you're demoing in, the Internet connection of your webhost, the browser's configuration you're demoing in, Flash's overall shittyness, and even your own stumbling trying to type and talk at the same time.
IT'S OKAY!
Believe it or not, if something goes wrong while you're demoing, the audience won't pass judgement on you at all. However, the audience will pass judgement on how you react in times of stress.
When something goes wrong, do you freak out? Go completely silent?
People are drawn to those who handle stress like nothing ever happened. If you can keep your cool, keep talking, get a few jokes out, and find a creative way to let the show go on, you'll win more hearts and minds than if all the technology even worked. Remember, generally speaking the point of a demo is to get people to think that you're a smart person doing worthwhile things.
Someone who can handle a bump in the road looks like a smart person.