I’m going to take you to a place that most of us dread going. It might trigger the same cortisol spike that you get when you hear an incoming Teams call. Take a deep breath. You’ve been warned.

It’s the monthly product performance review. The head of Sales opens one report, filters it to the appropriate month, and presents a value for growth. Looking good. Cool. Great. Moving on.

Next up is the VP of Product. She opens up a different report. Smack in the middle of her beautifully designed dashboard is the same growth metric. But wait— it’s not the same value! She pauses.

Joe Schmo, the new guy in Marketing, chimes in from the seat near the window. “Neither of those values are what my spreadsheet says!” (*slow clap* Thanks, Joe).

The meeting quickly derails and becomes a debate over whose number is the most right. Screaming and wild gesturing abound. The poor data team is watching from outside the glass walls, waiting for the catered lunch to start getting chucked against the window. Ok, I might be exaggerating on that last point.

What was supposed to be a targeted meeting that delivered a succinct answer to a critical business question has devolved into a debate over whose metric definition is the most correct.

Once that happens enough times, people stop asking what the data means and start questioning whether they should use it at all.

That’s when MY trigger happens: A stakeholder who has patiently waited for me to develop a beautiful, fast, clear dashboard has now lost trust in the tool. They download the data and pivot it themselves. They dig into the Excel file, looking for errors in the numbers. Time and resources are wasted evaluating the symptom rather than looking for the root cause.

The kicker is that the data is probably not even flawed. The data likely reflects each team’s unique understanding of growth. It’s the definition that is inconsistent. Not the reported values.

Trust in data is not created by prettier dashboards or more advanced tools. It comes from:

It’s not a stretch for me to say that the fastest way to kill adoption is to give users an answer they can’t reconcile with what they already know to be true.

I had a client go through this. Stakeholders kept seeing conflicting and confusing results in a high-profile dashboard about their supply chain operations. The instinct was to build a better report, one that cut out the noise and delivered only the mission-critical, top-line KPIs.

That first phase of the rebuild was bliss. I got to trim all the fat. Use my keen eye for aesthetic detail and my expertise in psychological processing to design an outstanding, clear, high-performing dashboard.

But once we stripped away all the excess, many inconsistencies, errors, and edge cases began to surface. Pulling at the threads, we discovered issues with the underlying logic and the way we were calculating certain metrics.

We then needed to take it a step further - why were we using these calculations to begin with? We had to go further up the chain to the business experts. What were the rules? What were the exceptions?

We began to notice holes in the logic that had gone unnoticed in the years since the metric was first calculated. New warehouses, new delivery routes, core product reassignments, had all snuck in and poked holes in our once-bulletproof calculation.

Ultimately, the dashboard rebuild facilitated a review of business logic that led to wider understanding and adoption of a mission-critical metric.

The real outcome was not just “the number changed”. It was that people could understand and defend it.

I’ve seen this enough times to know the pattern. People stop trusting numbers when:

One commonly overlooked root cause is the absence of documentation. Some report needs to be fixed quickly, a “Band-Aid” solution, just “get it out the door” and we will focus on the justification after the fact. Except somewhere along the way, the justification never gets written down. And then another emergency pops up. Another Band-Aid. All of a sudden you’ve got a bucket with more Band-Aid than metal, and no one has paused to consider that it might be time to replace the bucket altogether.

We can debate all day about how and why trust breaks down and why a piece of me dies inside every time a stakeholder downloads their data into a spreadsheet. But the important part is how we rebuild trust once it’s been lost. How do we replace the bucket?

Here’s what I propose:

Define it.

Agree on what the metric actually means.

Deliverable: Get the right people in a room. Give them snacks. Write down the business rules together. Follow the logic all the way back to the source: every input, assumption, and exception. If your metric has a numerator and denominator, define those too. If someone says, “Well, usually we…” write that down. “Usually” is where edge cases live.

Trace it.

Know where the data comes from and how it transforms.

Deliverable: Draw the journey. An Entity Relationship Diagram (ERD) is great, but it does not need to look like it belongs in a computer science textbook. Show where the data originates, what systems touch it, where calculations happen, and where the final number lands. Use logos. Use arrows. Make it understandable enough that someone outside the data team can follow it.

Test it.

Validate edge cases, exceptions, and real-world examples.

Deliverable: I’m thinking something that looks like a math assignment from 6th grade. Pick real examples, write down what you expect the answer to be, then compare that expectation with what the system actually produces. Test the normal case. Test the weird case. Test the exception someone swears “never happens.” Test an old example and a new one. The goal is not merely to see whether the code runs; it is to prove that the business rule survives contact with reality.

Explain it.

Make the logic understandable to the people using it.

Deliverable: Give users somewhere easy to answer, “Wait, what does this mean again?” Maybe that is a maintained data dictionary. Maybe it is an info icon and tooltip directly on the dashboard (my personal favorite). Maybe it is a searchable cloud document. I care much less about the format than two things: people can find it, and someone is responsible for keeping it current.

Repeat it.

If the same inputs produce different answers, you don’t have trust. Evaluate your data regularly. Repeat this whole process when the business changes, and/or on a regular cadence. The business evolves. Your definitions have to evolve with it.

Deliverable: Peace of mind.

Don’t think for even a second that AI is going to do this for you. It might (read: MIGHT) be able to give you a first draft of a data dictionary, provided you feed it high-quality business rules. It might be able to draft an ERD. But you need to provide the input, which means you have to do the work.

AI does not solve a trust problem. If anything, it amplifies one. If your definitions are inconsistent or your logic is unclear, adding a chatbot or predictive layer just makes the bad answer faster and more convincing.

A trustworthy data culture is not one where everyone agrees with every number. It is one where people understand how the number was produced, can challenge it with some degree of thought, and know what to do when something looks wrong.

The goal isn’t to make people trust the dashboard. The goal is to build a system worthy of trust.

-t

If your reporting has become a source of debate instead of clarity, ThinkFig can help. I work with organizations to align metric definitions, untangle business logic, validate reporting systems, and rebuild trust in the numbers people rely on.

If you’re spending more time arguing over whose number is right than acting on the answer, let’s talk.