Demos Done Right - When Things Go Wrong

No matter your experience level hosting software demonstrations it is likely you have experienced an unexpected behavior in the software while everyone is watching. Every live demonstration is susceptible to errors, and they are inescapable. So how should a presenter respond to the unexpected? This post is designed to use common sense to answer that question.

Before jumping into the answer, it is important to remind ourselves why we should spend time focusing on our responses in undesirable situations. As discussed in multiple posts earlier in this series, we focus on building a strong relationship. A strong relationship will amplify the highs of the software development cycle and dull the pain during the lows. Responding incorrectly during tenuous situations is received as dishonest, eroding trust, and ultimately degrading the foundation of the relationship. Errors in software are much easier to repair than rebuilding trust that has been lost.

Next, let's talk through some strategies when we are in the moment an error appears on our screen during a live demonstration. In the instance the demonstration intends to show an error state, before putting the software in the error state it is important to prepare the audience that the data will result in an error state. As I prepare to show the error state within the application, I will first talk through the inputs, or lack of inputs, that will result in the error state. Once it is clear to the audience what will cause the error state, I will then act to reveal the error. While forcing error states is common, more commonly the errors shown to the audience are not anticipated.

All the data is prepared and the audience is excited to see the new functionality the team has developed, then the functionality fails. My first recommendation is to take a moment to pause. In this pause review the data inputs. Briefly, confirm all the necessary pieces are in the appropriate place. Often, I find the mistake is valid and the issue is the data entry while trying to talk through the feature at the same time. As the invalid inputs are resolved, I make it a point to discuss with the audience what is invalid about the inputs and why the inputs are incorrect. I do this, because, audience members may experience a similar issue when using the software.

If you are not so lucky and the error does not appear to be a data input error. I will often talk through what I was expecting to occur, instead of the error state that was encountered. Sometimes attempting to execute the functionality again with different inputs. This retry gives me and the team the time to demonstrate the thought process and gather additional data on the error. During this retrial, I will often direct an engineer not participating in the demonstration to begin investigating. The goal of starting the investigation during the demonstration serves a couple of purposes. The first, and most important, build trust with the audience that the team has the situation under control. The second, gather data while the error is occurring to get a head start at resolving the issue. Lastly, the continued investigation as the demonstration continues, the investigator often has additional information to share with the audience before the meeting is over.

Once, each of these tactics has been executed and the error persists it is time to move the conversation forward. Sometimes that is moving on to showing the next feature in the demonstration. Other times it is a conversation to discuss when the error will be investigated more deeply and resolved. Both of these are fine options for continuing the conversation and not remaining stuck on the error. Often, I will choose to continue the demonstration. Then when summarizing the demonstration I will open up the conversation to the next steps on the error. This pattern has worked best for me, as the summary of a demonstration has a logical lead into what is coming up next.

In this post, we covered some tactics to handle situations when errors are experienced and not expected. Reminding ourselves that the relationship is the most important component of the demonstration, as software is easy to repair in comparison. Pausing, retrying the functionality, and describing the expected behavior when an error occurs, instead of trying to hide errors in the application. Quickly involving other team members to investigate the error, with the desire to provide quick feedback on the issue. Building confidence in the audience that the team understands what is important and the team had a great handle on building a quality product.