01
Start with the need, not the solution
Describe who will use the product, which task causes problems today, and what should change after the project. Keep the goal separate from a proposed solution: "reduce duplicate entry" leaves room to explore options, while "build a dashboard" already assumes a form that may not be right.
Add the constraints that truly shape the work: existing tools, data types, access roles, confidentiality requirements, deadlines, and the people available to review decisions. If information is missing, mark it as an open question instead of turning it into a silent assumption.
02
Define a scope that can be checked
Sort needs into three groups: essential for the first release, useful later, and explicitly out of scope. For each priority need, describe a concrete scenario with a starting point, key steps, and an expected result. This makes the work easier to estimate and changes easier to recognize.
Describe the connections to existing systems as well: which data enters, which leaves, how often, and who owns it. Naming an integration without defining the data flow leaves room for surprises during delivery.
03
Write acceptance criteria
A feature is not complete just because it appears on screen. State what a user must be able to do, on which devices, with which permissions, and what should happen when something goes wrong. For a form, acceptance also includes the message shown to the visitor, delivery of the inquiry, and handling of incomplete input.
Name the person who can accept each deliverable and allow a realistic review window. Record dependencies such as content, account access, legal approval, or business decisions. A schedule is credible only when these contributions are included.
04
Manage changes without stalling delivery
Keep a short decision log: topic, chosen option, owner, and date. When a new request arrives, assess its effect on cost, timing, and already approved work before adding it to scope. This is not about rejecting ideas; it is about making deliberate choices.
Review blockers and risks regularly, ending each discussion with a clear decision. Useful meeting notes tell everyone what they need to do next.
05
Review the brief before work begins
Before starting, check that the document answers five questions: why this project, for whom, what to deliver first, how to accept it, and who decides when priorities conflict. If one answer is missing, the brief still needs work.
A project brief cannot remove every surprise. It gives the team a shared basis for handling surprises without confusing discovery, a change in scope, and a delivery delay.
