Your dashboard is not the problem. Your question is.

Every company I have worked at has a graveyard of dashboards. They were commissioned urgently, built carefully, opened enthusiastically for about three weeks, and then quietly abandoned. Nobody deletes them, because deleting them would mean admitting they failed.

The usual diagnosis is that the dashboard was badly designed, or that the tool was wrong, or that the team was not sufficiently data-literate. I think all three are wrong, and I think the real reason is duller and harder to fix.

A dashboard freezes a question

When you build a dashboard, you are making a bet about which question will matter. That bet is reasonable on the day you make it. The problem is that the business does not hold still.

Last quarter the urgent question was "why is churn up in the enterprise segment?" So someone built an enterprise churn dashboard. This quarter the urgent question is "which of our new pricing tiers is cannibalising the old ones?" That is a different question. It needs different dimensions, a different grain, and probably a different join.

A dashboard answers the question you had when you built it, for as long as that stays the question.

So the team files a ticket. The ticket joins a queue. Two weeks later the new dashboard arrives, by which point the decision has already been made on instinct — and now there are two dashboards nobody opens.

Why self-service BI did not fix it

The industry noticed this and built drag-and-drop query builders. The theory was that if business users could build their own charts, the queue would disappear.

It mostly did not work, for three reasons:

• The interface is a programming language in disguise. Joins, grain and aggregation do not become easier because you drag them.
• Nobody agrees what the fields mean. If "revenue" is a column and four teams interpret it differently, self-service produces four confidently wrong answers instead of one slow correct one.
• There is no way to check the work. A chart from a drag builder looks identical whether or not it is right.

The thing that actually helps

What changed for us was separating two things that BI tools usually merge: asking a question and defining a metric.

Defining a metric is a genuine modelling task. It should be done once, carefully, by someone who understands the data, and it should be versioned like code. net_revenue should mean exactly one thing across the whole company.

Asking a question, on the other hand, should be cheap and disposable. You should be able to ask forty of them in an afternoon, throw away thirty-nine, and keep the one that mattered.

What we do differently

Axiom lets people ask questions in plain language against metrics that someone has already defined properly. The answer arrives with the generated SQL attached, so the asker can check it and the analyst can correct it.

The result is not that dashboards disappear. It is that they stop being the primary interface. They become what they should always have been — a place to pin the handful of answers that turned out to be worth watching.

If your team is three tickets deep waiting on a number, the problem was never the chart. It was that asking cost too much.