The most expensive moment in any product build isn't when the code breaks. It's the moment three months in when someone asks "wait, is that what we were actually trying to solve?" and the answer is unclear.
Most teams start building before the problem is defined. Not because they're careless — because defining the problem properly is uncomfortable. It means saying no to things, admitting you don't know things, and aligning across people who have different ideas of what success looks like. Writing a product brief forces all of that into the open before a line of code is written.
It's not a spec. It's not a PRD. It's a single-page document that establishes shared understanding of the problem before the team starts building.
What a product brief actually needs to contain
Five sections. No more. If it doesn't fit on one page, you don't understand the problem yet.
1. The problem statement — specific, not vague. "Users find it difficult to complete checkout" is not a problem statement. "35% of users who reach the payment screen on mobile abandon before completing — primarily on the card entry step" is a problem statement. It's specific enough that a developer, a designer, and a product manager can all look at it and agree on what's being solved.
2. Who it's for. Not "all users." Not "our customers." A specific user in a specific context with a specific need. The brief should describe one person making one decision. If you need to describe multiple users, write multiple briefs — or question whether you're actually solving a problem or building a platform.
3. What success looks like — and how you'll know. A measurable outcome. Not "better user experience" — "reduce cart abandonment on the payment screen from 35% to under 20% within 90 days of launch." If you can't write a specific number, you haven't decided what you're optimising for. This is where most briefs die. Everyone agrees on the problem but nobody agrees on success.
4. What's out of scope. This is the most underrated section of any brief. Listing what you're not solving protects the team from scope creep and protects the product from trying to be everything. Every feature request that comes in during development can be evaluated against a simple question: is this in scope? If the brief doesn't define the boundary, the boundary doesn't exist.
5. The constraint that matters most. Time, quality, or resources — you get to optimise for one. Be explicit about it. A team building to a hard deadline makes different decisions than a team building to a quality standard. Both are valid. Pretending the constraint doesn't exist produces a product that fails on all three dimensions.
If you can't explain the brief in one page, you don't understand the problem yet.
Why most teams skip it
The honest reason is that writing a brief feels like slowing down. Teams are excited. There's pressure to ship. Someone's already started designing. The brief feels like admin.
But the brief isn't slowing you down — it's front-loading the alignment conversation that will happen anyway. The only question is whether it happens in a focused one-hour session before development starts, or in a series of painful meetings while development is underway.
I've watched teams spend three months building something, do a demo for the leadership team, and then spend the next three months rebuilding it because the brief was never written and the assumptions were never surfaced. The brief would have taken a day.
The brief often reveals you don't need to build what you thought
This is the thing nobody tells you about writing a good brief: it regularly surfaces that the proposed solution isn't the right one. When you force a clear problem statement, a specific user, and a measurable success metric into the same document, the solution that seemed obvious sometimes stops looking obvious.
I've been in brief-writing sessions where the planned six-week build became a one-week config change. I've been in sessions where the brief revealed a different problem entirely — one that was actually worth solving. And I've been in sessions where writing the brief made clear that the problem wasn't big enough to justify building anything at all.
All of those are wins. Each one is cheaper than finding out the same thing after you've shipped.
Write the brief. One page. Five sections. Before you open Figma.
