Why the second-best dashboard always wins
After enough years working in or around enterprise data teams, you develop a kind of involuntary tic. You walk into a meeting room, see a Power BI dashboard on the screen, and you can tell within about five seconds whether the dashboard is loved or merely tolerated. The loved ones have fingerprints on the corner of the laptop where someone keeps the screen tilted slightly toward themselves. The tolerated ones have the slightly too-perfect look of something that was built for a launch event and has been opened seven times since.
Most enterprise dashboards are tolerated. This is the quiet scandal of the analytics industry, and it has very little to do with the technology.
By 2026, the technical bit of business intelligence is essentially solved. Microsoft Fabric is a genuinely competent unified analytics platform. Power BI does what Power BI is supposed to do. The connectors work. The semantic model works. You can stand up a beautifully governed lakehouse in a couple of weeks if you have someone who knows what they’re doing, and a competent dashboard on top of it in a couple more. Almost any reasonably-skilled team can produce something that, on the day it ships, looks impressive to the executive who commissioned it.
The problem comes later. The problem is that being impressive on day one is the wrong success metric, and the analytics industry has spent most of the last decade optimising for it anyway.
Here is what actually happens with most enterprise dashboards. They get built to address a question the executive asked. They demo well. They go live. For about three weeks, people open them with genuine interest. Then a senior person notices something the dashboard doesn’t quite capture, asks the data team to add it, and waits two weeks for a change. By the end of the second month, the executive has gone back to asking their analyst for an ad-hoc Excel export. By the end of the third month, the dashboard is something nobody opens unless they’re showing it to a visitor.
Meanwhile, two floors down, the head of operations has a Power BI report he built himself in an afternoon. It has three tiles. The colours are wrong. The data model is held together with chewing gum. But he opens it every Monday morning at 8.15 and uses it to run his Monday standup. The data team know it exists and quietly disapprove. They’re missing the point. The ugly little dashboard is doing more work for the business than the beautiful corporate one ever did.
The data consultancy practices in the Microsoft ecosystem that consistently deliver value have, in my experience, internalised a fairly unfashionable principle. They optimise for being used, not for being right. They will deliberately ship the second-best dashboard if it’s the one a real human will open every day. They will absorb the slight indignity of producing something less technically elegant than they could have, because the elegant version, they know, will be a museum piece by Christmas.
This sounds like a counsel of despair. It isn’t. The point isn’t that you should aim low; the point is that the unit of value in business intelligence is not the dashboard, it’s the decision the dashboard supports. A dashboard that supports a real decision once a week beats a dashboard that supports a hypothetical decision never. The data engineers I admire most are the ones who can sit in a meeting with a head of operations, work out what they’re actually trying to decide, and build something deliberately crude that answers that one question well, before they go anywhere near the modelling tools.
See also: From Bell Curves to Syllogisms: How Quantitative Logic Shapes Academic Arguments
There’s a second-order effect worth naming. Organisations that have a handful of well-used, slightly ugly dashboards tend to develop a data culture. Organisations that have one perfect dashboard nobody opens tend to develop a data project, which is a different thing. The first becomes self-reinforcing — people get used to making decisions from data, ask for more, become more sophisticated consumers of it. The second becomes a procurement exercise that has to be re-justified every renewal cycle.
This is one of those observations that sounds banal until you start counting. Once you do, the ratio of expensively-built-and-rarely-opened to cheaply-built-and-heavily-used in most enterprise data estates is somewhere between two-to-one and ten-to-one. The ratio is the actual measure of how well a data team is doing its job. Not the number of reports. Not the sophistication of the models. The ratio.
It also happens to be the metric almost nobody on the data team is asked about, and the metric the head of operations on the third floor has been quietly tracking, in his head, since the project started.
