Product Requirements Documents (PRDs): A Modern Guide

One of Product’s ever-changing artifacts

*Updated 5/28/24*

The art of writing a Product Requirements Document (PRD) has changed a whole lot since I began in Product Management 15 years ago.

History of PM → History of the PRD

In 2008, Marisa Mayer had just established the APM program at Google. The Product Management field was still nascent. It was more the stuff of Silicon Valley legend than standard practice.

Source: Wired

Marty Cagan’s 37-page “How to Write a PRD” was the guide for the era (published ~2006). It railed against bad waterfall practices like lack of usability. It became a viral sensation, email forwarded between product leaders like gold. The guide’s popularity catapulted Marty to stardom, and led to his publishing Inspired in 2008 (which became an instant-hit).

All the things he cautions against in “How to Write a PRD” and criticizes in Inspired - waterfall culture, excessively long PRDS, lack of discovery work - couldn’t have been truer. The Agile Manifesto was only 7 years old. Most teams didn’t really operate in that way yet.

So the guide and book were perfect for the times. And for all the history nerds, both are must-reads. But for a PM in today’s environment, leaving your PRDs where those lead you is a recipe for disaster.

PM’s 15-Year Flywheel

The field of Product Management itself has been the beneficiary of a Flywheel over the last 15 years.

On one side you have increasing pay, and on the other you have better PM practices. These two parts of the flywheel reinforce each other:

1. Pay: Better quality talent → Success of tech companies → Increase pay for PMs → More interested in PM → Better quality talent

It used to be rare to see software engineers or product designers aspire to be product managers (then mostly known as technical project managers). Nowadays, it’s normal to find former software engineers or designers who are now product managers. And it feels like every fourth one you meet has entertained the idea of switching to the field.

2. Practices: Better quality talent → Better PM training & content → Better PM practices field-wide → Increased reputation of PM → Better quality talent

Fifteen years ago, you were lucky to stumble upon a book or PM newsletter to get modern product practices. Now, it’s the opposite. PMs are stuck prioritizing between a litany of content, on every platform from LinkedIn to TikTok.

The rise of PM pay and practices have conspired to power the rapid growth of the field. Now, it’s actually rare to find a product team without a product manager. 15 years ago, it was rare to find one with a product manager.

Just as these two parts of the flywheel have powered the growth of the field, they’ve also accelerated the advancement of the PRD. The modern PRD is far better - and different - from its historical counterpart 15 years ago.

The Modern PRD

• The modern PRD isn’t nearly as long as before. But it‘s somehow also more insightful.

• The modern PRD includes specific user data and insights. It reads like a blog post, but has all the information of the old word documents.

• The modern PRD doesn’t just outline what the team should built, it excites them to build it.

How does this happen? Where does the PM’s work end and the designer’s begin? How much data & user research should be included?

It’s one thing to talk theory and it’s whole other thing to talk examples. In fact - that’s the point of the PRD as well, clarity.

So for today’s piece, we’re going to start by dissecting some PRD examples. Then we’ll go through the theory to put it together:

• Part 1: Breaking down 2 PRD examples in-depth

• Part 2: What should you write a PRD for?

• Part 3: The 5 steps to a great PRD

• Part 4: PRD templates to use

• Part 5: Common mistakes

There are plenty of guides online for PRDs, but I reckon you should read this one because it’s rare to see how an acting product leader evaluates PRDs.

---

Part 1: Breaking Down 2 PRD Examples In-Depth

Example 1 - Airbnb Total Price

So I’ve created a PRD for Airbnb Total Price. It’s very typical. Let’s take a look at it:

Notion Link

What does this PRD do well?

1. It’s good proof of work: There’s no executive, engineer, or designer who’s going to pick up this 10-section document and think you didn’t think this through. This is an underrated but important aspect of why you’re writing the PRD anyways. So step one, complete.

2. It gets all the right sections in there: It actually has a sub-section for almost everything you’d want a PRD to have: functional and non-functional requirements, risks and mitigations, dependencies, timeline & milestones…

3. There’s some good attention to detail: It catches that we want to think of WCAG 2.1 standards, that we want to make a change to the search filters as well on the search, and separated what detail should be on search vs listing vs checkout pages.

It’s very typical of the type of document I tend to receive when reviewing PM homework assignments.

---

At 5,000 words, this guide was too long for e-mail. Continue reading in your browser:

---

What could this PRD do better?

I would reject this PRD if it was submitted in homework to me. There’s a lot this PRD could have done better. We’ll start with the 3 high-level themes, and then dive into the 5 specifics.

High-level themes

1. It seems complete, but the quality of content is weak: The flip-side of having everything filled out, is people are going to judge the quality of the content you’ve put there. And a lot of the content, as we’re going to go through, could be better.

   The second section itself is an example of that:

   

   It’s got this fancy bulleting for content that is completely meaningless. A much better use of words and people’s time would have been to drop in something like a table with stakeholders, their role, and if they have signed off on it.

2. It acts complete, but there are many gaps: The summary in 10.1 says “this PRD outlines a comprehensive strategy.” But then when you go to the legal requirements, you find a tautology: “Ensuring alignment with legal standards.”

   Even having something simple like “@Legal to confirm details” would have been much better. And it should have a glaring tag in the title: '[WIP]’ given how incomplete it is.

3. It excessively delegates: This is the type of PRD where the PM is handing it over the designer and asking them to invent from scratch. It means that the PM hasn’t gotten into any of the details of edge cases or user states.

   Let’s take a look at the fifth section as a prime example of that:

   

   The wireframes and mockups section is essentially asking the designer to fill in that information. But this is abdicating thinking about the design entirely. It’s worth the PM creating a quick and dirty mockup to make sure all this stuff checks out. There are often edge cases and entry points that are not clear when you only right at this high level.

   A product mock isn’t needed for every feature, but for something as big as switching from nightly to total price, it’s needed.

Specifics

1. It’s completely lacking in data or analytics: This section on metrics is comically bad. PMs should display a level of control over the metrics that matter and be specific, not-high-level.

2. The extent to which it’s informed by the customer is debatable: Although it does start with a customer problem, there’s no proof of work. There were millions of complaints and memes about Airbnb’s prices. It completely missed the opportunity to use some of that to motivate the problem and give direction to the solution.

3. It’s not compelling: This PRD had an opportunity to excite every reader. This is clearly the type of change that puts the user first. But the writer has completely missed that.

4. There’s no mention of the other side of the equation: This barely even talks about the very real down-side to conversion you can expect from showing a higher price.

5. It lacks information about competitors: Airbnb’s big competitor, Marriott, shows total price. But the PRD doesn’t even properly survey the competition or draw attention this.

Overall Evaluation of the PRD

Overall, this PRD is a 2/10. This is really more of an outline - a first draft - than a PRD.

As a template PRD, I’d give this a 9/10. It gives you the right signposts of what you should work on in the PRD. It’s a great starting point. But it’s hardly complete. Basically all of the content is vacuous.

Example 2 - Leetcode PM Assesments

So we’ve gone through a bad PRD. Now let’s go through a great one. And let’s first notice that it’s the exact same length 🤯