Writing a good product brief

The brief is not the PRD. It is not the roadmap item. It is the document that forces every meaningful decision about a product investment before a single line of code is written — and in most teams, it either doesn't exist or is so vague it might as well not. Here is what makes one actually work.

The most important document almost nobody writes well.

Product briefs that work are rare. Not rare as in sophisticated or technically complex — rare as in honest and specific. The typical brief is vague in exactly the places where specificity matters most: the problem statement, the success metric, and the scope boundary. It is precise in exactly the places where precision is cheap: the timeline, the stakeholders, the links to related tickets.

This is not accidental. Vagueness in a brief is a rational response to an uncomfortable environment. If you state your success metric precisely and miss it, you have demonstrably failed. If your success metric is "improve user satisfaction," you can never demonstrably fail — someone will always be able to argue that satisfaction improved in some dimension. Vagueness is survivable in a way that specificity is not. And so, over time, in teams where PMs are evaluated on whether things ship rather than whether things work, briefs drift toward comfortable ambiguity.

The result is that most of the critical product decisions — what problem are we actually solving, for which user, at what cost, and how will we know we've succeeded — get made implicitly, by engineers in standups and designers in Figma comments, rather than explicitly, by the people with the context to make them well. The brief exists, technically. But it never forced the decisions. It was approved in a meeting where everyone nodded, nobody disagreed, and the work began on the same foundation of shared misunderstanding it always had.

What a brief is for, specifically.

A brief has one job: to force every non-trivial decision about a product investment before a line of code is written. Not to document the decision after it's made. Not to summarise the discussions that happened in the sprint planning. To force the decisions. This is the distinction that matters, and it requires the brief to be written in a way that makes disagreement possible.

A brief that cannot be disagreed with has not done its job. If you circulate a brief and every stakeholder comes back with "looks good" or minor copy edits, the brief was too vague to generate useful friction. The right response to a good brief is substantive disagreement — about the problem framing, the metric, the scope, or the tradeoffs named in the brief. That friction, happening in comments on a doc rather than in production code reviews, is the most valuable thing the brief produces.

This reframes what you are doing when you write a brief. You are not producing documentation. You are creating the conditions for productive disagreement before the work starts. The brief is a structured argument — here is the problem, here is why it matters, here is what success looks like, here is what we will and will not build — and you are inviting your team to poke holes in it. The holes they find in the brief are far cheaper to patch than the holes they find three weeks into build.

The problem statement that actually narrows scope.

Most product brief problem statements follow a template like this: "Users are having trouble with [X]. This is causing [Y]. We need to [Z]." This looks like a problem statement. It isn't. It's a summary. A problem statement that narrows scope tells you, with enough specificity that you could run a test against it, what is broken for which user in which specific context and how you know it's broken.

The test: can I read this problem statement and confidently exclude a class of solutions? If the answer is no — if any solution in the universe is compatible with the problem as stated — the problem statement hasn't done its job.

Here is a weak problem statement: "New users struggle to activate. We want to improve the onboarding experience." Here is a strong one: "New users who sign up via paid search — who have no prior context about the product — complete less than 20% of the onboarding flow. Drop-off analysis shows 65% exit on the third screen, which requires them to connect an external data source before they've seen any product value. The problem is that we're asking for integration commitment before delivering a first moment of value." The second version tells you what to build and what not to build. The first version allows any onboarding-related work to qualify as a solution.

Writing a specific problem statement requires knowing things that most PMs don't have on day one: the specific drop-off data, the specific user segment, the specific friction point. This is by design. If you can't write a specific problem statement, you don't understand the problem well enough to brief a solution. The brief is exposing that gap, which is the honest and useful outcome. Go back to the data before you write the brief.

Success metrics that commit to something.

Success metrics are where briefs go to die with dignity. "Increase engagement" commits to nothing. "Improve the user experience" commits to nothing. "Reduce support tickets related to onboarding by 30% over sixty days post-ship, measured against a baseline of the average weekly ticket volume in Q1" commits to something specific. You can fail against it. That's the point.

Two things make a metric usable. First: it must be measurable by a named person using named instrumentation that exists or will exist before launch. If you are relying on a metric that engineering hasn't instrumented yet, either the instrumentation must be in scope for this initiative or the metric isn't usable. Companies regularly ship major features with no way to measure whether they worked. The brief should prevent this. Second: the metric must be owned. "The team will track this" is not ownership. "Product Analytics will produce a dashboard by launch date and share it in the sprint review" is ownership.

The secondary metric — the guardrail — matters as much as the primary metric and is almost always missing from briefs. A guardrail metric is the thing you are explicitly watching to make sure you don't make it worse while chasing the primary metric. If your primary metric is onboarding completion rate, your guardrail might be account activation latency — you don't want to improve completion by simplifying the flow in a way that increases the time between signup and first meaningful use. The guardrail forces you to think about the second-order effects of your own intervention before it ships.

The scope section that makes engineers trust you.

The scope section of a brief should do two things: define what is in scope and explicitly name what is not. The not-in-scope list is the more important of the two. It is also the one most briefs omit entirely, usually because the PM doesn't want to have the fight about why they're not building the adjacent thing that someone in the meeting cares about.

When engineers read a brief without an explicit not-in-scope list, they fill the gap themselves. They make assumptions about what the PM meant, which are usually wrong in interesting ways. The engineer who assumes "rebuild the onboarding flow" includes "fix the account settings page because it's broken and we're in that part of the code anyway" is not wrong to make that assumption — the brief didn't say otherwise. The PM who is surprised to find account settings in the scope review at week two wrote a scope section that deserved it.

The not-in-scope list should include things that someone in the room genuinely expected might be in scope. If everything on the list is obviously out of scope, the list isn't doing anything. "We will not rebuild the mobile app" is not useful not-in-scope. "We will not refactor the account settings page, even though it uses the same components and will be touched during this build" is useful. It names a real temptation and rules it out explicitly, which means the engineer who had that idea raises it in the brief review rather than in the code review.

• 01
  A brief that cannot be disagreed with hasn't done its job. If every stakeholder comes back with "looks good," the brief was too vague to generate useful friction. Write it specifically enough that a senior engineer or a designer can read it and push back on the problem framing or the metric. That friction in the brief is cheaper than the same friction in production.
• 02
  Your problem statement should be able to exclude solutions. Can you read your problem statement and confidently say "this rules out solution X"? If every solution in the universe is compatible with your problem statement, you haven't written a problem statement — you've written a category description. Get specific enough to narrow the solution space before you enter it.
• 03
  If you can't write the metric before you know the solution, you don't understand the problem yet. The metric should follow from the problem, not from the solution. "We'll measure whatever the feature we build can track" is backwards. Define what success looks like in user behaviour terms first. Then build the thing that produces that behaviour.
• 04
  Every brief needs a guardrail metric. The primary metric tells you if you succeeded. The guardrail tells you if you made something else worse in the process. If you're improving onboarding completion rate, what are you explicitly watching to make sure you haven't broken activation quality? Name it. Instrument it. Put it in the brief.
• 05
  The not-in-scope list should contain things someone in the room wanted to do. If everything you've ruled out is obviously out of scope, the list is decoration. Include the real adjacent temptations — the things an engineer might reasonably assume are in scope given where the work touches. Naming them explicitly saves the argument from happening in the code review.
• 06
  Get someone from the commercial side to review before lock. Briefs reviewed only by product and engineering solve the technically interesting version of a problem rather than the commercially meaningful one. Your account executive or customer success lead should be able to read the problem statement and say "yes, this is what our customers are calling us about." If they can't, you may be solving the wrong problem with great precision.

Frequently asked questions.