Your CEO Can Build the Dashboard Now

Your CEO can build a dashboard faster than your team can schedule a requirements meeting. We have promised self-service for years. I am not sure we are ready for what it means.

For years, a new dashboard was something to unveil. An executive could put it on a screen and say, "Look what we've got." The charts made the company's investment in data visible. They looked modern. They gave the data team a finished product everyone could recognize.

Behind that five-minute demo were often months of work. Someone wrote requirements. Someone chased down the right source. Report builders made a first version, gathered feedback, changed the filters, and did it again. Consultants and contractors came in when the queue got too long. Companies built teams around producing these things. Entire careers grew around it.

This week, Anthropic launched Claude Dashboards in beta. Connect a warehouse or business app, describe what you want, and Claude writes the queries and creates the charts inside the conversation. You can inspect the SQL and refresh time behind each chart.

Claude did not start this. Databricks Genie Code builds and refines dashboards from natural-language prompts. OpenAI's Data agent in ChatGPT Work creates shareable interactive dashboards. Gemini in Looker returns charts from conversational questions and supports data agents grounded in governed Looker data. The offerings differ, but the bottleneck they attack is the same.

Claude's entry puts dashboard creation in another app people already use for everyday work. Its beta is aimed at exploration, and complex reporting still needs more. The direction is hard to miss: dashboard assembly is becoming a commodity. Your CEO can make one without filing a ticket.

Agents have already put similar pressure on code. For data teams, this shift is uncomfortable because dashboards have been visible proof of our value. A chart now takes minutes; bringing data together, agreeing on definitions, and governing access take far longer. Companies that deferred that work are about to feel the gap.

So where should the team spend its time when anyone can make the thing we used to deliver?

The old process forced useful questions

I do not miss the dashboard backlog. It was slow, frustrating, and full of requests that probably should never have become reports. But the human process contained a useful pause.

Ask a report builder for revenue by market and they might ask which revenue. Booked or recognized? Which market? Where the customer lives, where the sales team sits, or where the transaction happened? They might know that a refund arrives a month late or that an obvious join counts the same order twice. They might ask who will see the result and whether the customer detail in it should leave the finance team.

Those questions rarely made it into the demo. They lived in meetings, calculated fields, SQL, and the heads of the people who had been burned before. The dashboard looked like the product. Much of the value was in the decisions underneath it.

Now a dashboard that looks finished can arrive before anyone has that conversation. It has a title and a polished chart. The SQL runs. An executive shares it. A week later, somebody notices it disagrees with the board packet. By then, the unverified number is in the room and the data team has to prove why it is wrong.

Claude can write valid SQL against the tables it sees. The right answer still depends on business meaning and access rules that the tool may never have been given. A valid query can produce a very convincing wrong answer.

Permissions can prevent someone from seeing rows they should not see. They cannot decide whether "revenue" means booked or recognized. Access control can make a query authorized without making its answer correct.

That is when a dashboard becomes dangerous: when its polish gives it authority that its data has not earned.

The same problems, with the brake removed

None of this began with AI. We have had conflicting metrics, stale dashboards, abandoned reports, and catalog projects that nobody uses for years. The difference is volume. A dashboard is a claim about the business. When making one becomes trivial, making competing claims becomes trivial too.

When a dashboard took months to build, the backlog acted as an accidental brake. It kept some reports from ever being made. Now the cost of producing another one is heading toward a conversation. We are about to have more dashboards than we can review by hand, and more ways for a plausible answer to spread before anyone checks it. Without a different operating model, the business will create the dashboards and the data team will inherit the job of reconciling them. By the time a disputed number reaches the executive meeting, the team is already late.

I think data teams need to stop organizing around dashboard production and start organizing around the supply chain for an answer. Data has to come out of scattered operational systems, be brought together, modeled, defined in business terms, governed, and then made available to whatever interface a person chooses. The dashboard is the visible end of that chain. It is also the part that is getting easiest to generate.

Once anyone can generate an interface, the most valuable thing to own is what every interface consumes. That moves data engineering and the data platform to the center of this version of the data team. They bring data together from source systems and make it dependable enough that a dashboard created by the CEO and one created by finance start from the same governed foundation. The work has to happen upstream because no team can inspect every dashboard after it has been generated.

Business owners still have to decide what their metrics mean. The data team has to encode those decisions in a semantic layer that every legitimate tool can use. It should know which entities and relationships are approved, how each metric is calculated, when a number is incomplete, and which version of a concept belongs in which situation. It should carry quality checks and access controls with the data.

This matters especially when a company has put its metric definitions inside a BI tool while an AI tool connects directly to the warehouse. The warehouse may have clean tables and several plausible ways to calculate revenue. The AI tool will see the tables. It may never see the rule that makes one calculation the company-approved answer. Whatever form the semantic layer takes, a new interface needs to be able to reach it.

Some vendors already recognize this. OpenAI says its Data agent can use business terms, metric definitions, calculations, and relationships from semantic layers and other trusted sources. That strengthens the case for a governed foundation. Interfaces will change. The meaning underneath them has to be portable.

AI can accelerate the engineering work too. In an earlier post on data warehouse modeling, I described using a coding assistant to profile raw schemas, find logic scattered across SQL and BI assets, draft transformations, and generate validation queries. The modeler still decides the grain, relationships, and meaning. The assistant shortens the path from messy sources to a model people can trust. Data leaders should be using that speed to build the supply chain now, while they still have a chance to shape what the new dashboard tools consume.

The supply chain continues past the modeled data. Data teams also need a publishing framework. People should be free to explore their own data within their permissions. Sharing a dashboard as a team artifact is a different act. Publishing should require an owner, an audience, approved sources and metrics, an access check, and a review date. A chart used for executive decisions needs a stronger check before it becomes an official number. The guardrails begin when someone publishes. Exploration stays fast.

The status should travel with the dashboard. A personal exploration should look like one. A shared operating view should name its owner. An official dashboard should make its definitions and review status easy to inspect. When a dashboard is replaced or stops being used, it needs to be archived. Otherwise the old version keeps circulating because someone saved a link.

And make the whole estate findable. If creating a new dashboard is easier than finding the existing one, the company will keep making duplicates. A useful catalog should index dashboards by the business questions they answer, the metrics and data products they use, their owners, audience, status, and last review. Publishing should register that information automatically. A search for "revenue by market" should tell someone which metric is approved and whether there is already a dashboard worth using.

These are familiar responsibilities. AI changes how much of the work must happen through reusable systems rather than one report builder noticing a problem and fixing it by hand.

What happens to the people who built the dashboards?

I have a hard time seeing a long future for roles that are only about assembling reports. Choosing charts, placing filters, and iterating on a layout are becoming things the person asking the question can do. The CEO will not need to file a ticket to see a chart.

Experienced report builders know where the definitions are disputed, which source breaks at quarter-end, and why two dashboards that look identical disagree. I would want them helping build the semantic layer, define the publishing rules, and decide what belongs in the catalog. Their expertise becomes more useful when it is available to every dashboard rather than trapped inside one.

I would run a rehearsal before these tools spread much further. Give a business user a question your executives ask often and let them build the dashboard with the access they would actually have. Did they find an existing approved answer first? Did the chart pull from integrated, modeled data, use the right definition, and respect access rules? Could they publish it with a clear owner and status? Will someone be able to find it, review it, or retire it six months from now?

Every "no" is work for the data team. The goal is to make the next hundred dashboards safer without requiring the team to draw or inspect each one.

For a long time, showing off a dashboard was evidence that a company had invested in data. Soon it will only prove that someone asked a question. The data team may not see the next dashboard before the CEO does. Its chance to make that dashboard trustworthy is to own the supply chain before anyone asks for it.