Product Brief Template
A concise product brief template that aligns stakeholders before a PRD is written. Covers problem, opportunity, proposed solution, constraints, and open questions. Free to copy, download, and use. No signup required.
# Product Brief **Title:** [Feature / Initiative Name] **Author:** [PM Name] **Date:** [Date] **Status:** Draft / Shared for Review / Approved > A product brief is a 1-page alignment document written *before* a PRD. Its purpose is to get stakeholder agreement on the problem and direction — not to specify requirements. --- ## Problem > What problem are we solving and for whom? [2–4 sentences. Be specific about the user, the friction, and the frequency. Avoid jumping to solutions here.] **Evidence this problem is real:** - [Customer quote, support ticket volume, survey data, or sales call insight] - [Data point: "X% of users drop off at Y step"] --- ## Opportunity **Who experiences this problem:** [User segment — be specific] **How many users:** [Rough count or % of user base] **Frequency:** [How often they hit this problem] **Current workaround:** [What they do today — manual, competitor, nothing] **Business opportunity:** - [Revenue impact, retention impact, or activation improvement if solved] --- ## Proposed Direction > Not a spec — a direction. Engineering will shape the solution. [3–5 sentences describing the approach we're considering and why. What we build, what we don't, and the key design bet we're making.] **Key assumption we're making:** [The belief that must be true for this direction to work] --- ## Goals - [ ] [Primary user outcome] - [ ] [Business metric we expect to move] ## Non-Goals - [What we are explicitly not doing in this initiative] - [Adjacent problem we are not solving here] --- ## Constraints | Constraint | Detail | |---|---| | Timeline | [Hard deadline, if any] | | Engineering | [Estimated size or team capacity] | | Dependencies | [Teams or systems we depend on] | | Regulatory | [Compliance or legal constraint, if any] | --- ## Open Questions - [ ] [Question that must be answered before we can write a PRD] - [ ] [Risk or unknown that needs validation] --- ## Proposed Next Steps - [ ] [Stakeholder review by: date] - [ ] [Discovery spike or prototype by: date] - [ ] [PRD draft by: date] --- ## Stakeholder Sign-off | Role | Name | Status | |---|---|---| | Engineering Lead | [Name] | Pending / Approved | | Design | [Name] | Pending / Approved | | Data / Analytics | [Name] | Pending / Approved | | Leadership | [Name] | Pending / Approved |
How to use this Product Brief template
Write the brief before the PRD
The brief's job is to build alignment on the problem before anyone spends time specifying a solution. If stakeholders disagree on whether the problem is worth solving, discovering that in a 1-page brief saves weeks of PRD work.
Keep it to one page
A brief that exceeds two pages has become a PRD. If you're writing detailed requirements, stop — you've moved past alignment and into specification. Push detailed requirements to a separate PRD once the brief is approved.
Lead with evidence, not opinions
The 'Evidence this problem is real' section is the most important part. Stakeholders who see a customer quote and a data point are far more likely to approve a direction than stakeholders who hear 'I think users want this.'
List your open questions explicitly
Open questions signal intellectual honesty and prevent you from being held accountable for decisions that haven't been made yet. Every question in this section should have an owner and a resolution path.
Want a Product Brief grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
What's the difference between a product brief and a PRD?
A product brief (also called a one-pager or product spec) answers 'what problem are we solving and why?' — it's an alignment document. A PRD answers 'what exactly should we build?' — it's a specification document. Write the brief first, get agreement, then write the PRD. Many teams skip the brief and start with the PRD, which leads to expensive late-stage disagreements about scope.
Who should review the product brief?
At minimum: the engineering lead, design lead, and whoever owns the product metric you're trying to move. For features that touch pricing, legal, or compliance, include those stakeholders early. The goal is to surface disagreements before they become PRD debates.
How long should it take to write a product brief?
2–4 hours for a well-defined problem. If it's taking longer, the problem is not yet clearly understood — which is exactly the signal you need before writing requirements. Use the brief's open questions section to park unresolved questions and move forward.
Do I need a brief for every feature?
No. For small, well-understood improvements (under a week of work, single team), a ticket with acceptance criteria is enough. Reserve the brief format for new capabilities, cross-team initiatives, or anything with ambiguity about whether the problem is worth solving.
Other free templates