How to write a useful first project brief

A useful first project brief describes something a person needs to do and the difficulty they face today. It gives a project team enough context to discuss the work, while leaving room for questions that still need answers.

You can begin with three things: the problem, your setup and a useful result. The example below expands those starting points into a short brief with seven fields, including the people involved, the limits of the work and questions still to answer.

An imagined studio example

Imagine a studio that runs small group classes. Customers request places by email. A studio coordinator checks a shared calendar, asks for missing details and replies to confirm whether a place is available.

The studio wants to explore a clearer way to receive requests. Its first brief could look like this.

A filled first brief

The problem

People sometimes request a place without naming the class or their preferred session. The coordinator needs another exchange before checking availability. We want the initial request to contain the information needed for that check.

The users

A customer requesting a place and the studio coordinator reviewing the request. The customer needs to understand what they are requesting. The coordinator needs to see which class and session the request concerns.

Your setup

We have a website with class descriptions, a shared calendar for availability and an inbox for customer enquiries. The coordinator confirms places manually. We need to establish who maintains the calendar and whether it contains the information required to check a request.

A useful result

A customer can choose a class, identify a preferred session and submit their name and contact details. The customer understands that submitting a request does not reserve a place. The coordinator can review the request and decide what reply is needed.

The success check

Using a sample request, we can check whether a customer identifies the intended class and session and understands that confirmation is still pending. We can also check whether the coordinator receives the information needed to review it. We still need to agree how requests will reach the coordinator.

The scope boundary

This first discussion covers receiving and reviewing a booking request. It does not include taking payment, automatically confirming availability or replacing the shared calendar. A connection to the calendar is an open question, subject to checking how it works.

The open questions

Which classes accept requests? Can customers request several places? Who covers the inbox when the coordinator is away? What should the customer see if a request cannot be submitted? How will the coordinator distinguish a new request from one already answered?

What this brief makes possible

The example names a specific task: requesting a place in a class. It also exposes a distinction that affects both wording and implementation. A request and a confirmed booking are different events. That distinction needs to remain clear throughout the experience.

The success check makes the desired task observable. It can be refined as the team answers the open questions.

The boundary also makes the discussion more precise. Payments and automatic confirmation may become useful later. Keeping them outside this first proposal allows us to examine the request itself.

Keeping the brief manageable

A first brief can leave questions unanswered. An unknown calendar format, an unclear responsibility or a missing example is useful information when it is named plainly.

The brief becomes a working note that can change as those questions are answered. Existing class descriptions and a sample calendar entry may help explain the setup, with private customer details removed. A short example may provide enough context for the next discussion.

Write your own first brief using these seven labels, with one sentence under each and any unknowns recorded as questions.

Prepared for WGMI with AI assistance.