What is a Product Brief?
A product brief is a short document that captures the essential context for a product initiative: what problem are we solving, for whom, why now, how we will measure success, and what constraints exist. It is written before detailed design or engineering work begins.
Think of the product brief as the minimum alignment document. It ensures everyone, from the engineer to the VP, shares the same understanding of why this initiative matters and what success looks like.
Why Product Briefs Matter
Teams that skip the brief phase often discover misalignment late. The PM thinks they are building a retention feature; the VP thinks it is a growth feature; engineering thinks it is a tech debt initiative. The brief surfaces these disagreements early when they are cheap to resolve.
Briefs also prevent scope creep by establishing boundaries upfront. When someone suggests adding a feature mid-project, you can check it against the brief: does this serve the stated problem and goals?
How to Write a Product Brief
Keep it to 1-2 pages. A brief that requires 30 minutes to read is not brief. Include these sections:
Problem statement: What user or business problem are you solving? Include evidence (data, quotes, support tickets) that the problem is real.
Target user: Who specifically has this problem? Be precise. "All users" is not a target.
Goals and success metrics: What will change if this succeeds? Define 2-3 measurable outcomes.
Constraints: Timeline, technical limitations, regulatory requirements, or dependencies.
What we are NOT doing: Explicitly list things that are out of scope. This prevents scope creep.
Product Briefs in Practice
Amazon's one-page briefs (called "narratives") are famously read in silence at the start of every meeting. The format forces clarity. If you cannot explain the initiative in one page, you do not understand it well enough.
At Stripe, product briefs include a "pre-mortem" section: "Imagine this initiative failed. What went wrong?" This forces the PM to think about risks upfront and address them in the plan.
Common Pitfalls
- Too detailed. The brief is not a PRD. Save feature specs for later. Focus on the why and the what, not the how.
- No success metrics. A brief without measurable goals gives the team no way to know if they succeeded.
- Writing in isolation. Get input from engineering and design before finalizing. They will catch assumptions you missed.
- Skipping the brief. "We already know what to build" is the most expensive assumption in product management.
Related Concepts
Product briefs lead into product discovery and eventually PRDs. They are informed by product strategy and problem statements. For the structured approach to defining work, see user stories and product specs.