The Two-Column Brief That Stops Projects Drifting
Projects rarely drift because nobody wrote a brief. They drift because the brief becomes a collection of background, aspirations, features, stakeholder comments, and delivery instructions without showing which statements should guide a difficult trade-off.
A two-column brief creates a sharper boundary. The left column describes the result the work should create. The right column describes the conditions it must respect. Every important discussion can return to those two questions: Are we increasing the likelihood of the result, and are we still operating within the constraints?
Column one: the change
Begin with the current situation and the observable change you want. Write for a specific person or group. “Improve onboarding” is not enough. “Help first-time administrators complete setup without a support call” identifies an audience, behaviour, and point of friction.
Add one primary signal that would indicate progress and one guardrail that should not worsen. The signal might be successful setup within a session; the guardrail might be account errors or later support demand. These measures frame learning rather than guarantee attribution.
Column two: the operating conditions
List the boundaries the team must respect: time, budget, regulation, technology, brand commitments, existing contracts, accessibility, security, or operational capacity. Distinguish fixed constraints from assumptions. “Must use the current identity provider” is different from “We believe customers prefer email verification.”
Keep the list short enough to use. If a condition cannot change a design or delivery decision, it belongs in background material rather than the brief.
Add explicit exclusions
Below the two columns, state what this project will not solve. Exclusions protect the result from adjacent problems that become visible during delivery. They are not a refusal to care; they are a record of sequence.
Give each excluded item a destination: a later phase, another owner, the backlog, or a separate discovery question. Otherwise exclusions quietly return as urgent requests near the deadline.
Use evidence beneath the claim
For every important sentence in column one, link the evidence that supports it: observations, service data, complaints, interviews, or direct process review. Keep interpretation separate from fact. “Five of eight participants stopped at verification” is evidence; “users do not trust us” is a hypothesis.
This discipline prepares better decisions. When the team meets, the statement from Write the Decision Down Before the Meeting Begins can point to the exact evidence and constraints that matter.
Invite challenge before approval
Send the draft brief to the people closest to customers, delivery, compliance, and operations. Ask four questions: Is the desired change real? Is the audience specific? Which constraint is missing? Which assumption is being treated as fact?
Do not invite general comments. A precise review question produces better corrections and prevents the brief from expanding into a compromise document that contains every stakeholder’s preferred language.
Test the brief with three trade-offs
Before work begins, imagine three plausible conflicts: speed versus depth, consistency versus local fit, or automation versus operational control. Use the two columns to decide how the team should respond. If the brief cannot guide these choices, the result or constraints are still too vague.
A brief is useful when it makes some attractive ideas clearly wrong for this project.
Keep it visible during delivery
Place the two columns beside the plan, prototypes, or task board. Review changes against them. When a new request appears, identify which result it supports and which condition it affects. If neither answer is clear, it should not enter active work without a deliberate scope decision.
The visible-progress method in Make Progress Visible Without Building Another Dashboard can show whether the team is moving evidence, decisions, and finished outcomes—not merely accumulating activity.
Update through decisions, not silent edits
Briefs should evolve when evidence changes. Record the change, reason, owner, and consequence rather than replacing text without history. This keeps later reviewers from treating an early assumption as the original agreement.
At handover, include the current brief and its important revisions. The receiver can then understand both the destination and the operating terrain. Two columns will not remove uncertainty, but they give uncertainty a clear place to be discussed.
