Before you build a dashboard, decide what it's supposed to change

Almost every reporting project starts the same way: someone is tired of pulling numbers by hand, so they ask for a dashboard. That's a reasonable instinct, but it skips a step. A dashboard that just displays numbers faster than a spreadsheet did is a small win. A dashboard that changes what someone does on a Tuesday morning is a different thing entirely, and most of the value lives in that second kind.

Ask what decision the number is supposed to feed

Before building anything, we ask a plain question for every metric on the list: if this number moved sharply this week, what would you actually do differently? Sometimes the honest answer is "nothing, I'd just note it" — that's a fine metric to keep around, but it belongs in a monthly review, not a live dashboard someone checks daily. The numbers worth building first are the ones tied to an action someone is already prepared to take, just doesn't have visibility to trigger.

Don't let "nice to know" crowd out "we act on this"

Every dashboard request we've scoped has grown a few extra charts nobody asked for — a vanity metric, a breakdown that looked good in a meeting once. Each one adds maintenance and makes the two or three numbers that actually drive decisions harder to find at a glance. We'd rather ship five numbers someone checks every day than twenty that get glanced at once a quarter. Cutting scope here isn't a cost-saving move, it's what makes the thing get used.

Give it one owner who's expected to act

A dashboard with no named owner becomes background noise within a month — everyone assumes someone else is watching it, so nobody actually is. The ones that stay alive have one person whose job includes checking it on a set cadence and doing something when a number crosses a line, even if that something is as small as a Slack message. Build the dashboard around that person's actual rhythm, not an idealized one.

Review it like a tool, not a one-time project

A dashboard built around last year's priorities quietly becomes wrong the moment the business changes — a metric that mattered stops mattering, and nobody removes it. We treat reporting the same way we treat any automation: it gets revisited periodically, and anything nobody's acted on in a few months gets questioned, not left running because it's already built.

The honest test for any dashboard isn't whether it looks good — it's whether removing it tomorrow would change what anyone does today. If the answer is no, that's not a dashboard problem to fix with better charts. It's a sign the wrong number got automated.