PRD template
Below is the template I use for most of my Product Requirement Documents (PRD, or just product spec)
PRD: ___[product/feature name]_____
@yourslackhandle | Updated mm/dd/yy
Summary
Frame the problem that you trying to solve. More importantly, explain why it is worth addressing. Be specific, and provide metrics.
~3 bullet summary of what we want to do, 2-3 lines per bullet. Use bold to organize
Insight: What’s the qualitative/quantitative insight?
Hypothesis: [Product change] will cause [impact] for [population]
Goals
Promise clear deliverables and outcomes. Identify what’s out of scope. Make sure it’s easy to look at each goal and answer: did we hit it?
Usually aligned with KRs: “Grow MAP”
Out of scope
Useful for setting expectations and eliminating bad assumptions
Background
~1 paragraph about why is this important, what data do you have to back it up. Provide evidence that your audience needs to understand the problem and believe in your proposal. Assumptions, use-cases, metrics, etc.
Use Cases
Users want to:
abc
X wants to:
abc
Assumptions
abc
Proposal/Requirements
Your proposal should be detailed enough for your team to consume and execute — think of it like code for human brains to run. Add necessary subsections, figure out the best way to organize, and keep it short and concise.
Work hard on images - Like flow diagrams, or wireframes. They can convey huge amounts of info in an easily digestible manner, but can also take lots of time to make.
List/flow - specify what the behavior of the feature should be from the perspective of the user’s experience. Stay away from implementation details
Think about different edge cases - new vs. existing users, venues, scheduled rides, different ride modes, international, error states (connectivity), transitions
Experiment Design
50/50 split, ramp from 1% to 10% to 100%
Success metrics:
Failure metrics:
Metrics and Reports
Logging:
New reports:
Future Work
If we see xyz:
If the test succeeds:
Timeline
List dates and milestones that your team believes in. This section may start off vague, but should be finalized in your last spec review.
This timeline may slip by 1-2 weeks due to the kinds of issues mentioned in “future work”. That’s ok as long as we have results by xyz
Aug 26-29: spec review
Sep 4: Project kickoff
Sep 9-14: Tech spec
Sep 16: Start build
Oct 21: test on dev env
Mon Nov 4: submit build
Wed Nov 20 (drop dead experiment launch date): launch on prod
Dec 2: sync after 1 week. We may have additional tasks then.
Dec 18: final sync to review stats and decide if we want to do more or kill it.
Dec 30: this is the hard date for having the project wrapped up and results on hand.
People
Person 1: role
Person 2: role
Premortem
Imagine this project has failed - working backwards, what do you think was the most likely cause of failure? This can be done for various scenarios - project turned out well, turned out bad, turned out weird.
[your name]:
Good outcome:
Bad outcome:
Weird outcome:
[person]:
Good outcome:
Bad outcome:
Weird outcome:
Open Questions
Open-ended questions to be addressed w/ team