Product Brief V2 Template

What This Template Is For

A product brief is the document you write before committing resources to a new initiative. It answers four questions: What problem are we solving? Why now? How will we know if we succeeded? What constraints should the team work within?

This V2 format updates the traditional product brief with three changes. First, it is hypothesis-driven: instead of stating "we will build X," it frames the work as "we believe that building X will produce Y outcome." This keeps the team focused on the outcome, not the output. Second, it includes an explicit "Why Not" section that forces you to articulate the strongest argument against the initiative. Third, it separates the brief from the solution spec. The brief defines the problem and success criteria. The solution spec (written later, often as a PRD or Feature Specification) defines how to solve it.

Use this template at the beginning of the product development lifecycle, before design exploration or technical scoping. It is the artifact that gets reviewed in a product review meeting and earns a "go" or "no-go" decision from leadership.

For scoring and comparing multiple initiative briefs, use the RICE Calculator. For the broader strategic context that briefs should connect to, see the Product Strategy Handbook.

How to Use This Template

1. Write the problem statement from the user's perspective. Ground it in evidence: user research, support data, analytics, competitive analysis. Avoid describing the solution in this section.
2. State the hypothesis clearly. "We believe that [action] will result in [outcome] for [audience], as measured by [metric]." One hypothesis per brief. If you have multiple hypotheses, write multiple briefs.
3. Define success metrics with baselines and targets. If you cannot measure the outcome, the hypothesis is not testable and the brief is not ready.
4. Write the "Why Not" section honestly. What is the strongest argument against doing this? What could go wrong? What are you giving up by prioritizing this over alternatives? This section builds credibility with skeptical stakeholders.
5. List constraints, not requirements. Constraints define the boundaries the solution must operate within (budget, timeline, technical limitations, regulatory requirements). Requirements belong in the solution spec.
6. Get sign-off from your product lead, engineering lead, and one business stakeholder before proceeding to solution design.

The Template

Product Brief

Problem

[3-5 sentences describing the problem from the user's or business's perspective. Do not describe the solution here. Be specific about who has this problem, how severe it is, and how frequently it occurs.]

Evidence.

Who is affected.

• Primary audience. [Specific user segment, size estimate]
• Secondary audience. [Adjacent segment that benefits]
• Not affected. [Segments explicitly not targeted by this initiative]

Opportunity

[2-3 sentences on the business opportunity. Revenue potential, retention impact, competitive positioning, or market expansion. Use numbers where possible.]

Market context. [1-2 sentences on timing. Why now? What has changed in the market, competitive set, or customer expectations that makes this urgent?]

Hypothesis

We believe that [action/change we will make]

will result in [expected outcome]

for [target audience]

as measured by [primary metric].

If this hypothesis is wrong, we will learn [what the failure teaches us and what we would do instead].

Success Metrics

Primary metric. The single metric that determines whether the hypothesis was validated.

Secondary metrics. Supporting indicators that provide context for the primary metric.

Guardrail metrics. Metrics that must not degrade. If a guardrail is breached, pause and investigate before continuing.

Why Not

[This is the most important section of the brief. Write 3-5 sentences making the strongest possible case AGAINST this initiative. Include:]

• Opportunity cost. What are we NOT doing by pursuing this? Which other initiative loses resources?
• Risk. What is the worst realistic outcome if this fails?
• Counterargument. What would a smart skeptic say about this initiative?
• Alternative. Is there a cheaper or faster way to test this hypothesis without building the full solution?

Mitigation. [1-2 sentences on why the case FOR the initiative outweighs the "Why Not" arguments.]

Constraints

Solution Direction (optional)

[If you have a rough solution direction, describe it in 2-3 sentences. This is NOT a spec. It is a directional signal for the team. If you do not have a direction yet, write "To be explored in design phase."]

Stakeholder Sign-Off

Decision notes. [Record any conditions, modifications, or feedback from the sign-off meeting.]

Next Steps (after approval)

• ☐ Assign PM and engineering lead
• ☐ Conduct design exploration (1-2 weeks)
• ☐ Write solution spec (PRD or Feature Spec)
• ☐ Technical scoping and architecture review
• ☐ Sprint planning and kickoff

Filled Example: Self-Serve Team Analytics Dashboard

Product Brief

Problem

Team leads and engineering managers at mid-market and enterprise customers cannot answer basic questions about their team's productivity without exporting data to spreadsheets and building manual charts. Questions like "How many tasks did the team close last sprint?" or "Which projects are behind schedule?" require 30-60 minutes of manual data work. 67% of enterprise trial users cite "lack of reporting" as a reason for not converting. Support handles 25+ requests per month for custom data pulls that could be self-served.

Evidence.

Hypothesis

We believe that adding a self-serve analytics dashboard with team velocity, project status, and workload distribution charts

will result in a 15-point increase in enterprise trial-to-paid conversion rate

for team leads and engineering managers at companies with 20+ users

as measured by enterprise plan conversion rate (currently 23%, target 38%).

Why Not

The strongest argument against this initiative is that reporting features are table stakes, not differentiators. Building a dashboard that matches Asana and Linear will not give us a competitive advantage; it just removes a disadvantage. The 8 weeks of engineering could instead be spent on our unique workflow automation features, which no competitor matches. Additionally, our data model may not support the query patterns needed for real-time dashboards without significant backend work, turning an 8-week project into a 12-week one.

Mitigation. While reporting is table stakes, the 67% trial conversion blocker makes this a revenue gate. We cannot sell into the enterprise segment without it. The investment pays for itself if conversion improves by even 5 points (worth ~$180K ARR based on current pipeline).

Key Takeaways

• Frame every initiative as a testable hypothesis with a specific primary metric
• Write the "Why Not" section honestly to build credibility with skeptical stakeholders
• Separate the brief (problem + success criteria) from the solution spec (how to build it)
• Keep the brief to 1-2 pages and the approval group to 3-5 people
• Define guardrail metrics that must not degrade alongside your target metrics

About This Template

Created by: Tim Adair

Last Updated: 3/5/2026

Version: 1.0.0

License: Free for personal and commercial use