The Decision Brief

Pull up one extra chair at every dashboard demo. Leave it empty on purpose.

That chair belongs to the person whose decision this work was supposed to change. If nobody in the room can name who sits there — or what cause they’re actually serving — you’re not demoing a data product. You’re celebrating an artifact.

I’ll plant a flag on this: that distinction matters more than almost anything else in how we design data work.

The brief that becomes the goal

Here is how most data briefs arrive: “We need a dashboard.” “Something like the old one, but updated.” “The CFO asked for it.” That’s a brief doing the absolute minimum — naming an artifact, not a purpose. The artifact becomes the deliverable, and the deliverable becomes the goal. Somewhere in that chain, the original question — who should actually be better off? — got cut.

This is not a new observation. Andrew McAfee and Erik Brynjolfsson made the same point in HBR in 2012: the organisations that create real value from data treat it as a management and decision discipline, not an infrastructure exercise. Shipped output isn’t the outcome. A sharper decision is.

Cassie Kozyrkov, Google’s former Chief Decision Scientist, gave the framing a name: decision intelligence. Data analysis exists as a service layer to a decision. Remove the decision, and the analysis has no value. The dashboard is the last step in a backward chain that begins with who needs to decide what.

Three questions, in order

If the empty-chair test exposes the problem, the decision brief is the fix. It is not a methodology — it is three questions, asked in the right order before anyone opens a tool:

1. Who will be able to make a better decision because this exists? Not a team, not a department. A specific person, or a specific role, with a specific mandate.
2. What is that decision? When does it get made, with what alternatives, with what stakes if the decision is wrong or delayed?
3. What data product makes that decision possible? Only after you can answer the first two does the dashboard, model or report take shape.

The artifact follows the brief. It does not lead it.

Why the chair stays empty

The chair does not stay empty because people are lazy or incurious. It stays empty because most delivery models measure the wrong thing. Velocity lives in dashboards shipped, reports produced, queries answered. The question “did that change a decision?” does not appear in most sprint reviews. So the brief that arrives as an artifact request gets treated as one — everyone delivers, and nothing changes.

The data team is not the problem. The delivery model is.

What a real brief looks like

A real brief has a name in the seat. Not “the finance team” — a specific person, or a clearly defined role, who makes a clearly named decision, by a clearly named date, with clearly named stakes. When that brief exists, every design choice in the data product has an answer. Should this be a daily refresh or weekly? Ask the chair. Should this include a drill-through? What does the chair need to decide? Should this compare this year to last? Does that comparison change the decision?

Absent the chair, those questions get answered by analogy (“the old dashboard had it”), by committee (“everyone wants it”), or not at all.

Doing good starts at that chair

DoGoDa’s premise is that data is a medium, and doing good is the brief. That sounds abstract until you are in a demo room and nobody can name the person whose decision this was supposed to sharpen. Then it is not abstract at all. It is a dashboard that will be delivered, and nothing will change.

The empty-chair practice does not require a methodology overhaul. It requires one question before the first meeting: who sits here, and what decision are they making? If nobody knows, naming that person is the first deliverable — not the model.

Happy to think this through with you.