When an organization asks for a dashboard, they are rarely asking for a dashboard. They are saying there is something about how the business runs that they cannot currently see, and they want to see it. The job is not to build charts. The job is to find the handful of numbers that actually change what someone decides, get the data that backs them, and present each one in the form that makes the answer obvious. Do that and a dashboard becomes the fastest decision-making tool in the building. Skip it and you have built a wall of pretty graphs nobody opens twice.

I treat business intelligence as a discovery problem first and a visualization problem second. Almost every failure I have seen came from building a beautiful chart on top of a metric nobody could explain or data nobody could source.

When to use this play#

Use it whenever a stakeholder wants visibility into how some part of the operation is performing and intends to make decisions off what they see. That includes the obvious "we need reporting" requests, but also the quieter ones: a leader who keeps asking the same question in every meeting, a team that exports the same spreadsheet by hand every week, an executive who says they are "flying blind" on something.

It is the wrong play when the real need is a one-off answer to a single question. If someone needs a number once, run the query and send it. Standing up dashboards, pipelines, and access controls is overhead you only want to pay for metrics people will return to repeatedly.

How to run it#

1. Surface what they actually want to see. Before talking about charts, ask the broad questions that get people thinking. Two I lean on: if you were stranded and could only check three numbers to know your business was healthy, what would they be? And where in the organization do you feel like you are operating blind? Ask every stakeholder separately, because their answers diverge in revealing ways, and those divergences are the real conversation.

2. Interrogate each metric before building it. For every metric someone requests, work through a short set of questions. What do we actually want to know? What decision or action will we take based on the answer? Who cares about this number, and who needs access to it? What thresholds matter — at what point does this go from fine to watch it to act now? And where does the underlying data live? Going through this often reveals that a requested metric drives no decision at all, which means it does not need to exist. That is a win, not a failure.

3. Find the data before you promise the visualization. Once a metric survives the questions, chase the data behind it. Do we already have it? If not, what would it take to start capturing it? Where is it stored, who owns it, how often does it update, and what has to happen to the raw data to make it usable? You cannot visualize data you do not have, so data sourcing and modeling come before any chart. This is where most of the real effort lives, and where timelines quietly blow up if you skip ahead.

4. Match the chart to the question. The right chart depends on what you are comparing and over what dimension. A few rules I hold to:

• Tracking how several variables move over time is a line chart.
• Showing how the parts of a whole change over time is a stacked area chart, and the percentage version of that is a 100% stacked area chart.
• Showing proportions of a whole at a single point in time is a pie or doughnut, the doughnut when you also want the total in the middle.
• Breaking a total into a hierarchy of categories and subcategories is a treemap.
• Bridging the gap between two periods or two figures, showing what drove the change, is a waterfall.
• Testing whether two numeric variables are related is a scatter plot.
• Showing how often values fall into ranges is a histogram.

Avoid the confusing ones. Plain overlapping area charts and stacked or 100% stacked line charts are almost always worse than the stacked-area equivalents, and a histogram with many columns per category should be split into multiple single-variable charts.

5. Add depth only where depth is wanted. Multi-level metrics let a viewer drill from a summary into detail. Time-based numbers drill cleanly: year to month to day. Organizational numbers drill by structure: whole to division to product. But not every metric should drill, and the levels that matter are the ones consumers tell you help them decide. Keep the top level a single number anyone can absorb in a glance.

6. Control access before you ship. Decide who sees which data and which views before the build, not after. Configuring and testing access takes longer than people expect. Use role-based access: define roles, add people to roles, and manage permissions at the role level so a single change propagates to everyone who holds it.

Common traps#

• Building visualizations before the data exists. The most common and most expensive mistake. Confirm the data is available and clean before promising a chart.
• Charting metrics that drive no action. If no decision changes based on the number, it is decoration. Cut it.
• Sprawl. Twenty metrics nobody trusts beat one. Start with the three someone would check on a stranded island and earn the right to add more.
• Pretty over legible. A clever chart that takes thirty seconds to interpret has already failed. The right form makes the answer instant.
• Treating access as an afterthought. Roles and permissions are real work and real testing. Scope them in from the start.

Signals it's working#

People stop asking the question the dashboard answers, because they just look. The weekly hand-built spreadsheet disappears. Stakeholders point at a number in a meeting and a decision follows in the same breath. New metric requests start arriving pre-framed — "here is what I want to know and what I would do about it" — because the organization has learned to think in those terms. And occasionally someone asks for a metric, you walk the questions, and they conclude they did not need it after all. That conversation, more than any chart, is the play paying off.