Choose by Consumer, Not Habit

The reflex

Ask most organizations how a data product gets delivered and the answer is a dashboard. It is the default, it looks like the finished article, and it is frequently wrong.

The dashboard reflex fails for a specific reason: a dashboard requires the consumer to go somewhere and look. That works when someone has a standing habit of looking — a daily operations review, a weekly meeting with the screen already up. It fails for everyone else, which is most people, and it fails silently, because an unopened dashboard produces no complaints.

Meridian’s supervisor runs a Monday 7am crew-assignment meeting. He does not browse. If the ranked circuit list is not in front of him when that meeting starts, it does not exist.

My consumer is a distribution planning supervisor. He makes crew
assignments in a Monday 7am meeting. He does not write SQL and does
not browse dashboards. The output is a ranked list of circuits, at
most 15 rows, and he needs it before the meeting.

Recommend ONE primary delivery path from: ad-hoc query, scheduled
table, semantic model, dashboard, API, or push.

Justify it by where he is already looking when the decision is made,
not by what is most capable. Then tell me what that path obliges me
to maintain, and what should happen if the Monday load fails.

The “not by what is most capable” clause is there because an agent asked to recommend a delivery mechanism will gravitate toward the most featureful option. Capability is not the criterion; arrival at the point of decision is.

Stop and escalate when the consumer’s actual routine cannot be reached by any sanctioned channel — that gap belongs to the platform team and the owner, and a personal-email workaround is how shadow delivery starts.

KNOWLEDGE CHECK

You build a well-designed dashboard for a supervisor who makes his decision in a Monday morning meeting. Three months in, analytics shows he has opened it four times. What is the most likely explanation?

The six paths

Path	Right when	Wrong when
Ad-hoc query	One-time question, exploratory, no recurring decision	Anyone else needs to re-run it
Scheduled table	Other systems or analysts consume it; you are supplying data, not an answer	The consumer is a person who will not write SQL
Semantic model	Many people slice the same certified metrics in a BI tool	One consumer, one question
Dashboard	Standing habit of looking; exploration across dimensions matters	The consumer has no habit of looking
API	A system consumes it, or an application embeds it	A person is the consumer
Push — email, message, file	The consumer has a cadence and you must arrive inside it	The content needs exploration to be useful

The bottom row is the one that gets dismissed as unserious and is frequently correct. A Monday 6am message with eleven ranked circuits and a link is a legitimate data product: it has a named consumer, an owned definition, checks that block on failure, and a service level. That it arrives as text rather than as a chart is not a defect.

💡The question that settles it

Where is the consumer already looking when the decision gets made?

The delivery path should land there. Anything else asks them to add a step to an existing routine, and the routine wins.

Pick one primary

The temptation is to ship several: a table for analysts, a dashboard for browsing, and an email for the supervisor. That is three surfaces to keep correct, three places for the definition to drift, and three things to fix when the schema changes.

Commit to one primary path — the one the named consumer from Lesson 1.2 uses to make the decision. Everything else is secondary: it may exist, but it is not what the acceptance test gates on and not what pages someone at 6am.

That decision has a downstream consequence worth naming. Secondary surfaces built off the same certified table are fine. Secondary surfaces with their own logic are how you get back to three teams reporting three numbers, which Lesson 1.3 was about.

What each path obliges you to

Choosing a path incurs a commitment, and it is worth knowing before you pick:

Scheduled table — a schema contract. Adding a column is safe; renaming or retyping one breaks consumers you may not know about.
Dashboard — you now own its performance and its filters. A slow dashboard is abandoned as reliably as a wrong one.
API — versioning, error semantics, and availability. The heaviest obligation on the list, and the one people underestimate most.
Push — deliverability and a rule for what happens when the data is not ready. Sending stale numbers on schedule is worse than sending nothing.

That last one is the failure specific to push. If Monday’s load failed, the 6am message must say so rather than quietly repeating last week’s list. Lesson 3.4’s data-as-of line is what makes that automatic.

Key takeaway

Choose the delivery path from where the consumer already is when the decision gets made, not from what looks most like a finished data product. The dashboard reflex fails silently because an unopened dashboard generates no complaints, and it assumes a habit of looking that most consumers do not have. Push — a message or a file arriving inside an existing routine — is frequently the right answer and is dismissed for looking unserious. Commit to one primary path, keep secondary surfaces reading from the same certified table, and know what each path obliges you to maintain before you pick it. Lesson 5.2 covers what you owe a consumer once they depend on you.