A product requirements document (PRD) outlines the requirements for a product feature.
It’s an internal document sketching the rationale for building a feature, target user segments, user experience, and behaviour of the feature once built. It serves a point of interaction between product managers, engineering, UX, marketing, and adjacent teams.
At Google, we generally write PRDs in Google Docs, and it gets tons of comments from stakeholders, which is how the document evolves from concept stage to approved for execution. It’s the job of a product manager to conduct meetings, answer comments, and drive discussion to build shared understanding of feature implementation and get approval from stakeholders.
Believe it or not, PMs spend tons of time writing PRDs. It’s not that writing it takes a huge amount of time, but enumerating options, gathering customer feedback, and getting buyin takes time. Sometimes design choices can be tricky and consequential at the same time, and generally such critical points consume a huge deal of effort.
Here are some pointers I keep in mind when writing PRDs:
1. Guiding principles
Structured communication is generally of two types: breadth-first and depth-first.
In breadth-first, you offer information at one abstraction and then go a level deep. In contrast, in depth first you talk about one aspect of the topic in detail and then move to the next one.
When it comes to written communication, breadth-first approach often does a better job of communicating information and getting the buy-in. If readers understand and agree with the guiding principle, reading through the rest of the documents becomes smooth. In contrast, going depth-first might be too much detail to consume.
2. Rationale for building a feature
One of key thesis to defend in the PRD is how this feature will create value for users. This defence logic to a large extent determines whether the value created by this sub-feature justify the delay in speed-to-market caused by it.
One way to easily explain the value to users is writing critical user journeys (CUJ). One format to write the user journey:
As a [ role ], I want to [ feature ] so that [ goal ].
For example, I work on the Storage Transfer Service product at Google. We launched a Transfer Service for on-premises for customers to ingest data from on-premises filesystem. Here is one of the CUJ for this product:
As a System Admin responsible for migration from on-premises, I want checksum validation so that I am assured that copied data is the same as original data.
This CUJ explains why customers require us to do checksum matching of the data transferred through the transfer service.
3. Offer consistent level of abstraction
It’s not a good read when some parts have minute implementation details such as what library to use and crucial details are skipped in other parts. Unless it’s required by stakeholders, it’s a good practice to stick to a consistent level of abstraction.
For example, if you are defining API specs then define for all the suggested API actions. If not, then just comment on behaviours.
4. Eat the complexity
One common theme I have seen across good PMs is that they don’t push complexity to engineering. If there is a hard decision to be made, it should be on the PRD.
PMs going extra mile to get clarity on design choice can save a lot of time for developers. It could be whether APIs should be async or synchronous. Or it could be even about implementation choices that might affect latency or availability if crucial for user experience.
One critical part of reducing complexity is defining scope clearly, thus reducing scope ruthlessly. Needless to say, nobody, just nobody likes to delay launch.
5. Go broad to go narrow
Well, it’s not exactly a principle for writing good PRDs. It’s Intuit design’s principle, but it’s my go-to technique for brainstorming.
The basic idea is, in order to come with a small set of good ideas, one has to first generate enough ideas, irrespective of whether they are good or bad. In all likelihood, starting with a limited number ideas would result in you ending with a couple of mediocre ideas.
In the context of writing – not writing unnecessary statements also stops us from accidentally producing statements of consequence. It’s better to be lenient in the first draft. Start with creatively and perhaps exhaustively. Then, prioritize ruthlessly – move everything that’s not helping you make the point to appendix.
I’m sure I’ve missed many. What are some best practices you follow in writing PRDs?
