Stop Doing This: 4 Data Storytelling Mistakes That Lose the Room

Lessons learned from real stakeholder meetings that went sideways

Setting the Scene

On one of my first deliverables to a client, I flopped. I was so paralyzed from the mound of code I had inherited, I failed to engage the business from a problem-solving mindset. Instead, I boiled the ocean trying to deliver 80 KPIs under a tight deadline.

Furthermore, when I proceeded to deliver five of the most important customer behavior KPIs (frequency of purchase metrics), I literally just shared my screen and looked for a reaction from the business.

I was so caught up in trying to perfect the code, I didn’t even ask the business how they were using these metrics. This GREATLY inhibited my ability to present the data from a problem-solving framework.

What questions were they trying to answer? I had no idea. Due to this, I couldn’t relate the metrics to an actual scenario for decision-making.

This experience inspired me to focus on the challenges faced by data analysts when presenting dashboards and reports. We often hear about what you should do when engaging with stakeholders. But what about the things you SHOULD NOT do?

Buckle up and get ready, because we’re going to highlight the top 4 mistakes data professionals make when storytelling data.

4. Allowing the stakeholder to control the conversation

In the data space, your duties are critical to the improvement of a company. Due to this, interacting with key decision makers is a natural part of the job. What you’ll often find is that executives have egos.

These egos lead to difficult conversations when delivering data reports and products. I’ve experienced executive conversations that get far too technical for their own good. Some executives are technically savvy. They think they know best for a given data solution. Whether that’s how to architect or visualize something, they’ll have strong opinions about how a data report should look or be built. This leads to them controlling the conversation.

Due to their position on the hierarchy, it can be intimidating to take a leadership step forward and guide their thoughts. Analysts newer to this game will have to get their confidence up before avoiding the trap.

3. Explaining Technical Concepts When Presenting a Metric

It can be extremely hard to translate complex business processes into a data structure (ie. data model). It becomes even more challenging when you have to link the code to the process. Due to our depth of knowledge in SQL and relational data modeling, it becomes tempting to vocalize technical concepts out loud during stakeholder brainstorm discussions.

As a lead Looker consultant for a $100M FinTech company, I made this grave mistake time and again. We’d be talking about their marketing source system and how to track customer attribution. We had no way to uniquely link a Google Form Fill to their Oracle Eloqua marketing automation tool’s signup data.

Instead of breaking their process down and focusing on fixing the workflow at the source, I verbalized why a SQL join was impossible to link to Oracle Eloqua. I detailed the non-unique combination of keys I was trying vs. what would theoretically work.

My deep-dive into how a SQL left and inner join works only created more tension with these marketing stakeholders. NEVER DO THIS.

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

It’s one thing to demonstrate how a dashboard answers a question. It’s a whole other thing when an analyst builds a shiny dashboard with all the bells and whistles, but can’t demonstrate its relevance to their problem.

Instead, far too often I see junior analysts point to the complex features they’ve built and say here they are - this is what the Jira ticket asked for. This creates a whole lot of silence from stakeholders.

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

Similar to number 2, a huge mistake made by analysts is failing to put themselves in the shoes of the business and stakeholders. Being handed a list of KPIs to build by a Product Manager and then blindly building them without business context is a HUGE recipe for disaster.

I chose this as number 1 because it’s a common issue seen in the data analytics space. Furthermore, like I described in the beginning, this was a tough learning lesson for myself. Company executives have no patience, and view data analysts as part of IT (typically). Instead of allowing data analysts to partner with them strategically, they treat them like a developer.

Next thing you know, you’re presenting a laundry list of KPIs you built without context. Which ones actually help answer this stakeholder’s questions? No idea. It creates an order taker culture, and the idea of storytelling with data gets completely thrown out the window.

You are no longer thought of as a strategic partner that helps increase revenue, save time and increase profit, but rather a behind the scenes code monkey.

Keep Fighting the Good Fight

Next week, we’ll take a look at solutions to all four of these problems. If you’re now realizing you’ve experienced some of these, know you’re not alone. I listed all four of these because I’ve experienced all of them!

The first step to improvement is recognizing the pitfalls and dynamics that happen in stakeholder meetings. Give yourself some credit - business review meetings of your reports/deliverables are never easy. You’re usually dealing with extremely detail-oriented and high achieving executives.

This naturally creates an intense, opinionated and thought-provoking environment. You’re having to balance the art of data communication/storytelling with the science of logic and code. Know that learning to reduce the above issues will greatly impact your effectiveness when delivering insights to stakeholders.