Dashboards Are Not Dead: Why AI Makes the Work Before the Build Matter More

For years now, I've watched the same headlines do the rounds. Dashboards are dead. The death of Power BI. The end of the BI developer. BI analysts, no more. LinkedIn, X, Reddit… pick your platform. The pitch behind most of it was similar, why bother building dashboards when people can just chat to their data and get the insight straight away?

Then Anthropic launched Claude Dashboards. You connect it to your data platform, ask a question in plain English, and Claude builds you… a dashboard. One that stays current as the data changes, no less.

I'll be honest, I had a little smile when I saw it.

To be fair to Anthropic, they never said dashboards were dead (or at least, I haven't seen it posted by them). Plenty of others have though, BI vendors and analysts among them, some with blogs titled exactly that. Anthropic actually positions Claude Dashboards as working alongside your existing BI tools. But that's kind of my point. The chat-to-your-data era was supposed to replace the dashboard, and one of the biggest AI labs has just answered "ask a question of your data" with a faster way to build one. Clearly, dashboards are not dead.

I've been pushing back on this narrative for years, in fact! In one of my earlier blogs on building reports that actually deliver results, I wrote that dashboards are not dead, irrelevant information and clutter are what kill them. I said it again in Pretty Reports Need Strong KPIs, dashboards are not failing by nature, the failure lies in the questions asked at the start. Long before I wrote either of those, I was saying the same thing in workshops and to clients.

So yes, I'll allow myself a small "told you so". Just a small one. The more important part is why dashboards got their bad name in the first place. Many were built without the thinking that should come before any build, and AI on its own doesn't fix that. If anything, it makes it easier to skip.

Are dashboards dead? The short answer

No. Business intelligence was never about building dashboards, it is about improving the decision making process, and many dashboards were binned because they were built on the back of what I like to call the "what do you want" approach. The thinking before the build (who it is for, what decision it improves, what action follows) has always been what separates a dashboard people use from one nobody opens. AI can now take anyone from idea to dashboard in minutes, but it doesn't do that thinking for you, it just makes it easier to skip.

Key points

• Dashboards did not fail as a format. Many were built without a clear purpose, then quietly stopped being opened.
• The tools once pitched as the replacement for dashboards are now giving us faster ways to build them.
• Business intelligence is about improving the decision making process. A dashboard is one way of delivering the insight that work produces.
• AI multiplies speed. Where the thinking is missing, it multiplies the number of reports nobody uses.
• The work before the build is what our clients tell us they value most, and it applies whatever tool you use.
• A methodology that guides you before you touch any tool, Power BI, Claude Dashboards or anything else, is what gives a quick build a real chance of being used.

‍

‍

How dashboards got their bad name

Here's the thing. Dashboards were never the issue… it was us, the data and BI people developing them.

The process I've seen play out more times than I can count goes something like this. Someone in the business asks for a report. The BI team asks "what do you want?", then "where's the data?", then a few weeks later, "here's your report." There is a launch, a bit of buzz, and then usage drops week after week. Nobody formally declares it useless. Eventually someone asks whether anyone is still using it, and it gets binned.

Repeat that across an organisation a few hundred times and you can see how people reached the conclusion that dashboards don't work. Wrong conclusion. Think about it, if you built a product without speaking to anyone who would use it, and nobody bought it, you wouldn't blame the idea of products.

We made it worse ourselves in two ways. Either we jumped straight into the tech, or we waited for the business to come to us with ready-made requirements. The second one gets defended a lot ("end users don't know what they want"), and I've always half agreed. End users may not know what a reporting solution should look like, but that's not their job, it is ours. I covered this in more depth in report requirements when end users don't know what they want.

Over time, people outside the BI space started to associate BI with one thing, dashboard development. Honestly, a lot of us in the space fell into the same trap.

I made this mistake myself early in my career, and it shaped the way I have worked ever since. I've told the story before in my blog on why report developers need more than technical training, so the short version. A technically strong solution, a solid platform and model, polished reports the users liked, and then a demo to a very senior person. Their reply was two words… "So what?" That one still stings a bit. The solution was built well, it just didn't answer the questions that mattered to where the business was trying to go.

What business intelligence actually is

I say the same thing to every client and in every workshop I run.

BI was always about improving the decision making process.

Whether that is increasing revenue, reducing costs, mitigating risk, staying compliant or working more efficiently, the point is to help people make better decisions. Semantic models, pipelines, DAX and, yes, dashboards are how we get there. They are the enablers. Automating a manual report is great, but on its own it is a technical win. The real question is what impact it has on the business. I wrote about this in why business intelligence is about business and tech together, people, process and technology all coming together.

So what does that look like in practice? The dashboards that got binned usually skipped a whole set of activities and went straight to the build. In our experience, these are the activities that make the difference.

• Listening: understanding where the business is trying to go, what is getting in the way, and how they know whether they are on track.
• Challenging: asking why, and pushing back professionally. The classic examples I always use are 26 KPIs requested when 10 actually affect the goal, or five years of history requested for what turns out to be a This Year vs Last Year question, with no trend analysis needed at all.
• Navigating: guiding the room, running separate sessions for audiences with different purposes, and steering the conversation back to the business when it drifts to chart types and colour palettes.
• Promoting: building excitement at go-live, training people properly, and giving ongoing guidance so they use what was built rather than leaving them to figure it out between their day jobs.
• Keeping the business accountable: getting sign-off on the purpose, KPIs and actions before anything is built, then going back after go-live to ask what actions were taken, and if none, why not.

That's BI. Interacting with the business to improve the decision making process. An insight that changes nothing is just a number on a screen. A dashboard is what that work produces, when one is needed at all. Sometimes the right answer is that the report isn't needed, and as I've said before, no report is better than a pointless one.

What AI changes, and what it doesn't

Now we can go from idea to dashboard in minutes. Claude Dashboards builds them from data platforms like BigQuery, Databricks or Snowflake, and lets you click into any chart to see the query behind it. Copilot in Power BI can create report pages on top of your semantic models. In MS Fabric, Fabric Apps (still in preview) lets developers build full data apps connected to lakehouses, warehouses and semantic models. The build has never been quicker or cheaper.

Hold on though. Look at what actually happens when someone types a request into a chat interface and gets a dashboard back. It is the "what do you want" approach in its purest form. The analyst who used to ask "what do you want?" and go off to build has been replaced by a prompt that does the same thing in seconds. Nobody asks who it is for, what decision it improves, or what happens when a number goes red. Nobody sits with the actual audience, the people who will use it, and prompts them to share its purpose. Nobody helps derive the KPIs and agree the definitions, or works out which actions it should drive, which business objective it helps achieve or which challenge it helps overcome. That is the real work, and a prompt skips all of it.

In my blog on useful Power BI reports, I described design as a multiplier. Multiply 10 by 10 and you get 100. Multiply 0 by 10 and you still get 0. Speed works exactly the same way.

Speed multiplies whatever you feed it, including a pointless report.

We will jump into the tools even quicker, produce far more, and skip the thinking even more than before. The result is more solutions that nobody opens, just delivered faster. The dashboard graveyard is about to get a lot busier.

There is a second problem that gets bigger with AI, and that's definitions. I've sat in rooms where five stakeholders had three definitions of revenue, and that was for one report. Now picture each of them generating their own dashboard, each interpreting revenue in their own way. Same question, different numbers, and three dashboards that look equally convincing. AI does not fix a vague definition, it amplifies the consequences of one. This is a big part of why we push so hard on governed definitions in the semantic model, and why our Copilot-ready data model work starts with agreeing what the business actually means before any AI gets near it.

Let me be clear, I am not against quick dashboards. Anthropic positions Claude Dashboards for quick, exploratory questions, and that is a sensible use. I've always said exploration and ad-hoc analysis play by different rules. The trouble starts when a quick answer quietly becomes the operational report a team is meant to run part of the business on, without anyone asking the questions that should come before that.

‍

‍

‍

What our clients actually value

From my 10 plus years in BI, and since starting Metis BI, the feedback we get from clients almost always comes back to the same thing. It is rarely the development work. It is everything we do with them before we open Power BI or start building anything in the back end.

These are lines I've heard from clients and training participants over the years:

• "We have never had these conversations before."
• "These are conversations we should have had a long time ago."
• "It forces us to really think about what we are doing."

Don't get me wrong, the development matters. A slow report, a wrong number or poor data visualisation will get a dashboard binned just as quickly. We care a lot about getting that right. But the value clients describe, the ROI they talk about, comes from what happens upfront. A clear goal. KPIs everyone agreed to monitor, measured against a target, last year, budget or forecast. An action tied to every KPI, someone who owns it, and an alert when it crosses a threshold. That's what makes a dashboard actionable, and I've gone deeper on this in building actionable dashboards that drive better decisions. The right people in the room, including the people who will actually use the thing. One question I ask a lot is "what changes on a Monday morning because this exists?" If nobody can answer it, that tells us something before a single visual is built.

Also, just to add… sometimes the most valuable outcome is finding out a report isn't needed at all. It saves time and budget, and more often than not it resets the conversation about what is actually worth building.

Are BI roles changing?

Yes! I'm not closing my eyes to any of this, and I'm not saying our roles won't change. They are changing, and they will keep changing.

I use AI heavily to run Metis BI, it is part of our everyday workflow. We also use it with our clients for design work, developing models, running tests, building out reports and plenty more besides. But we do what is needed upfront first, all the thinking, working closer with the business.

I've said this many times over the years. If your role was to wait for requirements and spend time alone with a screen, dragging and dropping, then this shake-up is somewhat good, and it is time to pivot. The skills that hold their value are the ones no tool has a feature for. Facilitating a workshop, asking the uncomfortable question, reading the room, pushing back professionally, and translating a half-formed ask into something the business trusts. If you lead a BI team, this is where I would put your training budget next.

I've written about this in more depth from two different angles, and they sit together nicely with this blog. Back in early 2025, I asked will AI replace Power BI report developers? That one looks at the front end of the job. My view then (and it still stands) was that the "what do you want" reports are the most exposed to AI, and the developers who gather requirements properly, dig for the real business problem and tell a clear story with the data will stay valuable. More recently, in do you still need Power BI and SQL fundamentals now AI builds it?, I looked at the back end. AI can build a semantic model quickly, but a model that looks right and a model that is right can look identical on screen. Someone still needs the fundamentals to check it, so the value of an experienced developer is shifting from writing to reviewing. Put the two together and you get the same message as this blog. AI takes on more of the build, and the human value moves to either side of it, the thinking before and the checking after.

So, are our roles changing? Yes. Will they disappear? Only if you let them.

Before you open any tool

Whether it is Power BI, Fabric Apps, Claude Dashboards, Tableau or something that launches next month, the questions come first. In workshops I run, we would not touch a tool until we had answers to a core set of them, covering the audience, the goal, the KPIs and their definitions, and the actions and who owns them. If nobody can answer them, a faster tool won't help. It will just get you to the graveyard quicker.

I'm not going to list them all here, as they work best when they are tailored to the room. If you would like to know the questions we ask and how we use them, reach out, I'm always happy to talk this through.

Summary

Dashboards are not dead. The tools that were meant to replace them are now building them faster than ever, which says it all. What died, or should have, is the "what do you want" approach that filled the dashboard graveyard in the first place.

Business intelligence has always been about improving the decision making process. Listening, challenging, navigating, promoting and keeping the business accountable. That thinking before the build was always what made the difference. AI has made the build quicker and cheaper, but it hasn't done the thinking for you.

Ask first. Then build, with whatever tool you like.

If you are about to roll out Power BI, Fabric Apps or Claude Dashboards to the business, or you are tired of building reports nobody opens, talk to us before you open the tool. At Metis BI, we have a proven methodology for everything that comes before the build. Gathering requirements with the people who will actually use the solution, asking the right questions, the pushback, agreeing KPIs and definitions, building prototypes the business can react to before anything goes near production, and getting sign-off on all of it. It is tool-agnostic, and because stakeholders are involved from the start, it keeps everyone accountable. Nobody can say at the end that they don't know why a report isn't being used. It won't guarantee every report succeeds (nothing does), but it gives adoption and usage a far better chance. Book a call to hear how it works, or learn more about how we approach report development.