Demos Done Right - Start at the Beginning

In this post, we will highlight the start of a software demonstration. Generally, this series will focus on three types of presentations: stage talks in a conference or meetup setting, single-instance presentations where the audience is much smaller and more sales-focused, and recurring instance presentations such as a sprint review, where the audience is fairly consistent for each execution. While each type differs from the other, they all should start the same way.

Often, I see technical folks start a presentation by jumping right into the software, completely skipping the fact that they are human and have a name. As you begin any new relationship it is important to provide your preferred name. Part of being human is the desire to connect. How can one truly connect to another if we do not have enough information to address each other correctly? Since these posts are in the context of a technical presentation odds are you are working for an employer and have a specific role at said employer. Providing that information is also very helpful to the audience. With all this information, the members of the audience can use their judgment when asking you questions as they arise. It's not often that a software engineer can recite stipulations within a large contractual agreement or any information in the contractual agreement. The audience will know that you are the right person to ask about system availability, scalability, and support tooling.

When beginning a conference talk or a single-instance presentation you should always start with your name and role at a minimum. Often, single-instance presentations start with introductions, even in that case as soon as it is your time to present re-introduce yourself. I will often say "Once again, my name is Andrew Schwabe. I am a senior engineer here." But, why? When the group is going through 20-30 names in just a couple of minutes, there is no way everyone was able to internalize my name. At least not enough to feel comfortable stopping me during a presentation to ask a question. With reoccurring presentations, the rules change slightly. These types of presentations often have the same group of people each time. Depending on the frequency of the presentation I tend to stop introducing myself after the fourth execution. The more frequent the discussion, the sooner you can stop saying your name. The less frequent, I will consider extending the number of introductions. This count is not a strict rule, the count is based entirely on the relationship being built with the attendees. It is inevitable that the group in a reoccurring presentation will change, as soon as it does, the introductions begin again for a minimum of 3 introductions. This is to give multiple opportunities for the additions to the audience to build name and face recognition.

Now that everyone knows your name it is time to jump directly into the software demonstration, right? WRONG! Same as with missing our name, technical minds are in the software all day, every day. We have trained ourselves to hop in and out of code whenever it suits us. Our audience is not in this technical world all day, they need context to frame what is about to be shown to them. That context can take many forms, there is no one right answer. In the case of a conference talk, the context can be as simple as what prompted you to perform this work. Or a question that you wanted an answer to. Setting context in a single instance presentation could take the shape of waste reduction in workflows or mitigating corporate risks. Often in the reoccurring presentations business value is the context to provide before showing off the changes. This thirty seconds of context before showing any software allows the audience to meet you closer to where you are. So when the software demo starts everyone can already begin to see how the features presented fit into the larger picture.

With these two small tweaks to your upcoming presentation, you will begin to build stronger more connected relationships with the audience. Then set the software up for success, by guiding the audience into what they can expect from you. If this is done well the transition into how what you built solves their business problem will be seamless.