Product Brief V2 Template for Product Planning

A product brief defines the problem, hypothesis, and success criteria. A [PRD](/templates/prd-template) defines the solution in detail (user stories, requirements, wireframes, technical approach). The brief comes first and earns the "go" decision. The PRD comes second and guides implementation. Think of the brief as the "what and why" document and the PRD as the "how" document. For smaller features that do not warrant a full PRD, see the [Feature Brief Template](/templates/feature-brief-template).

At minimum: the product lead (strategic alignment), the engineering lead (feasibility and resource availability), and one business stakeholder (revenue or growth impact). In larger organizations, add the design lead if the initiative has significant UX implications. Keep the approval group small. More than 5 approvers creates a bottleneck. The [stakeholder management framework](/glossary/stakeholder-management) in the glossary covers strategies for managing input without creating decision paralysis.

One to two pages. If your brief exceeds two pages, you are either describing the solution (save that for the PRD) or you have not distilled the problem clearly enough. The "Why Not" section should be 3-5 sentences, not a full risk analysis. Brevity forces clarity.

That is a success, not a failure. The brief documents what you expected to learn and what you would do if the hypothesis was wrong. Follow through on that plan. Kill the feature, pivot the approach, or run a deeper investigation. Hypothesis-driven briefs make it safe to shut down initiatives that are not working because the decision criteria were agreed upon in advance. ---