PRDs#
An engineering lens
A PRD is primarily a product document, written by a product manager. However, they are useful for engineers to have some basic understanding of. This is not meant to be a comprehensive guide, but rather a basic overview for engineers.
What are PRDs?#
Product Requirement Documents (PRDs) are a way to define the scope of a problem and the needs to address it. It allows product managers, stakeholders, and engineers to understand what is being built and why.
How are Design Docs related?
If a PRD is the what and the why, a Design Doc is the how. A design doc should always follow a PRD.
Why write PRDs?#
By clearly laying out the boundaries of a problem and the needs to address it, you can ensure that everyone is on the same page. This in turn will reduce friction and misunderstandings, as it will all be written down and agreed upon. It will also help you avoid building towards the wrong solution.
The main driver of PRDs should usually be a Product Manager, but they can be written by anyone who has a good understanding of the problem and the needs of the users. Gergely Orosz recommends that engineers write a PRD at some point in their careers,1 because it can help you "build more empathy with what product work is like" and help you build a stronger product sense.2
In my experience, I have found that writing a PRD can help me think through the problem more thoroughly, without the bias of a technical architecture in mind. I have found that sometimes engineers can be biased to build what they want, rather than what the users want. A PRD can fix that misalignment.
Structure of a PRD#
PRDs can vary in structure, there are a lot of templates out there that you can use.34 You do not need to follow a template exactly, Aakash Gupta even suggests ditching a template in favor of a checklist.56
In general though, a PRD will contain the following elements:
- Background / context
- Problem statement
- User stories
- Goals / Requirements
- Phases / Milestones
This is a very high level overview, and you can find more detailed templates in the links above. My personal preference is to follow Hashicorp's template,7 as their example is very helpful and has covered most of my needs. It also pairs very well if you follow with their design doc.8
When should you write PRDs?#
PRDs should mainly be reserved for larger bodies of work, or when you are unsure of the problem space. For small improvements, or when the problem is well understood, a PRD might not be necessary at all.
PRDs can be very long and some people find them tedious to write.9 I am not suggesting that you should write a true long form PRD. Instead, a 1-2 page document that covers the basics is usually enough to fulfill the goal of a PRD. At minimum, this will help you think through the problem and get all the benefits of writing a PRD, without killing your motivation to start the project.