A project brief is where a product project succeeds or quietly starts to go wrong. A vague brief produces inconsistent decisions, slipping timelines and a product that misses the mark. This guide covers what a good brief contains, how to make requirements specific enough to actually design against, and why the brief keeps working for you as the project develops.
A well briefed and well managed project rarely goes badly wrong. Most problems trace back to the same root: the brief didn't say clearly enough what the product had to be, so decisions downstream were made on assumption. Getting the brief right is the cheapest investment in a project's success there is, because it aligns everyone before any expensive work begins.
What a brief is for
A brief sets out what the product must achieve and the constraints it must work within, so that everyone involved is designing toward the same target. It's not a specification of how to build the product, that comes later, it's a clear statement of the goals, the requirements and the boundaries. Its job is to keep the whole team aligned as the detail is worked out.
Make requirements specific enough to design against
The most common weakness in a brief is generality. "Lightweight" is not a goal a designer can work to; "as light as possible while meeting the other critical requirements, and under 3kg" is. The more specific a requirement, the more focused the design process, and the less room for a decision to drift from what you actually needed. Specificity early is what prevents expensive misunderstandings later.
A thorough brief covers requirements across several areas:
- Technical requirements, the performance the product has to deliver.
- User requirements, who it's for and how they'll use it.
- Environmental requirements, where and in what conditions it operates.
- Safety, regulatory and compliance requirements, the standards it must meet.
- Functional requirements, what it has to do.
Prioritise with MoSCoW
Not every requirement carries equal weight, and pretending they do makes trade-offs harder later. Prioritising functional requirements, using a simple framework such as MoSCoW (must have, should have, could have, won't have), makes clear which are critical to success and which can be de-prioritised or dropped if something has to give. That clarity is invaluable when constraints bite, as they usually do.
Keep it clear, and involve the right people
A good brief is clear and concise, uses plain language, and avoids unnecessary jargon so that everyone reading it takes the same meaning from it. It's also worth making sure all the relevant stakeholders are involved in shaping and reviewing it, so the brief reflects the whole picture rather than one person's view, and so the decisions in it carry genuine ownership across the team.
The brief evolves
A brief is not fixed at the outset and then filed. Questions that can't be answered at the start will have answers as the project progresses, and a good brief is reviewed and revised as that happens. Treating it as a living document, rather than a one-time formality, is what keeps it useful all the way through development rather than only at the beginning.
Related guides: Product Development Lifecycle · Designing a Product: A Step by Step Guide · Product Research a Step by Step Guide
FAQ
What is a project brief? A document setting out what a product must achieve and the constraints it must meet, so everyone works toward the same target. It defines the goals and requirements, not the method of building.
What makes a brief clear enough? Specific, measurable requirements. "Under 3kg" can be designed against; "lightweight" can't. The more precise the requirement, the more focused the work.
Should the brief change during the project? Yes. Some questions can only be answered as work progresses, so a good brief is reviewed and revised rather than treated as fixed.
Who should be involved in the brief? All the relevant stakeholders, so it reflects the full picture and the decisions in it are genuinely owned across the team.
