Developing Successful Demos

Over the course of my career I've had the opportunity to lead or be in the audience for dozens, if not hundreds, of technical demonstrations. I would assume that this is actually fairly typical for many engineers in the tech industry, and yet despite this, so many in our field find the act of leading a demo to be difficult. Even if you haven't had to lead a demo, it is quite likely that you have at least sat through a bad demo. Maybe the speaker was not engaging, or maybe it was uninformative, or most likely the product just didn't work. 

So why are technical demonstrations, something that is so common in our industry, so hard?

I don't think the answer is all that surprising: Most engineers like building things and aren't necessarily skilled or trained in public speaking. Most demos are given in non-ideal environments. Most products are still under active development which can sometimes lead to breaking changes or missing features. etc., etc., etc.

Rather than try and solve all of these issues, because I don't think you truly can get rid of 100% of them, the advice I will offer instead is that we re-frame how we view technical demonstrations. A demo is, at its core, a story about your product. Most people focus solely on having a good product (and for good reason!), but a good story forms the foundation for a good demo, and without it no matter how good the actual product is, the demo will not be memorable or effective.

Give enough demos, and eventually you will forget a line, or a critical feature won't be ready on time, or something will break. There's no amount of planning and scripting that will prepare you for every eventuality. But if you develop a compelling story, and keep laser focused on telling that story, then you can more easily adapt and improvise to still give a successful demo in spite of whatever issue you face.

How exactly to develop a compelling story is something people much better than myself spend their entire lives trying to learn, so while I'll leave most of that to the experts, I will recommend starting by answering some framing questions:

• What are you selling? It seems a bit obvious, but really try to take the time to understand the product itself, what differentiates it from the competition, and what it is offering the buyer. Keep in mind that sometimes the product you want to sell is not actually the tangible thing you are showing, but rather the person or team or organization behind that thing.
• Who are you selling it to? Are they prospective buyers, existing customers, your own boss or company leadership? Are they primarily technical, or more executive? Are they the ones who will actually be using the product? Ultimately you are asking what do they care about and what will resonate with them?

Once you have established the 'who' and the 'what' you can then approach your demo by thinking about some of the general principles that make for a good story. 

• A story is not just a list of facts. Of course facts are a good thing, and lend credence to your product, but they are meant to support the story, not the other way around. This is NOT saying you should lie, quite the opposite, but if you find yourself listing things like supported protocols then ask yourself if this is adding to the story, or if it can be skipped and instead refer someone to the documentation.
• A story is not a 'how-to' guide. There may be elements of how easy it is to accomplish something in your demo, but if someone needs a detailed step by step process guide then they can refer to the documentation.
• A good story is relatable. Even if what you are showing is a critical differentiator and nothing goes wrong, if your demo is not relatable to the audience then they will likely walk away with a 'so what?'. I recommend developing a comprehensive story that hits on all major points or features and then tuning each demo with only a subset of those 'chapters' based on each individual audience and what they care about.
• A good story is singular and self contained. It can be tempting to try and pack in several different threads in an attempt to throw spaghetti at the wall and see what sticks. The problem is that doing this can lead to overly long and complex demos that leaves the audience remembering a bunch of moments, but not the main point of your story because it got lost in the noise.

If you've established a clear plot thread in the audience's mind, then it doesn't matter quite as much if the button you click actually does the thing it is supposed to do, or if you just tell them what it would do if it were implemented. You can more easily adapt and improvise because you know the framework of the story. In fact, I would argue that with a compelling story to your demo, you can be 100% up front and truthful about what works and what doesn't, and it won't matter.

 

We humans are wired for telling and listening to stories. Our brains will more easily remember stories, and can automatically fill in gaps if needed. The iconic Star Wars bounty hunter, Boba Fett, has approximately 6 minutes of total screen time and only 4 lines in the entire original trilogy. Despite this, he became a massive fan icon generating a significant lore and still remembered today. A good story will draw people in, be memorable, and leave them wanting more. Whether it is a demo, a presentation, a report, or anything else in your job requiring communication, stop and ask yourself what is the story I am trying to tell?