Demos Must Work

Surely that’s obvious, right? Well, you’d be surprised. Unless, of course, you’ve tried to give a demo and had it fail miserably…then, naturally, you won’t be surprised at all.

…and that makes the demo kitten sad.

[this post is part of an ongoing series of rants constructive observations to help HQers understand and appreciate what it’s like to be on-the-road]

Demos are funny things, and I’ve mentioned them in posts before, but there really seems to be a gap in understanding/appreciation between the people who give them, and the people who build them. Whenever these are different people, the potential for failure increases.

Here’s the point I want all HQers to appreciate: it’s vastly better to have a good-enough reliable demo than a slightly-better-than-good-enough demo that craps out half the time.

It’s vastly better to have a good-enough reliable demo than a slightly-better-than-good-enough demo that craps out half the time.

Surely that’s obvious? Apparently not.

I’m rarely the guy who builds the demo, but when I am, it works. I’m often the guy giving the demo, and so I understand, vividly, the need for it to work.

The audience expects that if the underlying technology doesn’t work, then you’ve had the good sense to fake it

Here’s the thing: the audience expects the demo to work. In fact, they expect that if the underlying technology doesn’t work, then you’ve had the good sense to fake that stuff. When you show a demo that doesn’t work, you’re conveying two messages:

1. Our technology isn’t reliable enough to work, even when we control every last little thing
2. We didn’t have the common sense to fake it or hack it to actually work…because we’re idiots

Or, in other words:

When you show a demo that doesn’t work, you’ve conveying two messages: our technology sucks; we’re idiots

I wouldn’t buy a solution from that company, for either reason.

Now, I work for a very honest, very Canadian company – we don’t fake stuff. So the potential is always there for something to fail.

How do we limit that potential?

Well, one way is to avoid making any tweaks to the demo once you get it working reliably.

Don’t make any tweaks to the demo once you get it working reliably

Allow me to get nostalgic for a moment…

I remember back in university – I’m a Computer Engineer from the University of Waterloo – we had a project in which we had to create a real-time operating system. This project culminated with a live demonstration of the OS, in which we had to show that we’d implemented all the required features. After many long nights, we finally had it all working, so we compiled it and uploaded our code to the demo server. For the live demo, you’d pull down your code (this ensured that we had submitted before the deadline), and you had ten minutes to both demo and make any fixes to make the demo work.

So, loads of effort, blah blah, got the last few parts working, celebrations, compile, upload the code. We immediately pull it down to test it out. And it doesn’t work. What the hell?

Well, it turns out that a member of our group had taken it upon himself to just make “a few tweaks” to a piece that was already working reliably. Suffice it to say we were confused, and we were not pleased. Why the hell would he mess with something that was working?

[sidenote: by all accounts that “member of our group” is now a successful Silicon Valley entrepreneur…which perhaps undermines my main point, so forget that you read this line]

And then there’s the recent time when I verified that a remote demo worked one night prior to a meeting, and then by the next morning when I went to show it to a prospect, it had stopped working.

…which brings us to the more general question, why do engineers as a group (I don’t want to pick on you, but you know it’s true) mess with things that are working? Because they have a desire to make it work even better (even if it’s only the behind-the-scenes stuff). This drive is great, and leads to better products in the end, but leave it the hell out of demonstrations. A minor or insignificant tweak is a dumb reason to lose a customer’s faith or respect.

A minor or insignificant tweak is a dumb reason to lose a customer’s faith or respect.

I’ve mentioned a demo I was a part of at a CableLabs conference many years ago, and how we were up late the night before getting the damn thing working, even though it worked perfectly in the office. Why was it suddenly not working? Because someone had popped into the code to make a few tweaks. WHY???

So, to the HQ people who are often the ones working hard to make the demo (which truly is appreciated), but don’t have to live with it crapping out in front of an important audience (a feeling that you need to feel to truly appreciate – there’s a profound difference between hearing that the demo didn’t go as planned and living that the demo is failing in front of everyone): get the demo working, and then fork the development so you can tweak the hell out of your own fork…leave the reliable demo in a reliable state!

Get the demo working, and then leave the reliable demo in a reliable state!

About Lee Brooks

Lee Brooks is the founder of Cromulent Marketing, a boutique marketing agency specializing in crafting messaging, creating content, and managing public relations for B2B technology companies.