How to Write a Product Brief for a New Feature Initiative: Template and Examples

How to write a product brief for a new feature initiative requires answering four questions before any solution is proposed: who has the problem, why does it matter to the business, what does success look like, and what constraints bound the solution space — because a brief without these four elements is not a brief, it is a solution looking for a justification.

A product brief is not a PRD. A PRD specifies what will be built. A brief specifies what problem will be solved and why, leaving the solution open for engineering and design to shape. Teams that confuse the two skip discovery and build the wrong thing efficiently.

What a Product Brief Is (and Is Not)

| Document | Answers | When to write | |---------|---------|--------------| | Product brief | What problem, for whom, why now, what does success look like | Before design begins | | PRD / spec | What exactly will be built, how it works | After design sprint or prototype | | Technical spec | How engineering will implement it | After spec approval |

The brief is the earliest commitment — to a problem, not a solution. Writing it forces the PM to validate that the problem is real, measurable, and worth solving before engineering commits any capacity.

The Product Brief Template

Section 1: Problem Statement (1 paragraph)

Format: "[Specific user] struggles with [specific problem] because [root cause]. This results in [specific negative outcome] and creates [business impact]."

What makes a good problem statement:

Names a specific user, not a category ("Head of RevOps at a Series B SaaS company," not "enterprise users")
Names a specific problem, not a theme ("cannot reconcile CRM data without a 2-hour manual process," not "data quality issues")
Quantifies the negative outcome when possible ("spends 8 hours per week," "loses 15% of users at this step")

Section 2: Evidence Base (bullet list)

The evidence that this problem is real and affects enough users to be worth solving:

User research (number of interviews, key quotes)
Quantitative signal (support ticket volume, funnel drop-off rate, NPS mentions)
Market signal (competitive feature, win/loss mention)

H3: The Evidence Threshold

According to Lenny Rachitsky's writing on product brief quality, a brief without an evidence base is a feature request dressed up as a problem statement. "The question I always ask when reviewing a brief is: how do we know this problem is real? A quote from one customer doesn't clear the bar. Three customer interviews with the same pattern plus a quantitative signal does."

Section 3: Why Now (1 paragraph)

Why is this problem worth solving now rather than later? Common reasons:

Competitive gap (competitor just shipped a similar feature)
Quantitative signal that has changed (metric just started declining)
Strategic dependency (this blocks a higher-priority initiative)
Customer commitment (sales has promised this to a key account)

If "why now" is weak, the brief should be parked until the urgency is real.

Section 4: Success Metrics (2–3 metrics)

What specific, measurable outcomes will confirm that the solution worked?

The success metric format:

Primary metric: The single number that matters most
Leading indicator: The metric that will move first and confirm we're on the right track
Counter-metric: The metric that should not regress (to prevent one-sided optimization)

Example:

Primary: 30-day retention for users who experience the new feature (+10% from baseline)
Leading indicator: Time-to-first-workflow-completion (<10 minutes from activation)
Counter-metric: Support ticket volume for this user journey (should not increase)

Section 5: Constraints (bullet list)

What bounds the solution space?

Timeline constraint: "Must ship before [date] because [reason]"
Technical constraint: "Cannot require database migration due to [reason]"
Resource constraint: "Engineering capacity capped at 3 sprints"
Regulatory constraint: "Must comply with [regulation]"
Out of scope: "This brief does not cover [adjacent problem] — will address in a separate initiative"

Section 6: Open Questions

What do we still need to learn before design begins?

"Does the problem affect power users differently than casual users?"
"What is the competitive feature's UX model?"
"Can we instrument the current behavior to baseline the metric?"

H3: The "No Solutions" Rule

According to Shreyas Doshi on Lenny's Podcast, the most important discipline in writing a product brief is explicitly forbidding solutions in the document. "The moment you put a wireframe or a feature description in a brief, you've ended the discovery process. The brief should be so focused on the problem that an engineer can read it and come up with a completely different solution than the PM imagined — and that solution might be better."

Review the brief before sharing: any sentence that starts with "the feature will" or "users will be able to" is a solution and belongs in the PRD, not the brief.

Brief Review and Sign-Off

The brief should be reviewed by:

Engineering lead: confirms technical constraints are accurate and adds any constraints the PM missed
Design lead: confirms the problem is actionable for design and adds any UX research needs
Product leadership: confirms this problem is aligned with the roadmap strategy

Sign-off means: "This problem is real, the evidence supports it, and we're committing to solve it in a future sprint." It does not mean approving a solution.

According to Gibson Biddle on Lenny's Podcast, the product review process he ran at Netflix required every major initiative to pass a brief review before any design or engineering resources were allocated. "The brief review caught 30 percent of initiatives that had weak evidence or unclear success metrics. That 30 percent represents resources that went to better problems instead."

FAQ

Q: How do you write a product brief for a new feature initiative? A: Answer four questions before proposing any solution: who has the problem, why does it matter to the business, what does success look like, and what constraints bound the solution space. Keep solutions out of the brief.

Q: What is the difference between a product brief and a PRD? A: A product brief specifies the problem to be solved and why, leaving the solution open. A PRD specifies what exactly will be built. Write the brief before design begins; write the PRD after the design direction is validated.

Q: What should a product brief include? A: A problem statement with a specific user and quantified impact, an evidence base showing the problem is real, a why-now rationale, 2-3 success metrics with a primary, leading indicator, and counter-metric, constraints on the solution, and open questions.

Q: Why should a product brief not include solutions? A: Including solutions in the brief ends discovery. The brief should be focused enough on the problem that engineering can propose solutions the PM didn't imagine — which are often better. Solutions belong in the PRD after the design process.

Q: How long should a product brief be? A: One to two pages. If it exceeds two pages, the problem statement is probably describing a solution or the scope is too broad. A brief that cannot fit on one page is usually a PRD in disguise.