What is a clarification brief?

Clarification brief vs requirements document

A requirements document is written after a decision, and its job is to remove uncertainty: it says what to build, precisely enough to build it. A clarification brief is written before the decision, and its job is the opposite — to make the uncertainty visible so the people deciding can see what they would be betting on. One is a build input; the other is a decision input.

That is also why a brief is short. A page is plenty, and often a third of one. If it starts growing acceptance criteria and screen descriptions, it has turned into a specification for work nobody has agreed to do yet.

A worked example

The request: "We need SSO for the enterprise tier by Q3." Known — what someone can point at: the request came from sales, the enterprise tier exists, and customers sign in today with email and password. Assumed — what the request takes for granted: that SSO means SAML rather than another protocol, that open deals depend on it, and that Q3 is tied to a contract rather than a hope. Unknown — what nobody has answered yet: which identity providers matter, whether user provisioning is part of the ask, and who owns authentication today.

Each line then has a next move. Every assumption becomes a question to send back to the requester. Every unknown gets either an owner who can answer it or, if it decides whether the work is worth doing at all, a time-boxed discovery.

Common mistakes

Promoting assumptions to facts because the requester sounded sure — confidence is a property of the writer, not the claim. Listing everything as unknown, which produces a brief nobody can act on; keep the unknowns that would change the decision. Treating inferences as known: if an assistant or a colleague filled in a gap, the result belongs under assumed until someone confirms it.

And writing the brief once and never reading it again. The assumptions list is the first draft of the risk register, and it is worth re-reading at the moment of commitment — some assumptions will have become facts by then, and the ones that have not are exactly the risks being accepted.

Related terms

• Demand management

  Demand management is the practice of deciding what happens to requested work — shaping raw requests into decidable demands, refusing or parking some on the record, and committing the rest against real capacity.

• Demand lifecycle

  The demand lifecycle is the path a work request takes from arrival to a closed outcome: Capture, Shape, Decide, Plan, Commit, Deliver, Learn — where a demand only walks the stages it needs.

• Intake

  Work intake is the point where work requests enter an organisation, and the bar a request must clear there to become decidable: what needs to change, plus who is affected or why it matters now.