How to Write a Good Product Requirements Document

Product Requirements Document (PRD) builds a shared understanding of what to build. It’s a written agreement between PM, engineering, and UX that serves the following purposes:

• Offers a forum to reach a shared understanding, and once finalized, it serves as a source of truth to refer back to in case of any confusion.
• Goes beyond enumerating requirements and conveys the “why” by highlighting customers' problems and asks.
• Provides input for engineering and UX to draft design docs and mocks, respectively.

At Google, PRDs are written in Google Docs, and they receive tons of comments from stakeholders, which is how teams reach a shared understanding. Product managers conduct meetings, answer comments, and drive discussions to get buy-in from stakeholders.

PMs typically invest 100+ hours writing PRDs. Even minor design choices can be tricky and consequential at the same time, consuming a huge deal of effort.

A well-written PRD can save a lot of time for engineering and UX. Otherwise, product teams can go in circles, wasting time on design choices that might not be the best. This also means additional meetings, which no one likes.

What PRD is?

PRD comes into the picture once the decision on investing in the feature has been made and before design docs are written. Hence, “why to invest” has already been answered.

However, PRD almost always contains a background/context section explaining why we’re investing in this feature.

Similarly, PRD doesn’t dig much into “how,” but only tries to answer questions that could unblock the “how to design” part, which is covered by the design docs and mocks.

The major portion of PRD is about what to build, covering:

• Problem statement: Target customer and the exact use cases this feature addresses.
• Solution: PRD paints a picture of the to-be user journey and clearly defines the requirements and timeline for execution, which form the foundation for design docs and mocks.
• Metrics: Definition of what success looks like for this feature and how it can be measured.

What PRD is not?

The PRD should succinctly reference the business objectives, serving as a guide for product development rather than a sales pitch.

• User-facing document: A PRD is not designed for external audiences. Instead, it’s an internal document targeted at building a shared understanding of how the product will work. While clarity is crucial, the document doesn't need to be excessively polished. Its primary focus should be on conveying information clearly to stakeholders, ensuring everyone is aligned on the product vision and requirements.
• Product proposal: A PRD should not be confused with a product proposal. PRD isn’t the place to make the business case. While both documents may touch upon the business rationale, a PRD isn't the place to build a comprehensive business case. Typically, roadmap planning sessions and presentations to leadership are more appropriate for detailing the business case. PRDs should just contain the gist of the business case.
• Design document: Although a PRD outlines essential requirements, it is not a detailed design document. Instead, PRD provides the requirements that inform design decisions without going into the specifics of the product's design or architecture.
• One-time document: PRDs are living documents, which should be updated as the product evolves and used as a source of truth.

Tips for Writing PRDs

1. Guiding Principles

Structured communication generally falls into two types: breadth-first and depth-first.

• Breadth-first: Offer information at one abstraction and then go a level deep.
• Depth-first: Talk about one aspect of the topic in detail and then move to the next one.

When it comes to written communication, a breadth-first approach often does a better job of communicating information and getting buy-in. If readers understand and agree with the guiding principle, reading through the rest of the document becomes smooth.

In contrast, going depth-first might present too much detail to consume.

2. Rationale for Building a Feature

One of the key theses to defend in the PRD is how this feature will create value for users. This defense logic largely determines whether the value created by this sub-feature justifies the delay in speed-to-market caused by it.

One way to easily explain the value to users is by 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 connector for on-premises sources. Here is one of the CUJs for this feature:

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 the original data.

This CUJ explains why customers require us to do checksum matching of the data transferred through the transfer service.

3. Offer a 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 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 behaviors.

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 the extra mile to get clarity on design choices 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.

5. Go Broad to Go Narrow

It’s Intuit design’s principle, and one of my go-to techniques for brainstorming.

Step 1: Go broad
→ Generate 20+ ideas in 2 minutes
→ Don't judge, just write
        ⬇
Step 2: Go narrow
→ Choose 3-5 best ideas
→ Based on impact & feasibility
        ⬇
Step 3: Deep dive
→ Deep dive into chosen ideas
→ Develop and improve

Why does this work? Because in order to come up 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 of ideas would result in you ending up 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 creatively and perhaps exhaustively. Then, prioritize ruthlessly — move everything that’s not helping you make the point to the appendix.