Tell Story - Inspire Action
Goal: Use data to help make decisions.
Problem: Including data in the presentations often flies over everyone's head.
Situation: Even if the presenter is visualizing the data, and labeling it correctly, they are still leaving the interpretation to the audience —> that extra work for the audience adds cognitive load —> naturally look for shortcut interpretations —> that will create arguments and confusion —> no action is being taken or, even worse, the interpretation was wrong —> as the result, the outcome was not what you expected.
Possible Solution: Take responsibility for interpreting any and all data you are presenting.
Some time ago, in addition to the Voice of the Customer channel, I volunteered to post a weekly summary of the user feedback findings. My vision was to provide Business and Engineering teams with some qualitative insights that might spark interesting discussions and lead to more experimentation. Everyone liked the idea. I was excited and ready to roll.
The process was clear: everyone knew where I would post it. The timeframe was set: everyone knew when I would post it. As a measure of success, I would monitor Slack comments and count every new idea that makes it to development as a positive outcome.
After a few weeks of sharing insights and enjoying active engagement, I added categorization of the feedback left in the NPS surveys:
Most Promoters care about feature X
Most Passive users care about feature Y
Detractors do not seem to care about any particular feature, with high variability in requests
The first week of posting that additional variable, I did not get any questions and assumed that my team just did not have anything to add at the time.
The following week, encouraged by the early findings, I made a bold move. I pulled up another dimension of data. I was looking for any correlation between users’ engagement with the app during the reported period(transactions, data filling, starting jobs, etc.) and the features they had subsequently requested in their NPS comments.
Which looked something like this:
Promoters, Passives, Detractors + ##of transactions/key actions + reported period => care about feature X, Y, Z
I felt like I stumbled on a goldmine. The report demonstrated how users who are taking key actions that help them do their jobs, tend to respond with a higher net promoter score and also ask for the same features that we already have prioritized for development. That was huge because it meant that our product vision was well-aligned with the users’ perceived value.
After I posted these findings, I excitedly waited for a burst of discussions and celebrations in the comments. Instead, five minutes later, I watched in terror as questions started to pop up one after another in the thread below. Some started arguing about what this data meant. Others were politely adding thumbs-up avoiding involvement. That’s when the CEO tactfully DM-ed asking for some clarification. Still a bit stunned, I managed to gather my thoughts to respond with a lengthy explanation. Then, as soon as I hit send it hit me:
I posted all that beautiful data that made so much sense to me but took no responsibility for translating it. I simply dumped the information on the team and drove off!
I ended up apologizing to the team and asking for more time to complete the analysis. After closing down the thread, I could not believe it. What was such an exciting piece of data to me, turned into 10 minutes of confusion for others.
I felt disappointed. The moment was gone.
How might they see what I saw? What could I have done better?
I decided to start by telling the story.
Any story is even more enticing with illustrations. And that’s where my nice chart and numbers would come into play.
After explaining the numbers to the CEO, and to a few colleagues, while hearing myself out loud, I realized something. The chart needed 3 parts each with a headline and a clear conclusion.
It was a much simpler presentation of the data with little cognitive load.
The audience only had to look at the numbers as a supporting argument instead of being forced to interpret it.
As a result, the discussions got re-ignited.
The numbers also became part of the story-telling. The engineers and the sales teams started to mention the stats in the internal discussions. The feedback became less anecdotal and more data-driven. It allowed us to move faster and act with confidence all because we started to pay more attention to how we present the qualitative findings and tell the story around them.