How to pull off a slick tech demo (in 5 easy steps)
Published by Martin Kleppmann on 12 Sep 2009.
On Thursday I gave a demo of
Go Test It, our cross-browser testing product, at the Cambridge Tech Demo
Night. The audience was a mixture of startups, investors, business owners, developers and
researchers – a fantastic group of people. This was a great opportunity to show to a larger group
of people that Go Test It is now a solid, usable product. How do you make the best use of such an
Demoing alongside me were four other startups:
WebTicketing. I thought that all of them had very slick, impressive and
credible demos (and judging by the positive feedback I got, my own one seemed to go down quite well
too). I had not seen most of them before, but the message they got across in just seven minutes was
so powerful that I’m immediately convinced of their potential, and since the demo night I’ve even
been going around telling other people how awesome these startups are. That’s powerful stuff.
So how do you make a demo which will convince others that you are great and that they should tell all
their friends about you?
Well, first you actually need something substantial to show. A product, a
web application, something which is new and interesting and solidly built. I don’t believe in
vapourware demos; you’ve got to show the real thing. However, for most companies I know in Cambridge
that’s really not a problem – many have very impressive products, they just don’t know how to
Even if you have a great product, you can still wreck it with a bad presentation.
I’ve seen that happen and it feels tragic, so please do yourself and your audience a favour and make
it a good demo. It’s not that hard, and these are the guidelines I set myself when preparing my
demo. They may not work for everybody, but they worked well for me.
1. Know what you’re going to say
When I was at school, the only role I was allowed to play in the drama club was to be the
lighting technician at the back of the room – no chance anyone would let me near acting. That’s
because I can’t remember scripts word-by-word for the life of me, and even if I could, I feel really
silly when reciting learnt lines. Therefore I have no choice but to speak freely.
However, you do need to have a pretty clear idea of what you are going to talk about, and how long
it is going to take, if you want your presentation to be slick. You do need a script in the sense
that you need to decide beforehand:
- exactly which buttons you are going to click, and
- which topics you are going to address.
Then speak the whole thing out loud
twice. I find twice is a good number because I get a good feeling for how long the demo is going to
take – essential when the presentation is strictly timed! – but I don’t feel over-rehearsed and
therefore silly either.
I like things to start with a few slides introducing the issues your
product solves. This gives the audience a context and makes your solution look stronger. But I
wouldn’t spend more than 20% of the time in Powerpoint/Keynote mode; for example, in a seven-minute
presentation, you should be in the actual demo after about 80 or 90 seconds.
Embrace these time
constraints. They force you to be clear and to-the-point. Twitter is so successful precisely
because it forces you to be short; it wouldn’t have worked without the 140 character limit. The
same is true in presentations and demos.
2. Make it work offline
Don’t underestimate this
issue. There are almost always technical problems in any venue, and most usually they are either bad
internet access or problems with the projectors. Bad internet access is the most common. There’s no
point in relying on a 3G card either, because probably reception will be bad in the Faraday cage
that is your demo venue, and if not, the network will be overloaded because everyone is tweeting.
There’s no way round it: your app has got to work offline.
And even though you probably have a full
development environment on your laptop on which you can run your app, there are plenty of places
where you’re accidentally relying on internet access. Some of my
snippet into your page. When you’re offline, that script won’t load until the network times out, and
so the browser’s page load event doesn’t get fired until 30 seconds later. But all your funky
graphical effects only get initialised when the page is fully loaded, and suddenly you have no
animations, no Ajax, nothing! It’s almost like the 1990s!
- You want to demonstrate clicking a link from an email, which opens a particular
feature in your application; however, that email you sent to the test account contains the
production site’s URL, not the address on your local machine.
- You are relying on hostnames provided by a DNS server on another network.
- Some easily forgotten part of your infrastructure (your mail server, memcached,
message queue, mashed-up web service, …) is not on your own machine.
- Your Delicious Bookmarks Firefox extension (or other) tries to connect to its home
server via an SSL connection. Since you’re a new guest to the network, the wireless access point
intercepts the connection and inserts its own login page; of course its SSL certificate is invalid
though. The result? An annoying SSL certificate warning dialog which pops out of nothing every two
To make sure your application works offline, fully disconnect the network on
your laptop (or even better: go to a café with a dodgy public WiFi that intercepts SSL!), clear
your browser cache, and make sure every step of your demo still works flawlessly. Make sure you
leave enough preparation time to fix things that don’t work – it took me the best part of a day to
make Go Test It work without an internet connection! And I had to use, believe it or not, various
entries in my
/etc/hosts file and even an
ssh tunnel to localhost (for remapping ports).
Yes, a bit crazy, but it worked.
In the demo night on Thursday we actually had the projector problem rather than the internet problem. But
you’re on the web, right? It shouldn’t be hard for you to demonstrate your application on someone
else’s computer. Even the hardware guys, mbed and CamVine, pulled off their demos smoothly using a
computer they had never touched before!
3. Make it 100% reproducible
An interesting demo
probably involves manipulating data somehow, and once data has been manipulated, it usually doesn’t
like going back into the state it previously was.
You, however, should be able to run your demo
several times, doing exactly the same steps each time. That means after each run of your demo, you
need a way of quickly and reliably getting back to square one. And of course you need a well-defined
square one in the first place.
Your development database will probably contain lots of edge-cases:
excessively long strings, weird international characters, and other oddities from the times when
you’ve been testing error handling. That’s not what your typical user’s data would look like, so I
suggest having a separate database for demo purposes, with selected and nice representative example
Then you must write down the steps for getting back to the starting state you expect at the
start of your demo: the database records you need to delete or add, the files you need to restore,
the sessions from which you need to log out, the cookies which you need to clear. Or even write a
shell script to do that for you. The last thing you’d want is that you can’t demonstrate a key
feature of your application because some old data from your last trial run got stuck in
Another thing which you should write down, if you haven’t already, is exactly how to get
your development environment up and running after a reboot. For a full
Go Test It development setup I need about a dozen terminal windows open, each
running a different process with an arcane command line, each providing a different part of our
infrastructure puzzle. When I’m under stress I probably won’t remember every command correctly. They
are all documented, of course – on our wiki, which is only accessible on the web. Print it off
4. Clean laptop setup
If you’re anything like me, you’ll have tons of files on
your desktop, a whole host of applications running, alerts popping up from time to time, and more.
Some of this might be confidential. None of this should be appearing on the large projected image of
The easiest solution, I find, is to have a separate system user account to which I log
in only for demos. It is stripped down to the minimum:
- blank desktop,
- menus only contain the apps which are absolutely required,
- no unnecessary Firefox extensions (see the Delicious problems above),
- screensaver disabled.
When using the second user account, you can still
stay logged in to your primary account at the same time, and have all your terminal windows and
stuff open there. It makes sense though to shut down all applications which are not required for the
demo: TweetDeck, for example, is a notorious memory hog, and it would be a shame if one of the pages
in your demo suddenly takes 10 seconds to load because a shortage of memory caused Firefox, your
application server or your database to be paged out to disk.
Also keep in mind that projectors typically have a resolution of 1024x768 – make sure you’ve
tested in advance what your website looks like at that width.
If you need to press arcane key combinations on your laptop to enable an
external monitor, make sure you know exactly what those keys are, and that you’ve tried them
5. And now, enjoy it
With all that preparation, there is nothing which could
possibly go wrong. Sit back, take a deep breath and relax. Public speaking is an honour and a
privilege, something to be enjoyed and relished, not something to be nervous about. Do your best to
be focussed and relaxed, speak loudly and clearly, and smile at your audience. And it will work like