Field Notes · Commercial Operations

Start With the Decision, Not the Dashboard

Every few months, someone decides the organization needs better dashboards. The conversation starts with a real problem — forecast visibility is poor, the board keeps asking questions nobody can answer quickly — and ends with a project: build the dashboard.

Six months later, the dashboard exists. It's technically competent. It's largely ignored.

The reason is almost always the same: the team built the answer before they understood the question.

The question that matters isn't "what should we put on the dashboard?" It's "what specific decision does this need to support, and what would have to be visible for that decision to get better?"

Those are different questions. The first produces a list of metrics. The second produces a brief — who makes this decision, how often, what information is currently missing, what would change if they had it.

I've watched a company spend six months building a commercial performance dashboard with seventeen metrics, updated daily. It was never discussed in a leadership meeting after the first month. Nobody had agreed on what decision it was supposed to support. Everyone had added their preferred metric. The result was a comprehensive artifact that belonged to no one.

The most effective version I've seen started with a single question: can the VP of Sales tell, by day ten of any quarter, whether the team is on pace to hit pipeline coverage? That was the entire brief. The resulting dashboard had four metrics. It was reviewed every Monday. It changed how the team sourced pipeline in the first half of every quarter because it made the problem visible early enough to do something about it.

Before any dashboard project starts, the team should be able to answer three questions: What specific decision will this support? Who is responsible for acting on it? How will we know in six months whether it's working?

If those don't have clear answers, the dashboard isn't ready to be built. That's not a data problem. It's a requirements problem, and it deserves as much time as the technical work that follows.