Why your team has 47 dashboards and only checks four.

This essay uses an illustrative operating pattern we see often in data-heavy teams: dashboards accumulate faster than decisions get easier. The question is simple: how many dashboards does a team maintain, and how many do operators actually look at?

Forty-seven is not a benchmark claim. It is a deliberately memorable stand-in for the kind of dashboard sprawl Arcus is designed to reduce.

What follows is our product point of view on how that happens, who's hurt by it, and what a more answer-oriented workflow can look like. It's not a hit piece on dashboards. The dashboard was a useful invention. It is, today, often asked to do too much.

Section 01The shape of the data.

The model below is fictionalized. It borrows from common operating patterns across SaaS, e-commerce, marketplace, and fintech teams, but it is not a customer survey or public benchmark.

The headline number — 47 dashboards per business unit — is an editorial device. The exact count matters less than the shape: a handful of dashboards are truly operational, while many more exist as artifacts of old investigations.

The useful-dashboard count is usually much smaller than the maintained-dashboard count. Operators often return to the same few views: pacing, funnel, customer health, and growth mix.

The retirement problem is the one worth watching. Once a dashboard ships, it often stays around long after the decision it supported has passed.

Section 02How it happened.

This isn't anyone's fault. The shape of dashboard sprawl is the shape of a perfectly reasonable set of incentives, played out for ten years.

Picture the typical sequence. The CEO asks the CFO for a metric on Tuesday. The CFO asks the analyst. The analyst writes the SQL on Wednesday. By Thursday, the analyst thinks: I should make this a dashboard so I don't have to write it again. She publishes it. The CEO never asks for it again — he was preparing for a board meeting on a one-time question — but the dashboard now exists, in production, with no expiration date.

Repeat that pattern across weeks, analysts, and business units. You get a dashboard catalog that looks complete, but the analyst still has to answer the next executive question fresh because nobody trusts or remembers the old artifact.

The dashboard is, in this story, a coping mechanism for a system that doesn't remember. The team doesn't actually need a dashboard. They need their last answer to this question, refreshed.

Section 03The four-dashboard rule.

The four dashboards operators tend to return to have a clear shape. They are:

1. The pacing dashboard. Are we on track for the quarter? One number, refreshed daily, with a sparkline.
2. The funnel dashboard. What's converting and what isn't? Five rates, ordered top-to-bottom.
3. The customer health dashboard. Who is at risk? A list of accounts, sorted.
4. The growth-mix dashboard. Where are new customers coming from? A bar chart, possibly two.

That's the useful distinction: the operator dashboards deserve care, and the long tail is often really analyst tools — artifacts from investigations that should have been answers, not permanent surfaces.

This is the most useful framing we've found. Most companies do not have a dashboard problem. They have two problems, on top of each other:

• The four operator dashboards aren't getting the love they deserve. They're often slow, often stale, often built five years ago by someone who's left.
• The 43 analyst tools are masquerading as operator dashboards, and creating cognitive overhead for everyone who isn't the analyst who built them.

The first problem is solvable with attention. The second problem is solvable with a different category of tool entirely.

Section 04What teams are actually doing.

Teams that want to escape dashboard sprawl usually choose one of three patterns.

1. The dashboard purge.

Some teams just delete. They keep the core views, retire the long tail, and tell the business: if you need this again, ask and we'll re-derive it.

This is the cheapest, fastest, most controversial option. It works because the cost of a dashboard you can't find is, in practice, the same as the cost of a dashboard that doesn't exist. Most "we use this!" objections come from people who haven't opened the dashboard in nine months.

2. The semantic-layer migration.

Teams already invested in dbt or LookML often pull definitions into a semantic layer, then delete duplicate metrics. This is heavier work, but it moves attention from "build a dashboard" to "define the metric correctly."

The center of gravity changes. The team spends less time maintaining surfaces and more time making definitions dependable.

3. The conversational shift.

Some teams move ad-hoc questions out of the BI tool entirely, into conversational or agentic workflows. Arcus is built for this path: ask the question, show the work, preserve the answer.

The pattern at these teams: the four operator dashboards stayed. The 43 analyst tools were replaced by asking the question fresh, with the assumption that the system can answer it in seconds. Once asking is cheap, archiving the answer becomes optional.

Section 05What we'd do differently.

Here's a thing we say quietly to ourselves: product teams can make these mistakes too. It is easy to confuse a saved artifact with a maintained operating surface.

The honest order is to make the operating surfaces explicit, retire what no longer has an owner, and treat ad-hoc questions as threads that can be refreshed.

If we were starting a data org today — at any size — we'd do these things in this order, and we'd be unromantic about them:

1. Define the four dashboards before you build the first one. Write down what they are, what they show, who looks at them, when. Treat them like a contract. Resist building anything else for the first 90 days.
2. Build a semantic layer before a BI tool. Even a small one. The cost of doing this in dbt is hours; the cost of not doing it is a year of metric drift and re-derivation.
3. Treat ad-hoc questions as the default, dashboards as the exception. Most questions don't deserve a dashboard. They deserve an answer. The right tool for an answer is a thread, a memo, or a Slack message — not a permanent dashboard tile.
4. Set a retirement policy. Every dashboard expires after 90 days unless someone claims it. Renewing is one click. The "maintained dashboards" list shrinks naturally.

Section 06The real answer.

Here is what I think is true, that I would have argued against five years ago: the dashboard is not the right unit of analytical work for most teams. The right unit is the question. Questions are smaller, more disposable, more shareable, and easier to track over time than dashboards.

The dashboard era was a useful detour. It was the answer to a real problem — "I want to monitor this number without writing the SQL again every Friday." That problem is still real. But the answer is not necessarily a permanent tile in a permanent app.

The four operator dashboards your team checks every week? Keep them. Build them well. Defend them. They are doing real work.

The forty-three you don't check? They are not your fault. They are the residue of a decade of well-intentioned analysts trying to be helpful in a system that didn't remember. The kindest thing you can do for your team — and your future self — is delete them, and replace the underlying capability with something that lets you ask, and re-ask, and ask again.

We are biased about what that something should be. But you don't have to take our word for it. Look at your dashboard list. Count them. Notice how few you actually open. Sit with that, for a minute. The answer to what to do usually shows up shortly after.