When you approach an agency or development team about a new project, the first document you send shapes everything that follows. A vague brief leads to vague proposals, wide-ranging estimates, and weeks of clarifying questions. A clear brief gets you comparable proposals, realistic estimates, and a faster start.
The good news: a useful brief does not need to be long or technical. It needs to explain the problem, the people, and what success looks like. This guide walks through what to include.
1. The problem you want to solve
Start with the problem, not the solution. Describe what is not working today and why it matters.
- What is happening now, and what is the cost of leaving it as it is?
- Who is affected, and how often?
- How do people work around the problem today?
"Our support team answers the same 30 questions hundreds of times a week, and response times have doubled this year" is far more useful than "we want an AI chatbot".
2. Who it is for
Describe the people who will use the product or be affected by it: customers, employees, partners. Include what they are trying to achieve, what devices they use, which languages they speak, and how comfortable they are with technology.
3. What success looks like
Define how you will know the project worked. Try to make it measurable:
- Response time under a certain number of hours
- A share of enquiries resolved without a person
- A process that takes minutes instead of hours
- A number of signups, sales, or bookings
Clear success measures help a team propose the right scope and help you judge the result later.
4. Scope: must-haves and nice-to-haves
List the features or capabilities you think are needed, and sort them into two groups:
- Must-haves: without these, the first version is not useful
- Nice-to-haves: valuable, but could come later
This single step does more than anything else to keep budgets realistic. It also invites the team to suggest a smaller first version that tests your idea faster.
5. What already exists
Describe your current setup:
- Systems and tools the project must connect to, such as a CRM, website, database, or help desk
- Existing content or data the project will use, and what state it is in
- Brand guidelines, designs, or previous attempts, including what did not work
Integrations and data are often where hidden effort sits, so the more you share, the more accurate the estimate.
6. Constraints
Be upfront about limits:
- Budget: a range is fine and saves everyone time
- Timing: any fixed deadlines, such as a launch event or season
- Rules: privacy, security, industry regulations, or internal policies
- Technology: platforms or hosting you must use or must avoid
Sharing a budget range is not a weakness. It lets a team propose what is realistic, rather than guessing.
7. How you want to work together
- Who makes decisions on your side, and how quickly can they respond?
- How involved do you want to be during the project?
- Will someone on your team take over maintenance after launch?
What to leave out
- Detailed technical specifications, unless you have strong reasons. Let the team propose the approach.
- Long feature wish lists without priorities. They make estimates balloon.
- Confidential details before an agreement is in place. Describe them in general terms first.
A template to copy
Project name: [working title]
The problem: [what is not working and why it matters]
Who it is for: [users and their goals]
Success looks like: [two or three measurable outcomes]
Must-haves: [the essential capabilities]
Nice-to-haves: [what could come later]
Existing systems and data: [what the project connects to or uses]
Constraints: [budget range, timing, rules, technology]
Decision maker and contact: [name and role]
A brief like this fits on one or two pages and can be written in an hour. It will save far more time than that once the project starts.
If you have a project in mind, feel free to send us your brief, even a rough one. We will reply with questions and a suggested first step.
