

Ask HN: Best way to react when your tech demo fails? - mrspeaker


======
hideo
A few things that have worked for me in the past, or things that I have seen
work in the past:

1\. Quickly "accept", mentally, that it has failed. If you're the person who
wrote the code, there is a chance you are surprised that it could fail so you
switch to debug mode. Don't do that, just move on.

2\. Keep talking. The show becomes more awkward when there is a large
uncomfortable silence. If your demo has a presentation alongside it, then
restart your app/whatever and quickly move on to your next talking point.

3\. If your audience is technically inclined, sometimes it's fun to just
quickly describe what went wrong. It could help you connect with your audience
better.

4\. Continue with everything else that can still work, and don't bring up what
failed! Unless something critical went down, there's a good chance the rest of
your system will work. The demo might not be as impressive as you wanted, but
it's always better than nothing. Oh and don't retry the same feature again.
Seeing it fail twice is worse than seeing it fail once, unless you know that
it works on even-numbered runs or something :)

5\. Carry a backup of your demo if you can, and switch to that quickly. It
always helps to have someone else along who can help you switch quickly if
need be. This may not be cost-effective or viable, but it's the best option.

------
tomgallard
Without seeming flippant, your number one priority should be to make sure it
doesn't. The only reliable approach to this (at least with an immature
product) is a 100% scripted demo that you have run through multiple times both
in your office, and ideally where you are going to do the demo.

Ideally you also want to avoid using any sort of live/ad-hoc data if you can
(you can trust that this is when an edge case is going to turn up!).

Script it, run through it multiple times and this will minimize the chances of
anything unforseen going wrong. If you are not technical make sure you check
off your demo with your technical guys so there's nothing they're
uncomfortable with on there.

Make sure you're not demoing on either a dev or a live system if possible. You
should have an environment just for demos which no-one else touches. Last
thing you want is someone doing a release in the middle of it. Make sure the
dev team know there's a demo planned in any case.

That said- inevitably things still go wrong, and most people accept this.
Smile, and move on.

------
aapl
Good advice here. I would like to add two things:

When Apple demoes desktop applications, they have multiple computers linked to
a keyboard-mouse-monitor switch. If the demo fails on one computer, the
presenter can quickly switch to a fresh system. IIRC there some videos that
show Jobs doing just this.

If you can't afford redundant systems or it would be unelegant to have them
around, make sure to make a video or a bunch of screenshots of the planned
demo. One of the most fluid "demos" I have ever seen was just a sequence of
screenshots. Because the presenter was pointing out things on the screen and
clicking on where he would actually have to click to make the next action
happen, it somehow felt more like a demo than a slideshow.

~~~
Someone
The ones I saw, they do not only do that when a demo fails. Almost every
single part of a demo runs on a different machine. That minimizes the risk
that your demo, by a series of minute deviations from the script, ends up in
uncharted waters (this is especially true in alpha or beta software). It
introduces a risk of inconsistencies between scene cuts. Those you can
minimize by making sure that the 'scenes' at cut points aren't too complex,
and by rehearsing, rehearsing, rehearsing.

------
jvrossb
-Always have a backup -Keep on going

An anecdote: I was demoing a game to someone on my iPhone. The game crashed so
bad it rebooted the phone (bet you didn't know that was possible.) As the game
froze but before it crashed out I immediately began talking to them and made
eye contact to shift their focus back to me. Kept on talking and making eye
contact so they didn't look at the phone and was able to pretend that it had
fallen asleep mid-demo. Hit the home button after it rebooted, entered my
passcode, and rebooted the game. Worked the second time and I don't think they
noticed the crash.

------
brk
Well, this is kind of vague, but generally speaking the best approach is
neither apologize or joke about it. Just acknowledge it simply and keep
moving. Don't go down a rat-hole of trying to fix it on the spot.

The best response is also often a matter of the product demographic/audience
and maturity cycle. I would handle a tech demo of a failed pacemaker
differently than I would handle a failed demo of a just-announced Instagram
competitor.

------
rachelbythebay
How about a bluescreen while demonstrating plug and play? Then you just laugh
a little, and say "that must be why we're not shipping Windows 98 yet".

<http://www.youtube.com/watch?v=vxzYJXn4MFY>

------
pikewood
There's some risk to this, but one option is to use a different path/account
that will still demonstrate the functionality to the audience. Of course,
there's the chance of having it fail on you again, but if you have a feeling
what's causing the issue and know how to work around it, then it might help
the perception of your app from "not working at all" to "not fully tested".

If you have a team behind the scenes that can fix it within the presentation
time, that might be a good demonstration of your ability to recover from the
inevitable issues that will arise.

------
terjeto
Always have a backup presentation. Either powerpoint, video or something else
that your are comfortable with. I believe that the audience will understand...

------
macowar
Prepare a demo video ahead of time. If the actual demo fails, show the video
in its place.

------
israelyc
Have a BSOD screenshot ready to pop up in the background. And alt+tab it.

