Start with the question

A project often arrives as a proposed solution: a new page, a revised process or another feature. That can be a useful starting point, but it is not yet a brief. Before making a plan, ask which question the proposed work is meant to answer.

The question should describe a real situation. Who is trying to do something? Where do they get stuck? What would be different if the work succeeded? A sentence grounded in an observable problem is easier to discuss than a broad ambition such as making an experience better.

Next, gather the context that could change the answer. This might be a conversation with a customer, a technical limitation or a commitment already made. Keep the source beside the observation. A direct quote, an interpretation and an assumption are different kinds of evidence; give each enough context to be understood.

Write down the constraints without turning every preference into a rule. A fixed deadline is different from a date someone suggested in passing. A legal requirement is different from a familiar way of working. Knowing which boundaries can move helps a team explore useful alternatives.

A good brief also names what is outside the current decision. This protects focus without pretending those concerns do not exist. Leave a place for unanswered questions and identify who can help resolve them. The brief can stay short because it points to the right detail rather than repeating everything.

Finally, ask someone who was not in the first conversation to read it. Can they explain the problem and the next decision in their own words? If they can, the brief is ready to support a plan. If they cannot, improve the question before adding more tasks. A clear question does not remove uncertainty; it gives the team a shared way to recognise what they still need to learn.