README: This is a template for a feature-level Product Requirements Doc. It is always a ‘draft’ and should be edited, added to, and kept alive. The purpose is to tell and document an evolving story.

This template isn’t designed for planning larger bodies of work (Epics and such), but could still be used as a starting point. This would also be overkill for smaller ‘just get it done’ type tasks. Sometimes it’s best to not overthink. Make sure to have some room for judgement and common sense in your process.

Process: PM writes a draft PRD, circulates to design and dev, they add comments, thoughts, and everyone gets to a shared understanding of the ‘thing’. PM updates the PRD and passes to Design. Design adds words, images, and probably things like Figma links in the document.

FRAMING.

Define the problem and convince ourselves it is worth solving.

Problem Definition.

Define the problem and convince ourselves it is worth solving.

[articulate problem statement here.]
Why does this problem exist in the first place?

Job-To-Be-Done

Restate the problem as a JTBD.

…this helps clarify the solution concept

Personas.

Who is hurting.

…primary user or customer? what segment?
...who else could benefit?
…who might be not like this?

Why is this worth solving?

By far the most important question. Absolutely must have quantitative and qualitative evidence here. If you don’t go get some and come back.

...what evidence (research, data, feedback) is informing this work?
...is this a direct lever on an OKR?
…how is this helping the user?

Metrics.

What metric will move?

...how are we measuring success
Internal metric X
Customer Value metric Y

Non-goals

...what is not in scope. What problems are we ignoring for now.

BUILDING.

What’s the most straightforward way to solve this?

Solution Concept

Scope overview.

Describe the approach
Drop in any sketches or wireframes

Workflow

...narrate the user journey
Link to any schematics or boards (e.g. Miro)

Key Requirements + Stories

Articulate functional and non-functional requirements. Tell the story.

MUST-HAVES:

[as a human, I want to do x, so that I can y]

NICE-TO-HAVES:

[as a human, I want to do x, so that I can y]

ANALYTICS:

…define any new attributes or events for tracking

Risks.

What are the potential threats to achieving success? Are there external or legal risks to consider?

Out-of-Scope.

These things have been considered and excluded:
1. …
These things have been considered and planned for later:
1. …

Design

Notes:

…

Figma (or Mockups)

Insert images or better a Figma link here.

Engineering

Notes:

…

Release Planning:

…reference release data and version

Testing:

…reference any A/B test groups and similar info

Review Log

If you have read this document, let it be known!

@Scott Janicek