What is a product requirements document (PRD)?

An overview of the prototypical product management document

Kenton Kivestu, ex-Google, ex-BCG, Founder at RocketBlocks Published: September 11, 2019 | Last updated: November 8, 2019

PRD basics | PRD contents | PRD walkthrough | PRD full example

A PRD is a structured set of guidelines for what a product (or feature) should be.

Ultimately, PRDs are the goldilocks of product development documents: it can't be too pie in the sky (e.g., a press release) nor can it be too technical (e.g., a detailed engineering implementation plan).

Thus, one helpful way to think of a PRD is the bridge document that can take the high level product vision and define it and scope it enough that an engineer could write a credible implementation plan off of it.

Why do companies bother writing PRDs? PRDs serve as a cornerstone artifact that lays out a product / feature's reason for being by answering fundamental questions: Why should we build it? What problem will it solve? What should it look like? What will success look like?

Which companies use PRDs and who writes them? (Top)

Lots of companies, from massive tech leaders (e.g., Google, Uber) to small just-out-of-YC start-ups, use PRDs. Given this range, the depth of information and format of a PRD (e.g., Google doc, Powerpoint, JIRA story, napkin, etc.) varies wildly.

Additionally, the preferred nomenclature varies from company to company (and sometimes even from team to team!). For example, Google historically refers to these documents as PRDs, while the gaming company Zynga refers to them as specs, which is shorthand for product specifications.

Finally, product managers are often the authors of PRDs but it's not true in every case. In particular, in smaller companies and startups, a PRD could be written by a Founder, CTO, engineering leader or another leader helping with product development. But, regardless of who authors a PRD, input from key cross-functional team members is critical to produce a good PRD.

What sections and content should be included in a PRD? (Top)

Teams that use PRDs tend to settle on a list of "must have" sections in a PRD that make sense for their organization's size, release cadence, product stage and complexity. Here we will focus on a handful of "usual suspect" sections that are commonly included in lots of PRDs:

• Context & rationale: why are we building this?
• Goals & success metrics: what's the concrete goal of doing this?
• Use cases: what specific use cases should this enable?
• Requirements: what needs to be built?
• Open questions: what questions need to be answered before we can start?

To review each of these PRDs sections, we'll imagine we're writing a PRD for a small addition to the Uber rider-facing mobile app. Let's imagine that we're writing a PRD to add a small snippet of descriptor text to the page Uber shows riders when they open the app after a completed ride (screenshot below).

Example PRD: Uber rider-facing app updates (Top)

Now, let's jump in and walk through each section and imagine what a PRD addressing this issue might look like.

Section 1: Context & rationale

This section should lay out the core context which illuminates why a particular feature or product is being considered. It might include anecdotes from the support team, observations from UX research, supporting market data or insights the team has about what direction the product needs to evolve.

Depending on the culture of the team and scope of the feature, this section might be quite short or lengthy. Some organizations love to run detailed, highly quantitative analyses which make the case for the feature.

For our sample Uber PRD, we could imagine something like the following:

Recent user research sessions showed that many riders often skip rating their driver on this screen because they can't remember which driver they're rating (e.g., many riders never even see their driver face-to-face since they're in the back).

Since driver ratings are an important dataset for our algorithms and operations, any "nudge" we can give users to rate drivers will have an important, compounding impact on the business.

Section 2: Goals & success metrics

Next, the goals section will, unsurprisingly, lay out the specific goal(s) to be accomplished by the feature / product. While the context section will paint a picture of why the team might think the effort is important, the goals section should put a specific stake in the ground about how the company / team / product will benefit and how to measure it.

Returning to our Uber PRD, the goals section might look like:

Drive a 5% increase in riders rating drivers when faced with this ride-completion rating screen.

Section 3: Use cases

Use cases spell out how customers will interact with the proposed feature changes. The goal is to describe the specific context customers will experience the feature within and how that will help customers complete specific tasks.

Again, we'll return to our Uber ride-completion rating screen example:

Travis recently took an Uber late on Friday evening after catching up with friends. He doesn't use Uber again until next Wednesday during a busy work day, at which point he opens the app and sees the ride-completion rating for the Friday evening ride. He can't remember when he last took an Uber and doesn't recognize the driver. As a result, he presses the "Skip" button rather than rating the driver.

Section 4: Requirements

This could be considered the "meat" of a PRD, where what is actually being built will be outlined. Depending on the feature or product in question, this section could include feature wireframes, full fidelity mockups, details about what changes will need to be made on the front end (e.g., mobile apps) and/or the backend (e.g., databases, processing, etc.).

Let's look at what this might look like for the Uber example:

Front-end

• Display a new snippet of descriptor text below the current rating prompt
• Copy (example): "Your ride from Friday evening"

API

• When requesting the ride details (e.g., driver, driver image, etc), also grab the ride descriptor (no need to build any new logic here, just use the same ride descriptors we already put in emailed ride receipt subjects, instead of specific timestamps).

[AND SO ON...]

Section 5: Open questions

Finally, open questions is a section used as a "parking lot" of sorts to raise questions the author needs to investigate, make a decision on or get feedback on before considering the PRD completed.

• What color and size should the descriptor text be on screen? Cc @design - can you recommend the right parameters here?
• How granular are the ride descriptors that are generated (e.g., do they get more specific than, say, Friday evening?)
• If this feature doesn't produce the desired results, what next steps should we consider?

Putting it all together: a full PRD example (Top)

If you put everything we've discussed together, you'll ultimately get a document that looks like the one below (link to fictional document here). NOTE: This is *not* a real Uber PRD - it is a representative, fictional example based off a plausible scenario.

Even an extremely simple feature like the one detailed could generate a PRD in excess of a page! As you can imagine, more complicated features can end up generating PRDs much, much longer than the example discussed here.

Summary: final thoughts on the PRD

What we've reviewed above is a representative snapshot of what a PRD looks like today.

As mentioned, it's a representative sample, but should provide a directionally accurate idea of what a PRD might look like. Don't be surprised though if you see different formats out there or different types of content included (e.g., a work estimates section from an engineering lead on how long it will take to build, etc.). For example, here is a great PRD template put together by Kevin Yien, a Product Lead at Square.

Finally, modern communication platforms and productivity tools like Slack, Google Docs, Notion, Quip, Office Online, Dropbox Paper, Asana, will have a significant impact on the evolution of PRDs in the coming decades. Already, we've seen PRDs evolve to become "living" documents that tag key contributors, solicit inline comments and feedback and embed additional data (e.g., tables, screenshots, etc).

However, with all that said, one key thing won't change: the need for a type of product document to align stakeholders, serve as a high-level blueprint and translate the vision into concrete product requirements.