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:
<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>
<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>
<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>
<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>
<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”.
<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>
<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>
<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>