The Dashboard Request That Wasn't a Question

What is wrong

• It names a deliverable (a dashboard) and a topic (loyalty), not a decision. "Is it working?" has no metric, no baseline, and no comparison group, so it cannot be answered as written.
• It is unbounded: "everything" against three weeks and a part-time engineer guarantees a shallow artifact rather than an answer.
• It repeats a documented failure. The 40-tab workbook is evidence that the constraint is scope, not tooling - so building more tabs is the wrong response.

First 48 hours

1. Meet marketing, finance, and the director separately. For each, ask: what decision will this number change, and what would make you act differently? Write the answers down verbatim.
2. Get the board agenda. If there is no agenda item tied to loyalty, the real request is reassurance, not analysis.
3. Write a one-page scope memo: the business task statement, the primary metric, 2–3 supporting metrics, agreed definitions, and an explicit out-of-scope for v1 list.
4. Ship a rough three-metric prototype (even a static chart) before hardening anything, so the stakeholders react to something concrete instead of to their imagination.

Key judgement: the deliverable format is negotiated after the question is defined, not before. Saying "a dashboard may not be the right output" in week one is cheaper than saying it in week three.

Business task statement (example)

"Determine whether households enrolled in the loyalty program for six months or more spend more per basket and shop more often than comparable non-enrolled households, so the board can decide whether to renew the loyalty platform contract."

Why this version works: it has an actor (the board), a decision (renew or not), a comparison (enrolled vs comparable non-enrolled), a time frame, and measurable quantities.

Clarifying questions

1. What action follows from each possible answer? If nothing changes either way, this is a reporting request, not an analysis.
2. Over what window does "active" count - 30, 60, or 90 days - and must it reconcile to finance's figure?
3. Is "spend" gross revenue, net of returns, or margin? Do refunds and cancelled orders count?
4. What is the comparison group? Enrolled households already chose to enrol, so they likely already spent more; a pre-enrolment baseline is a different (and stronger) design than enrolled vs non-enrolled.
5. Who signs off on the definition, and where is it stored?

Judgement point: question 4 is the one stakeholders never volunteer. Answering it changes whether the analysis can support a causal-sounding claim at all.

Reframe the conflict. Neither definition is wrong; they measure different constructs (engagement vs commercial activity). The problem is that both are being published under the same label, "active member."

Steps

1. Build a reconciliation table, not an argument: count members who (a) opened a push and transacted, (b) opened only, (c) transacted only, (d) neither. This converts a disputed number into a shared one.
2. Tie the choice to the decision. If the board is deciding whether to renew a marketing platform, engagement is relevant; if it is deciding contract value per member, transactions are. State this explicitly rather than splitting the difference.
3. Name them differently. Publish "engaged member" and "purchasing member" as separate metrics; never let two definitions share one label on one dashboard.
4. Assign ownership and governance: one owner per metric, a change-logged definition, and a sign-off before anything reaches the board.
5. Escalate the trade-off, not the data. Give the director the two definitions, the overlap counts, and the consequence of each - a decision they can make in one minute.

Avoid: averaging the two figures, silently adopting the more senior stakeholder's number, or displaying both without labelling them. Each of those loses trust permanently the first time someone re-derives the number themselves.