Demos Done Right - Feedback

Even if you never present to an audience or follow any of the advice in this series you will still get some form of feedback in your development journey. Some could be positive, some will be negative. The feedback may be actionable or it may not. In this final topic, we will discuss how to manage received feedback, deciding what is worth taking action on and what is just noise.

Since this entire series is dedicated to becoming a better presenter while demonstrating software, we will narrow the scope of this particular post to feedback regarding the software content of the demonstrations. However, similar tactics often apply to other situations where feedback is provided to you. I have personally used each of the upcoming tactics to clarify feedback and prioritize feedback across a broad spectrum of encounters.

Imagine you are in the middle of a demonstration just about to click a button to perform an update action in your software, then a comment rings out. What do you do? Assuming we have read all the other content in this series, you have seen the answer to this question already. First, take a quick moment for a pause to digest the comment. During that pause jot a quick note to capture basic information. I will often start with the root of the comment, where the demo is currently stopped, and the commentator. In my experience, taking note of where the demonstration is paused assists with the pacing of the demonstration. If I often receive comments about what was demonstrated before the current functionality, that tells me I am moving too quickly through the demonstration and should pause a little longer between features. As you collect more data from presenting, you too will find some interesting parallels, and how you can adjust delivery to refine your approach. My personal preference is to take notes on paper or a tablet with a pen, as I find typing all the information in to be too difficult to execute quickly enough and drawing on a PC to be too cumbersome when a drawing is the more effective form of communication. . with this basic information it is time for a decision.

Now that the note is taken, the decision is to tackle the comment now, defer it until a later point in time, or not engage with the comment at all. Comments from the audience that require little thought, or the team has already received should be quickly acknowledged, then you should move on with the demonstration. It is a waste of everyone's valuable time litigating feedback that was discussed at an earlier time. This is the same approach I tend to use when the implementation cost is less than the cost of the discussion. In these situations, I will give a quick update on the current state of the feedback; such as, if it is an item on the backlog, or if we have heard that feedback from others and are considering the priority compared to other work for the team. There is no need to sugarcoat the response, generally, the audience is interested in knowing the concept is understood and the team understands the need. This approach is unlikely to be your go-to as you navigate this journey, however, you will learn to love it as you get more comfortable with presenting.

The most popular option when receiving feedback is to start digging into the comment right away. This is often my preferred approach, as most feedback is a possible solution to the root of the problem, not the root problem itself. All questions I ask the commenter are to drive to the actual problem they see or are having. Trying to see the issue from the perspective of the commenter, to try to figure out whether or not the feedback is worth considering. I try not to hang on the line of questioning too long, if you are unable to figure out what is motivating the feedback in 5 questions or less, it may be time for the next tactic. One common mistake is letting the discussion drag on too long. This causes the remainder of the presentation to be pressed for time, which no one wants. So, be cautious when you choose to dig into feedback and for how long you hold on to the conversation.

The last approach is deferring the conversation to a different time. This was always an approach I never loved, that is until I used it a couple of times. Then I learned what a wonderful tool deferring a conversation is. In instances where you know there is limited time to discuss feedback, it is important to make sure the feedback is heard. What is not always important is that the feedback be heard at this moment in time. In these cases, defer the discussion to a later time in the presentation, to a later time on the same day, or even to a different day altogether. Another use case for the defer tactic is when the feedback is off-topic. When this happens, defer the conversation until a later time. Not everyone watching the presentation needs to hear the response, frankly, some of them do not care what the answer is to the off-topic feedback. An extreme case to use this approach is when the feedback is specific to a single person in the audience. It is possible that responding in the moment to feedback will satisfy one or two members who are interested in the topic, and lose everyone else who was paying attention until the conversation took too long to complete. Choose wisely when to defer a conversation. When you do choose to defer, take notes and get the time scheduled as soon as possible. Failure to follow through on the deferred conversation will result in lost trust in the relationship.

In summary, when receiving feedback it is your choice on how to handle it. Always acknowledge the person, document the commentary, and then choose how to respond. In this journey, you will make mistakes, the most common is digging into feedback when it will derail the remainder of the demonstration. Learn from those mistakes and apply the learnings to the next opportunities.