The Client Brief Is a Draft, Not a Specification
A client brief is almost never a specification. It is a description of a problem, written by someone who is not sure what they want, in the language of a solution. "We need a dashboard" is not a requirement. It is a guess about what would fix something.
Before any analysis starts, the brief has to be converted into a scoped question. That conversion is the part worth doing carefully, and it is the part where a model helps most — provided you understand what it cannot do.
What a brief actually contains
Read the same brief twice and two different documents appear.
The first reading is the surface: deliverables, timelines, a budget range, some named stakeholders. The second reading is the underneath: what the buyer is worried about, what decision this work has to support, and what they will do differently if the answer is inconvenient.
Almost all briefs contain both, with the second one unstated. The work of scoping is extracting the second from the first and putting it in writing where the client can disagree with it — early, cheaply, before you've built anything.
The three-step conversion
Step one: separate the stated solution from the stated problem.
Take every sentence in the brief that names an artefact — a report, a dashboard, a workshop, a strategy — and set it aside. What remains is the problem: the thing that prompted the request. If nothing remains, the brief is entirely solution and you have no idea what it is for. That is not a small gap; it is the whole job.
Step two: name the decision the work must support.
Not "the client wants to understand X." Understand for what? Somebody has to choose something: fund this or not, enter this market or not, restructure this team or not. A piece of research that does not change a decision is a document, not an analysis.
This step is also where briefs are most often wrong. Clients frequently ask for analysis without having identified the decision. Asking "what will you do differently depending on the answer" is uncomfortable precisely because it has no diplomatic form, and it is the single most valuable question available.
Step three: write the scope as falsifiable statements.
Not "understand customer churn" but "identify which of the three suspected causes explains the majority of churn in the last two quarters, and state what evidence would have contradicted each one." The second version can be judged wrong. The first cannot.
A worked example
Take a brief that reads like this:
"We're a B2B software company, roughly 80 staff. Our churn has been climbing and the board is asking questions. We'd like a customer research project — maybe 15 interviews — and a report on why customers leave. Budget is tight, and we'd need it within six weeks."
Read it as a solution and you book interviews. Read it as a problem and something else appears.
The stated solution is the research project. Set it aside. What remains: churn is climbing, the board is asking, and nobody in the request knows why customers leave.
Now the decision. "Understand churn" is not a decision. Candidates that are decisions: whether to invest in retention work or accept the loss rate as the cost of the segment; whether the sales team is selling to the wrong buyers; whether to change the product roadmap. Those lead to very different research.
So the scoping message becomes something like: "Before I propose interviews, one question — what will you change depending on what the research finds? If the answer is 'we'd fix the onboarding,' then the useful question is why customers who complete onboarding still leave within ninety days, and that might be answerable from your existing data in a week rather than from fifteen conversations in six. If the answer is 'we don't know what we'd change,' then the board problem is not a churn problem, and the research will produce a report rather than a decision."
That message does three things at once. It finds the decision, it tests whether the requested artefact is the right one, and it demonstrates a level of thinking the client can evaluate before spending anything. It also risks the client deciding they don't need the project — which is the correct outcome if the brief really was a solution looking for a problem.
Notice what the model contributed and what it didn't. It could have pulled the constraints out of the brief (six weeks, tight budget, 80 staff, board pressure) in seconds, and it could have listed eight plausible reasons churn might be rising for a company of that shape. The reframing — that "why do they leave" might be the wrong question — is the part that required knowing what a decision looks like.
Where the model does real work
Three things, all mechanical enough to be reliable.
Compressing a long discovery conversation into the actual request. Call transcripts and email threads run to thousands of words, most of which is scheduling and politeness. Asking a model to extract only commitments, constraints, and named people is a pure information task with a checkable answer — you can verify against the transcript.
Generating the hypotheses you'd otherwise anchor past. Give it the problem and ask for eight plausible causes, including ones that would be inconvenient. Its value here is not insight; it is coverage. It will suggest causes you find embarrassing or unlikely, and those are often the ones you'd have excluded from consideration without noticing.
Restating your scope as a testable sentence. Ask it to rewrite your scoped question so that a competent third party could tell whether the work answered it. This is a phrasing check, and it catches vagueness reliably because vagueness is a textual property.
Where it fails, specifically
It will invent the client's context. Ask a model to draft a problem statement from a thin brief, and it will produce one that describes a plausible company with plausible constraints. That company is not your client. The output is fluent and almost entirely fabricated, and it is dangerous precisely because it reads like insight.
The countermeasure is structural, not verbal: never let the model produce content about the client. Only let it operate on text you paste from the actual engagement. If a claim about the client cannot be traced to a sentence in the transcript, it does not go in the document.
It will resolve ambiguity instead of surfacing it. Real briefs are internally inconsistent — the timeline doesn't fit the scope, the budget doesn't match the deliverables, two stakeholders want opposite things. A model given that brief will produce a coherent synthesis, quietly picking one interpretation. The coherence is the problem: the contradiction is the most useful thing in the document.
So ask for it explicitly. "List every pair of statements in this brief that cannot both be true." Then put those contradictions in front of the client. Each one is a decision they have not made yet, and each one would otherwise have surfaced in week three as a change request.
It will agree that your framing is correct. If you paste your own problem statement and ask for feedback, the default response is improvement, not challenge. Ask instead for the sharpest possible argument that the framing is wrong, and treat the answer as a hypothesis to check rather than a verdict.
The human step that cannot be delegated
At the end of this, one person has to write the scoped question and send it to the client as something they can disagree with.
This is the moment the whole workflow exists to reach, and it is also the moment people flinch. Sending a scoped question invites the client to say "no, that's not what I meant," which feels like a setback. It is not. It is much cheaper now than it will be after the work is delivered.
The sentence to send is short: "Here is what I understand you to be asking for, and here is what I'm treating as out of scope. If either is wrong, tell me now — it's much cheaper to fix today than in six weeks." Attach the falsifiable scope, the contradictions you found, and the decision the work is meant to support.
What the model gave you is a first draft of that document in ten minutes instead of two hours. What it could not give you is the willingness to send it, or the judgement about which contradictions matter. Those remain yours, and they are the reason the exercise is worth doing at all.
A test you can run on your own briefs
Take the last brief you accepted. Write down, in one sentence, the decision it was meant to support. Then write the sentence that would have been falsified if the analysis had come back the other way.
If you can't produce both, the brief was never scoped — the work proceeded on mutual optimism, and whatever you delivered was judged on how it looked rather than whether it settled anything. That is worth knowing before the next one arrives.
This note describes a method, not a measured result. No time savings or success rates are claimed. No client work is described; the failure modes above are properties of the tools, not observations of specific engagements.
Related notes
- The Proposal Doesn't Need Writing. It Needs Deciding. — the scoped question you produce here becomes the scope block of the proposal.
- The Meeting Notes Are Not the Work. The Decision Log Is. — "the decision this work must support" is a decision somebody has to record and own.
- The Four Seconds After You Say Your Price — what happens when the scoping call turns into a pricing call.