Author: Cyrus
Status: Complete
- Driver: [Fill in the blank]
- Approver: [Fill in the blank]
- Contributors: [Fill in the blank]
- Informed: [Fill in as necessary]
Motivation for writing a PRD
As teams grow, it’s no longer efficient for everyone involved in a project
to meet and share updates as they happen in real-time.
And as organizational structure forms,
teams need help to stay on task,
to avoid the temptations of scope creep,
and to curb conflict arising from uncertainty about who is in charge.
The main purpose of a PRD is to explain why a particular project is important
and to define what needs to be built (not how).
By explaining the motivation behind a project, team members can better reason
about how to make decisions when they are presented with new information.
More than anything a PRD should be a document that can be referred to whenever
there’s disagreement on the best way to move forward.
Requirements for an upcoming PRD
- Document the Driver, Approver, Contributors, and Informed (DACI) for the project
or another comparable scheme for defining who needs to be privy to what and who will settle disputes.
Once agreed upon, be sure to get feedback from everyone who will
be involved about the specific requirements that will need to be met.
- Outline the business rationale for devoting valuable human resources to a project.
Strike a balance between being explicit and concise.
This should be an easy document to refer back to that should be intelligible
to everyone regardless of technical expertise.
- Specify an estimated time of delivery with an understanding that this may change
as the team digs into implementation details.
Defining success for a PRD
- Team members have read the PRD and know where to find it.
- Minimize the number of misunderstandings about what’s required before releasing to production.
And as appropriate, engineering, design, marketing, customer success, and sales should
know what they are responsible for delivering.
- Qualitatively ensure that team is on the same page about what needs to be done.
- Release on schedule.
Assumptions
- The process of putting together a PRD will help the team come to a healthy compromise on
the minimum scope necessary for meaningful progress.
- Once each person’s role has been established for a project, it won’t change unless there
are extenuating circumstances.
- Metrics for success will not change unless they’re found to not correlate with the
right behavior, in which case what is being measured should change, not the target.
The fact that a metric is difficult to achieve is not grounds for an
adjustment.
Current plan for execution
- Milestone #0: Driver asks Contributors to contribute to a first draft of the PRD
- Make tasks in Asana
- File tickets on Github and/or Jira with links to the associated Asana tasks
- Put project on the marketing Trello board
- Slack the team to check their task management tools on a dedicated slack channel
- Milestone #1: Driver circulates the PRD to inform Informed
- Ensure Informed have access to the Google Doc with default access to
Suggest
- Driver organizes a meeting to explain / read the PRD to Informed
- Milestone #2: Driver seeks approval from the Approver
- Confirm that Approver acknowledges and understands what is being approved
Dependencies
- Setting up interviews with customers to understand their expectations.
- Estimates on how long implementation will take once the scope has been defined.
- Budget approval for any work to be done by outside contractors.
Acronym Definition
PRD
= Product Requirements Document
I realize this is a little meta, but I thought it’d be interesting to write
a PRD for writing a PRD.