Most dashboards are built backwards. Someone asks what data is available, pulls it into a tool, arranges it into something that looks coherent, and calls it a management dashboard. The result is a report dressed up as insight: seventeen metrics, three RAG statuses, and a chart nobody quite understands but nobody has asked to remove. Leaders look at it once a month, note that sales are down and costs are up, and go back to making decisions the way they always did.
The problem is not the dashboard. The problem is the question it was built to answer.
What is the difference between a reporting dashboard and a decision dashboard?
A reporting dashboard describes what happened. A decision dashboard helps you decide what to do next.
Both have their uses, but they are not interchangeable, and most organisations build the first while convincing themselves they have the second. A reporting dashboard tells you that customer satisfaction scores fell in August, that revenue came in 8% below forecast, and that three of your five product lines are underperforming. Useful information. What it does not tell you is why any of those things happened, which of them deserves your attention first, or what you should actually do differently next week.
A decision dashboard is built around a question. What do I need to know to run this business well? Where are the three or four places where my attention will create the most value? Which numbers, if they moved, would change what I do? Those questions force a fundamentally different design. Instead of pulling in everything available, you start by asking what decisions need to be made regularly, then work backwards to identify only the metrics that would change those decisions. Everything else is noise.
The distinction sounds obvious. Almost nobody applies it.
How many KPIs is the right number?
Fewer than you think.
There is no universal number, but the practical test is this: if you cannot recall all of your key performance indicators without checking the dashboard, you have too many. A metric you have to look up is not shaping your thinking. It is just occupying screen real estate.
For a leadership team, somewhere between five and ten metrics covering the full business tends to be workable. For an operational team, the number might be similar but focused much more narrowly on the things that team can actually influence. Finance should not be monitoring customer satisfaction scores in the same way that the customer operations team does. The metrics that matter for strategic decisions and the metrics that matter for day-to-day delivery are different in kind, not just in detail.
The right number of KPIs is the number you genuinely use. If a metric sits on the dashboard and nobody references it in a meeting, in a decision, or in a conversation about performance, it should not be there. That sounds obvious too. Most dashboards are full of orphaned metrics that survived because removing them felt like it might upset someone.
How do you know whether a metric is actually influencing behaviour?
Ask one question: has anything changed because of it?
Not whether people look at it, not whether it gets reported upward, but whether it has ever caused someone to make a different decision, alter a process, reallocate a resource, or change a conversation. If the answer is no, that metric is being monitored, not used. There is a meaningful difference.
A metric that influences behaviour tends to have three characteristics. It is visible to the people who can act on it. It is understood clearly enough that people know what a bad trend looks like before it becomes a crisis. And it is connected, at least informally, to something the organisation cares about enough to do something about.
A metric that sits in a monthly pack, gets acknowledged, and is then set aside is usually a symptom of one of two problems. Either the metric is real but nobody has been given responsibility for improving it, in which case you have a governance problem. Or the metric is tracking something that the organisation does not actually care about enough to change, in which case you have a measurement problem. Both are worth knowing. Neither gets solved by adding another chart.
What should be on a leadership dashboard versus an operational dashboard?
Different things, designed around different questions.
A leadership or executive dashboard should answer questions about the health and direction of the whole organisation. Is growth on track? Are margins sustainable? Are we retaining customers at the rate we planned? Is the pipeline strong enough to support next quarter's targets? What are the early warning signs that something structural is going wrong? These are strategic questions. The metrics supporting them tend to be lagging indicators, things that reflect what has already happened, combined with a small number of leading indicators that give you early signal about where things are heading.
An operational dashboard works at a different altitude. It answers questions about whether the work is being done well, right now. Are we hitting daily or weekly targets? Where are the bottlenecks? What is the first-time resolution rate on customer queries? How is capacity tracking against demand this week? These metrics need to be timely, often updated daily or more frequently, and they need to be specific enough that a team can act on them without waiting for a senior decision.
The failure mode is conflating the two. Leadership teams that spend their meetings reviewing operational metrics are not doing strategy. Operational teams given high-level financial metrics but nothing specific to their own work quickly disengage from performance data altogether. Both situations are common. Neither is the dashboard's fault, exactly, but a well-designed set of dashboards would make the confusion harder to sustain. And, for what it is worth, getting this structure right is one of those things that sounds straightforward in a conversation and turns out to involve a surprising amount of organisational negotiation once you actually try to do it.
When is a dashboard a symptom of a data problem rather than a solution to one?
Almost always, if it was built quickly on top of messy underlying data.
A dashboard visualises what is in the data. If the data is incomplete, inconsistently recorded, spread across systems that do not talk to each other, or dependent on manual processes that introduce error, the dashboard will visualise all of that too. It will just do so in a way that looks authoritative and clean, which is arguably worse than having no dashboard at all.
The credibility of a dashboard depends entirely on the quality of the data behind it. This is the unglamorous part of the conversation that tends to get skipped over in favour of talking about which tool to use or how to design the layout. But a beautifully presented number that is wrong, or inconsistently defined across departments, or six weeks out of date because someone has to export it manually from a legacy system, is not management information. It is a confident-looking guess.
The practical test is to ask: where does each metric on the dashboard actually come from, how often is it updated, who is responsible for its accuracy, and what happens when two people look at the same metric and get different numbers? If those questions provoke uncertainty, the data layer needs attention before the dashboard gets more sophisticated. Adding a predictive model or an AI analytics layer on top of poor data does not improve the quality of the insight. It just makes the errors harder to trace.
This is also where many organisations discover that their dashboard project is actually a data strategy project in a thinner disguise.
What does a genuinely useful dashboard actually look like?
It starts with a short list of decisions.
Not a list of data points, not a list of things the organisation measures already, but a list of the decisions that the people using the dashboard need to make regularly. What are the three or four strategic calls that the leadership team makes on a quarterly or monthly basis? What does an operations director need to know each week to keep delivery on track? What does a founder need to see each morning to know whether the business is moving in the right direction?
From that list of decisions, you work backwards to identify the minimum set of metrics that would give the decision-maker enough information to act with confidence. Not all available information. Not every metric that someone has ever suggested might be interesting. The minimum set that would change a decision if it moved.
The dashboard that comes out of that process is almost always simpler than the one the organisation currently has. It has fewer metrics, clearer ownership, and a direct connection to the things the business actually cares about. It is also more likely to be used, because the people who use it recognise themselves in it.
That is the only real test of a dashboard. Not how it looks, not how many charts it contains, not what tool built it. Whether the people who rely on it make better decisions because of it.
If the answer to that question is not clearly yes, the problem is worth going back to the beginning on.
