As you work in the software industry, you will inevitably need to demo your work. This can take different forms: live coding in front of an audience, pitching a SaaS app to a client you must land, showing your boss’ boss’ boss a prototype to pitch a new team, etc. The good news is that with preparation, you can get better results than winging it. Don’t get me wrong. I love winging it. But imagine you could spend a few hours to make your audience remember you. Wouldn’t you do that? I would.
A quick caveat! This isn’t about giving a presentation or a talk. This is much narrower: how do you demonstrate software or hardware? My goal is for people to watch your demos and walk away and say “Alice/Bob/Carol/Dave’s demo was pretty good!” I’m not promising that you will give world class demos. I don’t. You know those talks where Steve Jobs invited the whole world to an intimate storytime? And he’d give a short demo that showed the value that an iPhone added to your life? Jesus. I can’t help you there. But I can offer tips to give your audience a fighting chance of remembering what you showed them.
Where did I learn this? I worked at a computer vision research lab for a few years after I graduated college. Its business model involved sales overselling our abilities and resources to land robotics and computer vision grants. Engineering took this money and produced prototype systems. Government employees would then come and verify our progress just to make sure we weren’t pulling hijinks on ol’ Uncle Sam.
Our prototypes were “researchy” and barely worked by any objective measure. But we took this madness and used it to build reliable and successful demos. Our division would have failed if our demos sucked. But we reliably drummed up new and repeat business from this.
I participated in hundreds of demos when I worked there and watched many more. This was on top of thousands of practice runs. We developed a set of loose guidelines for giving demos that reliably produced good results. I have successfully applied these principles to demoing other things like web apps, so I have some confidence that they are generally applicable.
Consider these points à la carte. It’s hard to apply everything all the time. It’s easy to try a few of them. Pick ones that seem achievable! You’ll be surprised how much more your audience will understand with just a few simple tips.
Craft a demo for each audience
The whole reason you are giving a demo is because someone wants to watch it. Give them a good experience. I have a tendency as an engineer to show off the most complex part of a system because that’s the most interesting to me. But a potential user doesn’t want to see something I overcame. They want to see something that provides them value. Think about your audience and ask yourself a few questions about them. What do they care about? What do they want to learn? What do they need to see?
For instance: at my first job we had a prototype robot that could autonomously retrace its steps if you drove it somewhere. Grab an Xbox controller and drive it around for a while. Press a button and BAM! It turned around and drove back to where it started. Now imagine that we had two demos scheduled for the same week. One to a lawnmower manufacturer and the other to bomb disposal technicians. We could have given the same demo to each of them. They may have gotten the point. But we got better results by crafting demos for each group. Think about building an autonomous lawnmower. They want a robot that runs in neat straight lines and it definitely cannot randomly veer into the flower bed. It’s life and death. Now imagine the bomb disposal technician’s job. They may want to recall the robot from dangerous areas with limited WiFi because otherwise one of their coworkers may need to suit up to retrieve it. It’s life and death.
You should confirm this ahead of time when possible. Just send them an email and say, “Hey! I want to make sure your time is well spent. We imagine that tracking over a whole field is difficult. We were planning on demoing how our system handles long straight paths. Are you interested in seeing anything else?” You might find out that “No no! We have straight lines pretty much nailed. We’re having trouble with neat and repeatable turns.” This gives you extra time to build a scenario demoing how your system handles twisty paths. The result is a demo that is more interesting to your audience by design. This is better than showing a robot weaving around a car twice and the lawnmower company thinking “cool, but it’s not doing tight turns so I don’t care” and the bomb disposal technicians thinking “they’re keeping it within range of the WiFi antenna, I wonder how robust this is”
It’s also useful to consider the breadth of experience of each audience. Let’s say I was demoing a new library at Etsy. A typical audience might have software engineers, engineering managers, and product managers. What do they all have in common? They all want to launch features faster! So I would focus my demonstration on how the library requires product developers to write less code while being easier to understand and test.
Explain to the audience what they are seeing and why they care about it
Audiences don’t give you their full attention when you present. I know this because I often do not give people my full attention when they present. Mea culpa. Also, if your audience has more than a handful of people, someone inevitably has a partial view of the screen and can’t see everything you’re doing. And frankly, sometimes your demo isn’t as clear as you think it is. This means you should overexplain what you are doing and explain why it is important.
“You see that the robot is driving over the curb. This means that the obstacle detection algorithm understands the difference between a curb and a car. It doesn’t get stuck on things it can drive over.”
Overexplaining sounds like a negative. Overeager. Overzealous. Overcooked. It’s a bad prefix. But a demo is not a conversation and doesn’t have the same social rules. You’re basically a live stream of audio and video that can’t be rewound or slowed down for clarity. You need to tailor your script to always explain what you are doing and why.
Imagine you were demoing a computer vision program that counts the number of people in a scene. “I’m seeing if the output exists by running ls. Great, it’s here. Now let’s cat the contents. We see that it has the number 3. This is good because the source image has 3 people. That means it detected how many people were there. Yay!” Someone who only listened to this fragment would understand a great deal about your demo.
- The presenter was demoing a people detector.
- It’s maybe not production-ready since it requires outputting data to the filesystem.
- It was run live.
- It worked.
This is roughly the level of detail that you want to target when you demo something to a general audience. Practicing will help you tune this because it helps you understand when you should add or subtract.
Your preparation should match the intensity of the situation
At the computer vision lab, we got the best results by continuing to practice long after we hit diminishing returns. These were high-stakes demos though. Our business depended on them. If I was just showing my team something, then I would just do two or three runthroughs. “Exceeding diminishing returns” is something I’d break out for high-stakes demos like “we’re hosed if we don’t land this contract” or “we’re doing multiple 12 hour days of demos to dozens of potential investors.” The goal is to use all the time you have available to learn everything about the failure modes of your system.
What does preparation for a really intense demo look like? At the robotics company we had big checkpoint demos several times a year. If the government employees weren’t happy, we probably would not get followups or new business. It would have been game over if we failed them. But we reliably drummed up new and repeat business even in the face of major things going wrong. This is because we practiced for weeks until even the breakages were boring for us.
We went through a few phases when doing this level of practicing.
The first phase was rough. We’d be compiling on laptops next to the robot and transferring stuff over on USB sticks. We’d start practice the second stuff might work. And stuff always went wrong. Practicing in a lab is much different than running a system in the wild. We’d learn that the sun overwhelmed our LiDAR systems in daytime. Our C++ work threads would crash. Pan/tilt units would break because the moving robot would put too much stress on them. Nothing worked and nobody was happy. We’d spend hours or days fixing software and hardware bugs.
Eventually this would settle down. Things would gel. The software would stabilize. We understood the limits of our hardware. But our managers insisted that we keep practicing. They knew better. And they were right. New things would break. Weirder things. For instance, commercial cables aren’t usually rated for military use. So the cables would eventually experience brief disconnects and some of the experimental hardware would freak out. We’d uncover weird software bugs like “The robot drives forward until killed when it moves by a wall at a certain angle.” We’d learn how often we needed to recalibrate the cameras. We’d understand how to tear down and rebuild the hardware on-site. We learned how many spare batteries we’d need.
This level of preparation had a few major benefits. First, we learned tons of properties about our full system. We understood roughly what should be replaced, when it should be replaced, and what to look for. More importantly we felt that component failure was a nonevent. We practiced recovering from errors by practicing until we experienced errors. It didn’t matter if they happened during the live demo. We could just laugh it off and keep going. “Hah, wow! We were excited that you were coming so we practiced all morning. Looks like we forgot to swap a battery after lunch and the camera battery died. We’re changing it now and then we’ll pick up where we left off.”
All these examples have been robotics examples, but this is NOT limited to robotics. All software fails. Imagine that you’re going to present a website at a conference. Have you ever seen a demo fail because a WiFi access point is overwhelmed by the number of people connecting to it? I sure have. Make sure that your demo works when WiFi is down. Make sure it works when you have realllly sllloooowwww internet. Practice checking it out and running it from scratch. Make sure that it works if you need to run it from another machine at the last second.
This level of practice also helps with stage fright. I’ve had to demo in front of large crowds a few times. I get nervous every single time. I’ve been so nervous that I have no memory of what happened. But videos show a different story. I look calm and collected. I’m roughly following the script that I’ve practiced dozens of times. I mean, it’s not amazing. I’m still saying “um” and what am I doing with my hands? But I’m getting the job done and following a script that is meaningful for the audience instead of going through the demo by rote.
Embrace show-stopping errors and ignore the rest
Imagine that you’re demoing a new React component for your website. You open up developer tools to show the audience something. You see an error in the Console that is unexpected. Something about the Content Security Policy for a marketing library you’re not demoing.
Just ignore it and go on. This goes against your natural instincts. I’ve been there. I know. You want to tell everyone that you didn’t cause this failure. “Oh, weird. There’s a Content Security Policy error in here. I’ve never seen that before. That’s not related to the demo. OK, now let’s see what the React tab has to say”
It’s not related to the demo and it’s not blocking? Just ignore it. Half the people aren’t paying attention, and the other half will see you ignore it and figure it’s not important. You already have your audience following you through some Real Nerdy Shit if you’re cracking open developer tools. Continue the story. Show them what they need to see. Explain to the audience why it’s important. Ignore the small errors. They don’t matter.
Now let’s say that something happens and you need to restart. This is majorly disruptive to the demo’s flow and is worth explaining. “Whoops! Let me read the error message. Ah, the login cookie expired. Bad luck! OK, I am going to log in real quick and try again.” The audience is going to be pretty chill about it. Just keep them posted on what you’re doing. Worst case, if the demo is unrecoverable (it happens), just describe to them what you were going to show them and what you hoped they were going to take away from it. The worst has already happened. It’s not going to get any worse because you tried to explain what you would have shown them.
Make the participant part of the demo when possible
Demos can be fun. Interactive demos are more fun. Does your demo need a name? Don’t enter foo. So help me god. Enter “Ishmael” and ask the audience to call you that. Showing off some hardware to somebody? Let them control it if time and safety allow. Engagement dramatically increases how interesting a demo is. “The robot followed a path” versus “I drove the robot and then pressed a button and then the robot replayed everything I did!”
This matches my own experiences watching demos. For instance, I don’t remember much about the museum I visited in Anchorage, Alaska. But I remember the exhibit that showed what I look like when filmed with an infrared camera. I even took a damn picture of it.
Summary: my coworkers are gonna be real mad when they watch me give a terrible demo in the future because of how long this post is
You’re a busy engineer. I get it. You could definitely get away with just showing your audience the 5 different versions of the view that you created. But it’s worth considering…
- What does this specific audience want to see?
- Are you prepared to explain what the audience is seeing and why they should care about it?
- What does your audience care about?
- Has your preparation matched the intensity of the situation?
- Is there a way you can include the audience?
By considering these 5 things (damn, I should have added the number to the post title), you will have a leg up on people who just mechanically go through the motions because you will say things that are meaningful to the audience and you will have practiced saying it to them.