How to write a product brief for a digital agency

A bad brief costs more time than no brief at all. That sounds counterintuitive, but at Livewall we see it regularly: a document full of assumptions and vague goals that sends a team in the wrong direction for three weeks. Then the whole process restarts.

A good product brief is not a functional specification. It is not a feature list. It is a clear articulation of the problem you want to solve, for whom, and what success looks like. The more specific you are about the problem and the desired outcome, the more room you give a digital agency to find the best solution.

This article walks through how to write a brief that actually works, what to include, and what to leave out.

Start with the problem, not the solution

The most common mistake in a product brief: the client describes a solution before the problem is clear. 'We want to build an app where users can do X' is not a problem statement. It is an assumption.

Start with the situation instead. What is happening now? What is not working? Who is experiencing that problem, and in what context? How do you know this is actually a problem and not just an internal assumption?

A good problem statement sounds like this: 'New employees start without context about their role or their team. That leads to higher dropout in the first month and more pressure on managers.' From that description, a digital product agency like Livewall can propose relevant solutions. Sometimes that is a preboarding tool. Sometimes it is something else entirely.

Describe your audience precisely

Not 'consumers aged 25 to 45'. Describe the people you are building for as concretely as possible. What device do they use? When and why do they interact with the product? What do they already know, and what do they expect?

For the Sportvisunie platform, the audience was very specific: anglers who wanted to share knowledge and connect local clubs online. That shaped every UX decision. Generic personas are not enough. Concrete behavioral descriptions are.

Define success in measurable terms

What is the desired outcome of this digital product? Be as concrete as possible. 'More engagement' is not a goal. 'Return visits within seven days of first session' is.

Good success criteria are:

• Behavioural: what do users do when the product is working well?
• Measurable: can we track this after launch?
• Realistic: based on an assumption we can test

It also helps to describe what failure looks like. If users drop off after one visit, or if the time to complete task X is longer than Y seconds, the product is not working. These anti-criteria are just as valuable as the positive KPIs.

Describe the technical context

A digital product agency cannot estimate scope without knowing what systems the product needs to connect with. Describe the existing stack: which CMS, CRM, or other system does the new product need to integrate with? Are there constraints around hosting, security, or authentication?

This does not need to be a technical document. A sentence like 'the product needs to connect to our Salesforce CRM and support Single Sign-On via Azure AD' already provides enormous context. It prevents surprises mid-project.

In the KLM scalable growth case, integration with existing systems across 50+ markets was a defining factor in architecture decisions. That kind of context belongs in the brief, not surfacing for the first time in week four of the engagement.

Budget and timeline: be honest

Many clients deliberately keep their budget vague, hoping to get a lower price. That backfires. An agency that does not know the budget might design a solution twice as expensive as what you can afford, or too simple for what you actually need.

Share a range. 'We are thinking of an initial investment between €40,000 and €70,000' gives a digital agency enough room to propose a fitting approach. Without that frame, every proposal is a guess.

The same applies to timeline. Is there a hard deadline, such as an event or a seasonal launch? Is there room to build iteratively? When do you want to go live with a first version? The earlier you share this, the better an agency can structure the plan.

What to leave out of the brief

A product brief is not a functional specification. The following things do not belong in it:

• Wireframes or screen sketches that already lock in a solution
• Technical specifications that have not yet been confirmed
• Long summaries of internal discussions and stakeholder opinions
• Wish-list items from stakeholders that do not connect to the primary goal

The shorter and clearer the brief, the better. Five pages covering the problem, the audience, the success criteria, the technical context, and the budget work better than twenty pages of background reading.

A checklist before you send

Before you send the brief, work through these questions:

Problem statement

• Is the problem described from the user's perspective, not a desired feature?
• Do we have evidence this problem actually exists?

Audience

• Is the audience concrete enough to base UX decisions on?
• Are there multiple user types with different needs?

Success

• Are the success criteria measurable and behavioural?
• Have we described what failure looks like as well?

Technical context

• Are all relevant system integrations named?
• Are there constraints around hosting, security, or authentication?

Constraints

• Is a budget range included?
• Is the desired timeline and any hard deadline clear?

If you have solid answers to all of these, the brief is ready. Not before.