Most briefs describe what someone wants built. Strong briefs make visible why it matters, what remains uncertain and which decision the next stage is expected to make.
Name the decision before the deliverable
“Design a dashboard” is an output request. The underlying decision may be how a manager recognizes risk early, which signals deserve attention or what action should follow each state.
When the decision is named, the team can evaluate several solutions. When only the deliverable is named, everyone optimizes the first interpretation.
Keep uncertainty inside the brief
A brief should not make the project look more certain than it is. Separate confirmed evidence, working assumptions, open questions and explicit constraints.
That separation helps Strategy know what to validate, Product know what to prototype and Engineering know which choices should remain flexible.
Write acceptance as evidence
Acceptance should describe what must be demonstrated, not who feels satisfied. A journey can be tested. A requirement can be traced. A release can show its checks and known limitations.
This turns approval from a vague reaction into a review of a specific version against shared expectations.
What to carry forward
- Start with the decision, not the requested artifact.
- Separate evidence, assumptions, questions and constraints.
- Define who owns the next decision.
- Express acceptance in observable evidence.