Isn't writing a brief slower than just pulling the numbers?

It's faster end-to-end, almost every time. The twenty minutes spent scoping is what prevents the two days of rework when "that's not what I meant" lands at delivery. A brief front-loads the disagreement to when it's cheap to resolve — a two-line reply — instead of after you've built the wrong thing. The only case where skipping it wins is a genuinely trivial, unambiguous ask.

What if the requester doesn't actually know what they want?

That's the most valuable case for this playbook, not the exception. The clarifying questions in step one are designed to help a requester discover their own decision — "are you funding a retention push or reporting to the board?" forces the goal into focus. If they still can't say what they'd do with the answer, that's a finding: the request isn't ready to build yet, and the brief just saved you from guessing.

How is this different from the metric dictionary playbook?

The metric dictionary defines what your metrics mean once, for the whole team. An analysis brief scopes a single request — which of those metrics it needs, for which segment, to inform which decision. The brief cites the dictionary; it doesn't redefine metrics. If a brief needs a metric the dictionary doesn't have, that's a signal to go define it there first, not to invent a one-off definition here.

Do I send the brief to the stakeholder or keep it for myself?

Send it — that's the point. A brief you keep to yourself is just notes; a brief the requester signs off on is a lightweight contract. Their quick "yes" (or "also add X") is what lets you build with confidence and what turns a later "that's not what I asked for" into a conversation about an agreed scope rather than an unpaid rebuild.

Turn a vague request into an answerable analysis brief

when to reach for this

"Can you pull some numbers on churn?" is not a question — it's the start of three rounds of rework. You build something, they say "not quite what I meant," you rebuild, and the deadline slips while everyone's frustrated. The fix isn't to query faster; it's to spend twenty minutes turning the vague ask into an answerable brief before you touch the data — the decision it informs, the precise questions, the exact metrics and sources, the segments, and what's explicitly out of scope. Pinning the question down is the single highest-leverage analyst move there is: it's the difference between answering what they asked and answering what they meant.

gather this first

The original request as it came in — the Slack message, the email, the line from the meeting. Don't paraphrase it; you want the actual words so you can see what's ambiguous.
Who's asking and what decision they'll make with the answer — a number that changes a decision and a number that's just curiosity are scoped completely differently.
The deadline and the format they need, and your metric dictionary (metrics.md) so the brief's definitions point at the agreed ones, not freshly-invented ones.

the workflow

Pin the decision behind the request

Open the folder with the request and your metrics.md in Claude Desktop and ask in the chat — no terminal needed. Before any questions or queries, force the real goal to the surface: what will this person do differently depending on the answer? Everything downstream — which questions matter, how precise to be — hangs off this.

you ask

Here's a request I got: "[paste the exact message]". Before we scope any analysis, help me pin the decision behind it: what is this person most likely trying to decide or do with the answer, who is the audience, and what would make this analysis a success versus a waste of time? List the questions I should ask them to confirm the goal — don't design the analysis yet.

what you get back A sharp read of the underlying decision plus 3–4 clarifying questions to send back: "Are you deciding whether to fund a retention push, or reporting churn to the board? Which segment — all customers, or enterprise? By when?" You learn what they meant before you build for what they said.

The decision is the anchor. "Look into churn" to decide a retention budget and "look into churn" to put a number in a board deck are two different analyses — don't start until you know which.
Turn the vague ask into precise, answerable questions

A fuzzy request hides several sharp questions. Decompose it into the specific, answerable ones — each phrased so you'd know an answer when you saw it.

you ask

Given that decision, break the request into a short list of precise, answerable questions — each one specific enough that I'd recognize the answer ("what was monthly logo churn for enterprise accounts over the last 4 quarters?" not "how's churn?"). Order them by how much each one actually moves the decision, and drop the ones that are nice-to-know but won't change anything.

what you get back A ranked list of crisp questions, the decision-moving ones first and the curiosity ones cut — so your effort goes where it changes the outcome, not into every number you could produce.
Map each question to metrics, sources, and the cut

Now make it buildable. For each question, name the exact metric (from the dictionary), the data source, and the breakdown — so there's no definition ambiguity left to discover halfway through.

you ask

For each question, map out what it takes to answer: the exact metric and its definition from metrics.md (flag any metric we haven't defined yet — that's a blocker to resolve first), the data source or file, the segments/breakdown needed, and the time window and comparison baseline. Tell me where I'm missing a definition or a data source.

what you get back A per-question plan — metric, source, cut, window — with the gaps called out: "'churn' is defined in metrics.md; but 'engaged account' isn't — define it before building. Source: the subscriptions table; needs a region breakdown." The unknowns surface now, not mid-build.

An undefined metric is the most common cause of rework. If a question needs a metric the dictionary doesn't have, resolve it in Build the metric dictionary every query and report inherits first — don't quietly invent a definition that contradicts everyone else's.
Set the scope — and write down what's out

Half of rework is scope creep nobody named. State explicitly what's in v1, what's deliberately out, and which assumptions you're making — so an unspoken expectation can't ambush you at delivery.

you ask

Draft the scope: what this analysis will deliver in v1, what is explicitly out of scope (so it can't be assumed in later), and the assumptions I'm making that the requester should confirm before I build. Flag anything that, if I've guessed it wrong, would mean redoing the whole thing.

what you get back An explicit in/out-of-scope list plus the load-bearing assumptions surfaced for confirmation: "In: quarterly logo churn, enterprise, 4 quarters, by region. Out: revenue churn, root-cause analysis. Assuming 'enterprise' = the segment tag in the CRM — confirm." The expensive wrong-guesses are caught before they cost anything.
Assemble the one-page brief and agree it before you query

Pull it into a short brief and send it back for a yes before building. A two-line reply now saves the two-day rebuild later — this is the cheapest checkpoint in the whole analysis.

you ask

Assemble it into a one-page analysis brief: the decision, the audience and deadline, the ranked questions, the metrics and sources for each, the in/out-of-scope list, and the assumptions to confirm. Keep it to a page. Write it so I can paste it to the requester and get a quick yes-or-adjust before I start.

what you get back A paste-ready one-page brief you send for sign-off. Once they reply "yes" (or "actually, also X"), you build with confidence — and if it changes later, you point at the agreed scope instead of silently absorbing the churn.

Getting a thumbs-up on the brief is the whole point. The brief is a cheap contract: it makes 'that's not what I asked for' a conversation about a documented scope, not a free rebuild.

make it your own

Straight into the query: once the brief is agreed, hand it to Write the query and learn the SQL — the precise questions and mapped metrics are exactly its inputs, so you skip the 'what do you actually mean' step entirely.
A recurring request becomes a template: if the same kind of ask lands often ("the monthly numbers," "a churn look"), save the brief as a reusable template or a /brief command (see the Features tab) so scoping the next one takes five minutes.
Bilingual stakeholders: if the requester works in Arabic, write the brief in Arabic so the scope is unambiguous to them — the clarity of the agreement matters more than which language you personally drafted in.
It's a dashboard, not a one-off: if the decision is recurring ("I need to watch this"), the brief becomes the spec for a standing view — carry it into Build a recurring analysis report rather than answering once and getting asked again next month.

watch out for

A brief is an agreement, not bureaucracy. The twenty minutes isn't process for its own sake — it's the cheapest possible checkpoint, and skipping it is what turns a half-day analysis into a three-day one. If the requester won't engage with a one-pager, that itself tells you the request wasn't real yet.
Don't let Claude invent the decision. It can propose what the requester probably wants, but only the requester can confirm the actual decision — treat step one's read as a hypothesis to verify with them, not a fact to build on.
An undefined metric in the brief is rework waiting to happen. If a question depends on a metric your dictionary doesn't have, resolving the definition is a blocker, not a detail — settle it before you query, not after the stakeholder questions the number.
Scope written down is scope you can defend; scope in your head is scope that creeps. The out-of-scope list is the most valuable line in the brief — it's what lets you say "that's a v2" instead of silently rebuilding.

you'll end up with A one-page analysis brief — the decision, the ranked questions, the exact metrics and sources, and an explicit scope — agreed with the requester before you query, so you build the right analysis once and have a documented contract if the ask later drifts.

Questions people ask

Isn't writing a brief slower than just pulling the numbers?: It's faster end-to-end, almost every time. The twenty minutes spent scoping is what prevents the two days of rework when "that's not what I meant" lands at delivery. A brief front-loads the disagreement to when it's cheap to resolve — a two-line reply — instead of after you've built the wrong thing. The only case where skipping it wins is a genuinely trivial, unambiguous ask.
What if the requester doesn't actually know what they want?: That's the most valuable case for this playbook, not the exception. The clarifying questions in step one are designed to help a requester discover their own decision — "are you funding a retention push or reporting to the board?" forces the goal into focus. If they still can't say what they'd do with the answer, that's a finding: the request isn't ready to build yet, and the brief just saved you from guessing.
How is this different from the metric dictionary playbook?: The metric dictionary defines what your metrics *mean* once, for the whole team. An analysis brief scopes a single request — which of those metrics it needs, for which segment, to inform which decision. The brief *cites* the dictionary; it doesn't redefine metrics. If a brief needs a metric the dictionary doesn't have, that's a signal to go define it there first, not to invent a one-off definition here.
Do I send the brief to the stakeholder or keep it for myself?: Send it — that's the point. A brief you keep to yourself is just notes; a brief the requester signs off on is a lightweight contract. Their quick "yes" (or "also add X") is what lets you build with confidence and what turns a later "that's not what I asked for" into a conversation about an agreed scope rather than an unpaid rebuild.