Product School

Product Templates: Product Requirements Document (PRD)

PS logo with padding.png

Author: Product School

January 17, 2023 - 6 min read

Updated: January 24, 2024 - 6 min read

Editor's Note: the following content has been validated by the Head of Product at YouTube.

If you are a Product Manager or aspiring to be one, chances are that you have come across or you’re currently writing your Product Requirement Documents (PRDs). Or perhaps you’ve already written dozens of PRDs and you’re just looking to fine-tune your skills.

Our PRD guide aims to take you from idea to action. We’ll tell you what a PRD should include, a step-by-step guide for writing your own, and provide you with a template to get you started.

So what does it take to write the perfect PRD? Let’s jump right in.

Ready to get started? Access a free PRD Template here!

What is a Product Requirements Document? 

A PRD is a guide that defines a particular product's requirements, including its purpose, features, functionality, and behavior.

This document is generally written by the Product Manager to communicate what they are building, who it is for, and how it benefits the end-user. It also serves as a guide for business and technical teams to help develop, launch, and market the product.

According to Minal Mehta, Head of Product at YouTube, a PRD is a living document that should be continuously updated according to the product's lifecycle.

blog image 1: prd blog

Now that you know what a Product Requirements Document is, its time to understand what exactly goes in it.

The contents of a PRD

  • Title: Give this project a distinct name.

  • Change History: Describe each important change to the PRD, including who changed it, when they changed it, and what they changed.

  • Overview: Briefly, what is this project about?  Why are you doing it?

  • Success Metrics: What are the success metrics that indicate you’re achieving your internal goals for the project?

  • Messaging: What’s the product messaging marketing will use to describe this product to customers, both new and existing?

  • Timeline/Release Planning: What’s the overall schedule you’re working towards?

  • Personas: Who are the target personas for this product, and which is the key persona?

  • User Scenarios: These are full stories about how various personas will use the product in context.

  • User Stories/Features/Requirements: These are the distinct, prioritized features along with a short explanation as to why this feature is important.

  • Features Out: What have you explicitly decided not to do and why

  • Designs: Include any needed early sketches, and throughout the project, link to the actual designs once they’re available.

  • Open Issues: What factors do you still need to figure out?

  • Q&A: What are common questions about the product along with the answers you’ve decided? This is a good place to note key decisions.

  • Other Considerations: This is a catch-all for anything else, such as if you make a key decision to remove or add to the project’s scope.

As you write your first drafts, it’s ok to leave TBD and placeholder comments for unknowns.  For example, you might not initially know how you want to message the product.

blog image 2: prd blog

Building a PRD: step-by-step

Now, its time to show you how its done.

Step 1 - First draft

 To start, write the first version of the PRD in your collaborative platform of choice.

  • It’s a good idea to start your PRD draft somewhere private.

  • People talk and sometimes get the wrong ideas, and you don’t want them to find a draft with language/features you realized were wrong.

  • It’s fine to put TBD in spots (maybe success metrics).

  • In general, you want the background, objectives, maybe metrics, and maybe key user scenarios/epics focused on the high-level features.

Step 2 - Get approval

Get any needed approvals from your boss with the first version. Your teammates and your boss are an asset, and use them as such.

  • Get their thoughts/feedback.

  • People who have been there longer might have insights you don’t know about or can suggest ways to approach potential sticky points.

  • Plus you don’t want to blind-side your manager!

Step 3 - Share with design

Share the PRD with the design project leader and incorporate feedback.

  • Design is close to the user too, therefore it would be smart to engage them before approaching engineering, because their feedback might affect the project’s technical scope.       

  • Discuss the spec with them and incorporate their ideas/feedback. You’re not telling them what to do.

Step 4 - Share with engineering

Share the PRD with the engineering project leader (don’t forget the design lead!) and incorporate feedback.

  • With the design lead (ideally), engage the engineering lead and get feedback.

  • This will help you figure out what’s technically feasible, get some very rough time/difficulty estimates, and they might know something about the tech part of the system that enables a new solution.

Step 5 - Share with project team 

Share with the project team!

  • Move the PRD to someplace more public so that others can see what you’re thinking in one place.

  • Make sure to get your team’s questions, input, etc. and document it on the PRD

  • At this point, note any good ideas, and if they’re not right for this initial version, still record them in the  icebox

Step 6 - Share with company

Possibly share it with the company.

  • You’ll likely be presenting rather than sharing the PRD.

  • This doesn’t necessarily mean read your PRD on a podium but instead, assemble a well-structured presentation and share it with your stakeholders.

Start now!

What are you waiting for? Access your free PRD Template.

Main takeaways

  • PRDs are living Documents:

    As you build the product, you need to constantly update the PRD. 

  • They must be flexible:

    As you write your first drafts, it’s ok to leave TBD and placeholder comments for unknowns.  

  • A good PRD is concise:

    Note key decisions, add relevant links, and don't leave anything up for interpretation.

  • PRDs are a product of teamwork:

    Even though the Product Manager is ultimately responsible for owning the product/defining what to do. It's much better to have a collaboration/soft power approach when it comes to creating the PRD.

  • They are excellent communication tools:

    Use the PRD to communicate what you're building and why.

Check out our other templates:

Still, looking for some great templates? See our collection of Product Management Templates!

Updated: January 24, 2024

Subscribe to The Product Blog

Discover Where Product is Heading Next

Share this post

By sharing your email, you agree to our Privacy Policy and Terms of Service