Name the Consumer and the Decision

The request as it actually arrives

Nobody asks for a data product. They ask like this:

“Can we get a dashboard for circuit reliability?”

That sentence contains no consumer, no decision, and no definition of reliability. Build directly from it and you will produce something reasonable that nobody opens after week three — the most common outcome in this line of work, and an expensive one, because it consumes a month and teaches the organization that data work does not pay off.

Three questions convert it into something buildable. Ask them before you open a query editor.

Prompt first: interrogate the request

The temptation is to hand the request to an AI CLI and ask it to build the thing. Resist that for one more lesson. What an agent is genuinely good at here is interrogating the request:

I have a data request: "can we get a dashboard for circuit reliability?"

Do not design anything yet. Instead, list the questions I need answered
before this is buildable, grouped as:
  - consumer and cadence
  - the decision that changes, and the grain that implies
  - freshness requirement, derived from the decision rather than asserted
  - cost of a wrong value, and what that implies for checking
For each question, note what I should do if the answer is "nobody knows."

You are using the agent as a checklist that does not get tired or polite, not as a designer. The output is a list you take into a fifteen-minute conversation with the supervisor. That conversation is the actual work of this lesson, and no tool does it for you.

Stop and escalate when nobody can name a reader after a real attempt: back to the requester, not onward to a build. A freshness dispute that survives the anchoring conversation goes to whoever owns the decision, because it is a claim about the meeting, not about the data.

1. Who reads this, by name?

Not “leadership.” Not “the ops team.” A person or a specific role who will look at it on a known cadence.

At Meridian the honest answer turned out to be the distribution planning supervisor, who runs a Monday morning crew-assignment meeting. That single fact settles a surprising number of downstream decisions: it must be right by Monday 7am, it has to be readable in eight minutes, and it needs to identify circuits, not summarize the fleet.

If nobody can name a reader, you have found something important early. Either the request is exploratory — in which case run the query, answer the question, and do not build anything — or the requester is asking on behalf of someone they have not consulted, which you want to discover now rather than at delivery.

2. What decision changes because of it?

The test is whether you can complete this sentence: “When this number is X rather than Y, we do Z instead of W.”

For Meridian: “When a circuit’s degradation score crosses the threshold, it goes on this week’s proactive maintenance list instead of waiting for a failure call.”

That sentence is doing more work than it looks like:

• It tells you the output is a ranked list of circuits, not a trend chart. Nobody assigns a crew to a trend line.
• It tells you the grain is one row per circuit, not per meter or per outage event.
• It tells you a threshold exists, which means somebody has to own what the threshold is — and that is a decision, not a calculation.

3. What does it cost when it is late or wrong?

Two separate costs, and they size two different parts of the work.

Late sets your freshness requirement and therefore most of your engineering effort. “Right by Monday 7am” is a weekly batch, which is straightforward. “Right within five minutes” is a fundamentally different and much more expensive system. Ask, and then push back on the first answer — the reflexive response to “how fresh?” is “real-time,” and the reflexive answer is almost never the true one. Anchor it to the decision instead: crew assignments happen once a week, so anything fresher than weekly is engineering nobody will use.

Wrong sets how much of Module 4 you need. A wrong circuit on a maintenance list costs a wasted truck roll — recoverable, annoying, and worth ordinary checks. A wrong number in a rate filing costs a regulatory finding and is worth reconciliation against an authoritative source before every publication. Same effort spent in different places, decided by this one question.

Key takeaway

Three questions turn a request into something you can build: who reads it, what decision changes, and what it costs when it is late or wrong. The second question quietly determines your output shape and grain; the third splits your effort between freshness engineering and correctness checking. A request that cannot answer the second one should be satisfied with a query and an email, not a data product. Lesson 1.3 takes the definition problem hiding inside the word “reliability.”