Concise replacement for (or, if you must, precursor to) a PRD. Conceived as the primary document a PM writes (but only after at least a synchronous kickoff!) to define a project. The big key is it focuses on the problem, not the solution.

Vijay Umapathy at Heap wrote a great post on product briefs. It includes Heap’s template, which is an expansion and evolution of my original template. While Heap’s is more rigorous, I personally prefer a simpler template:

Simple Product Brief Template

Context

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

What is this project? What’s the quick summary to orient the reader?

</aside>

Hypothesis

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

What problem(s) are we trying to solve? What need(s) are we trying to meet?

</aside>

Goals

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

As an organization, what are we trying to accomplish with this? Prioritize.

</aside>

Target User / Customer

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

Who experiences this problem or need? How do they currently address it? If they use other products as solutions, what does that competitive landscape look like?

</aside>

Use Cases

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

To the extent we’re going to build/test concrete functionality, what use cases does it break down into? Ensure use cases are framed around user needs and tasks, not functionality; and that they include both a “what” and a “why”.

Why is this worth doing?

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

What leads us to believe this is a good thing to prioritize? Where did this come from? That is, what makes us believe this is a real problem or need? What level of confidence do we have? And lastly, what does success look like here—how will we know we’ve succeeded?

Is this a hunch we’re playing? A common request we hear from Sales? A response to user research? None of those is bad or wrong; we just want to take stock.

</aside>

Why is this not worth doing?

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

Why might this not be a good use of resources? What are the risks? The trade-offs? Likely modes of failure?

</aside>

Evidence & Validation

<aside> <img src="/icons/info-alternate_lightgray.svg" alt="/icons/info-alternate_lightgray.svg" width="40px" />

What evidence do we have to support what we have here? What level of confidence does that give us? What’s missing?

</aside>