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