Business & Revenue OpsFree
Dashboard Requirements Spec With a Cut List
Every requested metric tested against a named viewer, a cadence and an action, and everything that fails ships as a cut list.
Every dashboard requirements template on page one tells you to start with the question rather than the chart, and then hands you a section headed Key Metrics. One widely copied prompt template spells out the instruction inside it: list 8 to 12 key metrics. That is a quota, and a quota is filled. Nothing in any of those templates removes anything, which is why the requirements process that everybody agrees with produces the fourteen-tile dashboard nobody opens.
Google publishes the rule that fixes it, in the monitoring chapter of its own SRE book: signals collected but not exposed in a dashboard and not used by an alert are candidates for removal. Point that at a business dashboard and the test becomes a sentence. A named person looks at this on a stated cadence and does a specific thing when it crosses a stated number. A metric that cannot finish that sentence has no reader.
So the cut list is a section of the spec rather than a thing that happens quietly. Fourteen requested tiles come back as five, with the other nine listed, each with the reason and the person who asked for it. Every survivor carries the source field it reads from, because a spec that defers the data question is a spec the build discovers is impossible. Definitions come from the same place a metric register holds them, so the tile and the monthly pack cannot drift apart.
What a fourteen-tile dashboard costs
Grafana's own dashboard maturity model describes the default state a team lands in without a strategy, and two of its symptoms are one-off dashboards that hang around forever and people browsing to find the right one. That is written about infrastructure monitoring and it describes a revenue operations team exactly. The cost is not the build. It is that a leader who has to hunt for the view stops opening any of them.
Metrics fail the sentence test in four recognisable ways, and the reason belongs on the cut line because it decides what happens next. The number is already read somewhere else, so the tile is a duplicate surface and the fix is a link. Nobody can name an action, so it is context and belongs in a footer. The data refreshes quarterly while the dashboard is weekly, so the tile shows one value for thirteen weeks. Or the source field does not exist yet.
That last one is the most valuable thing the exercise produces. A metric everybody wants, with a named owner and a real threshold, that no system currently records, is not a tile. It is an instrumentation project with a business case already attached, and it comes out of the spec as its own recommendation rather than being quietly dropped or faked with a proxy. Freight claims tracked in an inbox is the classic version, and it gets funded once somebody writes it down.
How it works
Send the ask
Whatever the requester said they wanted, in whatever form they said it, plus who asked.
List the fields
What data actually exists, which systems hold it, and how often each one refreshes.
Run the test
Every metric has to name a viewer, a cadence, a threshold and an action.
Cut and specify
Survivors get a full spec entry. Everything else lands on the cut list with a reason.
What you get
- The spec, written from the decision each viewer makes rather than a metric list
- A cut list naming every metric removed, the reason, and who asked for it
- Each surviving tile with its viewer, cadence, threshold and the action at that threshold
- The source field behind every metric, so the build never discovers the data is missing
- Metrics whose refresh is slower than the dashboard, which would show one value for months
- Anything worth measuring that nothing records yet, written up as an instrumentation project
Common questions
The requester will not like being told no. How does this land?
It lands better than the alternative, because nothing is refused, it is relocated. Each cut names where the number already lives, or what would have to change for it to earn a tile. A requester who sees nine reasons and a link to each existing view is being answered rather than overruled, and the five that survive get built.
What if the requester genuinely wants a metric with no action attached?
Then it is context, and context has a place. Put it in a footer strip or a monthly summary rather than a tile with equal visual weight to the number somebody acts on. The spec says which, and the distinction is what stops a dashboard reading as fourteen equally urgent things when two of them are.
Do I need to know the source fields before I start?
No, and sending what you do know is enough. Anything unmapped comes back as unmapped, with the question that would resolve it. That is useful on its own, because a metric nobody can source is either an instrumentation project or a request to drop. A field-level dictionary is where the sourcing answers get recorded.
We already have twenty dashboards. Can this work backwards?
Yes, and running it on what exists usually matters more than running it on a request. Feed in the current tiles and the same test applies, which is where the report retirement audit picks up. Anything nobody can attach an action to has been costing review time since it shipped. A weekly and a monthly view of the same business need proof of which numbers may appear in both.
What if two tiles show the same metric computed differently?
That is the finding that outranks the spec, because a dashboard cannot resolve a definition dispute and will just publish both. The spec names the conflict and stops. Settling it is a separate job, and working out which of two numbers is right is where it gets done before anything gets built.
Which BI tool does the spec target?
None of them, deliberately. The spec is what you hand to whoever builds it, in Looker, Power BI, a spreadsheet or a weekly email, and the decisions it records survive a tool migration. Chart types and layout come after the metric list is settled, and specifying them first is how a fourteen-tile grid gets locked in.
Dashboard Requirements Spec With a Cut List
Fill in the form and your workspace opens with the work already underway.