Stop Building Dashboards. Start Building Decisions.

There is no shortage of dashboards at most companies.

There's a marketing dashboard. A sales dashboard. A pipeline dashboard someone built in HubSpot. A revenue dashboard in a spreadsheet that one person on the finance team updates manually every Monday. A Looker report that took three weeks to build and gets opened twice a month.

And somehow, despite all of that, the answer to "how are we doing?" still requires a meeting.

The problem isn't the data. It's what the data is being built for.

The Dashboard Trap

Dashboards feel like progress. They look sophisticated. They signal that you're a data-driven organization. Building one creates a sense of visibility even before anyone has looked at it.

So companies keep building them — and the people who need to make decisions keep not making them any faster.

Here's what I've observed across dozens of revenue systems: the organizations with the most dashboards are rarely the ones with the clearest visibility. They're the ones with the most data debt. Every dashboard represents a question someone once had that never got fully answered, so they built a new view instead of fixing the underlying problem.

A dashboard that doesn't change a decision is decoration. It might be accurate. It might be beautifully designed. It is not doing the job it was built to do.

What Decisions Actually Need

Before you build any report, there's one question worth asking first: what decision does this exist to support?

Not "what would be interesting to know." Not "what does the board ask about." What specific decision will someone make differently — and faster — because this report exists?

If you can't answer that question before you build the report, you will almost certainly build the wrong thing.

The founder who needs to decide whether to hire a second rep needs to see pipeline coverage relative to one rep's capacity — not a full funnel breakdown with twelve filters. The VP of Sales running a weekly forecast call needs to see what moved since last week and why — not a static snapshot that looks identical to last Tuesday's. The CEO trying to understand why Q2 missed needs to see where deals stalled — not overall win rate by quarter.

Same company. Same CRM. Completely different reports — because they're supporting completely different decisions.

When you build for the decision instead of the data, the report gets smaller. Simpler. Faster to read. And actually used.

The Reports That Get Ignored

You can tell a report isn't working by watching what happens when someone opens it.

They spend the first two minutes figuring out what they're looking at. Then they apply filters to find the thing they actually care about. Then they export it to a spreadsheet to do the analysis themselves. Then they share a screenshot in Slack with a caption that explains what the report is supposedly showing.

That is a report that was built to capture data, not to support a decision.

The most ignored reports in any company share a few traits: they show everything instead of something, they're organized around what the tool can display rather than what the reader needs to know, and they require interpretation before they're useful.

A report that requires a paragraph of explanation every time it gets shared hasn't been built for the reader. It's been built for the builder.

What Decision-First Reporting Looks Like

Decision-first reporting starts with a conversation, not a dashboard.

Who is this for? What are they responsible for? What do they need to know to do that job well — and how often do they need to know it? What would cause them to act differently if the number moved?

Those answers determine the report. Not the other way around.

In practice, this means most companies need far fewer reports than they have — and the ones they need are considerably simpler. A weekly pipeline review report shouldn't have more than five columns. A monthly revenue summary shouldn't require scrolling. A forecast report should show the number, the change from last week, and the deals driving the variance. That's it.

The goal is a report that someone can read in two minutes and walk away knowing exactly what to do next. If it takes longer than that, or if the "what to do next" isn't obvious, the report needs a redesign — not more data.

The Metric Worth Tracking

Here's the one I use when I'm auditing a reporting setup: what percentage of the reports in this system have been used to make a documented decision in the last 90 days?

At most companies, it's lower than anyone expects.

That's not an indictment of the team that built them. It's a structural problem — reports got built to answer questions in the moment, and nobody ever asked whether those questions were still worth asking.

A reporting system should be treated like a product. It has users. It has a job to do. If nobody is using it, something is wrong — with the report, not the user.

Audit your dashboard count. For each one, ask: what decision does this exist to support? Who made that decision last, and when? If you can't answer either question, that dashboard probably shouldn't exist.

Delete it before you build the next one.

Photo by Jakub Żerdzicki on Unsplash