A dashboard can be clean, complete, and technically correct, and still create no impact at all. Not because the numbers are wrong, but because nothing changes after people see them.
That is the uncomfortable part of data work: delivery is not the finish line. Use is.
Data only matters when it changes a decision
It is easy to focus on producing information: cleaner pipelines, better definitions, prettier charts, more complete reporting. All of that helps. But none of it guarantees impact. Adoption does.
What matters is whether the data helps someone answer a real question:
- What should we prioritize?
- Where is performance slipping?
- Which process needs to change?
- What should we stop doing?
If the output does not help with those decisions, it may still be informative. It just will not travel very far.
THE ISSUE IS FIT.
It is not because people hate data. It can be that
- the dashboard answers a question nobody is asking
- it delivers the answer in a format stakeholders do not like or trust
- it arrives too late, or too early, to influence a decision
- the audience does not know what action to take next
- the view is too broad or too detailed to be useful
- the metric is technically sound but disconnected from what the team is accountable for
In other words, the issue is often not quality. It is fit.
Adoption starts well before delivering the dashboard
But, if you get one idea from this post, let it be this: adoption starts long before delivery. Counterintuitive with what I’ve said so far? NOT AT ALL
Communication is part of the work, not a nice extra. The more you talk with stakeholders and sponsors during the project, the easier it becomes to build trust, catch needs as well as misunderstandings early, and reduce friction later, all these leading to adoption.
- Be intentional about Adoption.
- Build adoption workflow into the project plan
- Include adoption milestones
- Check you have adoption-related tasks (the uncomfortable truth for engineers is: these matter as much as implementation).
- …
Don’t start without a defined sponsor that is aware of being so
And before building anything, make sure the project has a real sponsor. A great data product without clear sponsorship is often just well-executed waste. If the sponsor is real, ask who the actual stakeholders and users will be.
One useful question at that stage is: What action would you take with this report? What would you do if this number went up or down? If the answer is vague, delayed, or theoretical, the issue may not be training. The artifact may still be too far from the decision it is supposed to support.
Then ask a few simple questions early:
- Who will actually use this?
The sponsor’s answer may differ from the end user’s. That difference matters. - What decision should this help them make?
Be specific. What problem are they solving? How often does that decision happen? What would they do differently with a better answer? - How do they want the answer delivered?
Format, tool, level of detail, timing, and readability all affect whether the artifact gets used.
Side notes on delivery, tooling, and readability
- Tool choice matters more than data teams sometimes admit. If your team loves Superset but your stakeholders live in Looker, use Looker. Teaching people a new tool adds friction. Asking them to use one they already dislike adds even more.
- Readability matters too. A dashboard can be correct and still be hard to scan, interpret, or trust. AI tools can help here: you can give an agent a rubric or checklist and ask it to review a dashboard or report for clarity before sharing it.
- Before delivery, show stakeholders what you plan to ship and invite review. Be ready for pushback. In many cases, a request for changes really means: “I’ll use this if you make it closer to what I need.”
Morale
It is tempting to measure success by views, opens, or shares. Those are useful signals, but they are not the outcome. A dashboard can be popular and still irrelevant.
The impact begins when the insight reaches the right person, in the right format, at the right time, and changes a prioritization, a behavior, a workflow, or a decision.


Leave a Reply