Concise equivalent of a PRD. Conceived as the primary document a PM writes (but doesn’t write until after at least a synchronous kickoff!) to define a project. The big key is that it focuses on the problem, not the solution.
Vijay at Heap wrote a great post describing the what and why here, from which you can download Heap’s template. (Heap’s template might go a little overboard on the detailed justification for my tastes, but the list of justifications is worth perusing).
Or if you’re not feeling quite that rigorous, here’s a much simpler template:
- What problem are we trying to solve / what need are we trying to meet? Or put another way, what’s our hypothesis?
- Whose problem or need it is? How do they deal with it today? If they handle it via other products, what’s that landscape?
- 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?
- 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.
- What level / type of thing do we need to do to test our hypothesis here? Are we building a feature? User-testing a prototype? Running a painted-door test?
- 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”.
- Yes: “As a user, I’d like a quick way to send my location to friends so it’s easy to meet up.”
- No: “As a user, I’d like a quick way to send my location to friends.” ← Missing the “why”
- No: “As a user, I’d like a button to share my live location for 15m in one click.” ← Specifies functionality, not a need.
(And check out this product brief from Miter that’s based on something similar.)
While I’ve historically done these as standalone docs, one additional benefit to their brief-ness is they could sit inside a Jira / Linear ticket or Productboard feature.