Conquer Data Storytelling Mistakes

The solutions to our 4 big data storytelling mistakes

Recapping From Last Issue

Last week we covered our top 4 mistakes when storytelling data to stakeholders. As promised, we’re diving into solutions for all of these in this issue.

Again, we landed on these four because we’ve personally experienced all of them. These aren’t something we generated using ChatGPT. At the end of the day, a data professional’s technical bubble is one of their greatest strengths, but also one of their greatest weaknesses.

Getting too deep into code, statistics and methodology takes attention away from the value data is driving for business stakeholders. At the end of the day, what is the point of all the code and theory if it doesn’t help drive bottom line and efficiency for the business?

Our plan is to cover a section for each solution to these mistakes made (at some point in my career). Our hope is that the last issue made you aware of these. Now we will give you the tools to avoid and combat these mistakes completely.

4. Allowing the stakeholder to control the conversation

Don’t overcomplicate this one. The human dynamic at play here can be enough to feel overwhelmed. Someone in a position of power vs. you, an individually contributing analyst or engineer, doesn’t have the authority. A huge realization I’ve gained throughout the years in data analytics is that it’s not about authority.

The key is to be direct, ask thought-provoking questions, and guide the stakeholder’s attention. It’s natural for stakeholders to poke and prod around the data solution you present to them. However, do not be reactive to the questions they throw at you. Even if they point to something that is incorrect or don’t like, acknowledge it, thank them and ask what they were expecting to see or what they’d prefer, tell them you’ll look into it. Then move on.

There can always be an additional conversation for changes and iterations on a dashboard. However, the most critical takeaway is to just keep moving.

3. Explaining Technical Concepts When Presenting a Metric

Diving into SQL concepts with stakeholders is a dangerous game to play. Like I said in issue 8, it can be tempting to get into technical concepts because it’s our default as data people. If you’re being pressed, use a metaphor as to why a SQL join or code logic isn’t going to work.

I’ve given this tip in a prior issue about semantic layers, but it’s a good one. Use AI to help craft a metaphor for your given technical solution translation.

The other option is to avoid it completely. Don’t dive into the details. Just say you’ll have to look into it and move on.

However, the dynamic gets interesting when a few stakeholders in the audience may be more technical themselves. The conversation will inevitably get into the weeds. In this case, do what I suggested above and use metaphors.

2. Talking about the features of a dashboard but not relating them to how it helps make decisions

The solution here is simple. First and foremost, always ask yourself what relevance a given feature or fancy bell & whistle has for answering a stakeholder’s questions.

Secondly, walk through an actual example with them using that feature! Like I said in the prior issue, nothing is worse than an analyst who is proud of a feature they built, aligned to acceptance criteria, and shows up to the meeting excited to show that they built the thing.

Without running through an example and showing a stakeholder how it answers their question in real time, they do not care. Demonstrate to them why they should care!

1. Presenting a Report / Metric / KPI Without Knowing How the Stakeholders Will Use It

Do not take orders from the business or a product team on metrics/KPIs to build without discovery first.

To deliver the best data model and dashboard presentation possible, it’s necessary to ask some critical discovery questions to the stakeholders.

• What are your objectives/goals for this month,quarter,year, etc.?

• What do you want to result from hitting those goals?

• What is the source system(s) you’re using to capture your current metrics?

• How have you historically reported on this data?

• What actions do you take on behalf of this data?

• Who is this data presented to?

• Have you thought about X, Y, Z KPIs also?

The goal of this questioning exercise is to strategically map business objectives to outcomes by using KPIs to track an objective’s progress. It enables you as the analyst to gain a far deeper understanding into how they think, what they care about, and which data points will help them to improve in their day to day work.

By backing away from the KPIs/metrics they’ve historically used and are telling you to build, you’re able to dig deeper into their real motives and determine KPIs/metrics to track that they may have never thought about. This breaks the divide from being an order-taker to a strategic data advisor (good approach to use for number 4 as well).

Focus on Improving These to Thrive

Overall, countering these critical data storytelling mistakes requires you to be confident, curious and strategic. Thinking of yourself as more than just a technical wizard, but rather a partner to your stakeholders is what levels up the bar for stakeholder communication.

Just keep moving the conversation and guide the stakeholder. Furthermore, leverage metaphors when absolutely necessary but stay away from technical jargon as much as possible. Demonstrate, don’t show. And always get an understanding for a stakeholder’s business goals and what they want to achieve by setting those objectives.

If you embrace the strategic partner mindset, and exercise the solutions laid out in this issue, you’re well on your way to being one of the most trusted analysts and strategic professionals at your organization.