What is a Product Requirements Document?

A product requirements document (PRD) is a living, detailed guide to your product’s intended features, functionality, and purpose. Product managers (PMs) typically create and own PRDs to gain clarity and alignment with stakeholders around: 

  • What you’re building
  • Who you’re building for
  • Why you’re building this (i.e. what’s the added value?)
  • How you plan to take this to market

What’s inside the Product Requirements Document template?

We’ve broken this PRD template down into three parts: Product/feature overview, solutions, and assumptions/risks. 

Part one includes: 

  • Mission. This should be your elevator pitch. Keep it concise, specific, and use-case oriented.
  • Target audience. Help your readers get a feel for what types of businesses will end up using your features by including an overview of the problem your PRD is looking to solve.
  • Use cases. Describe how your target audience will use the product to solve their pain points. 
  • Jobs to be done (JTBD). We give you a formula to describe the different JTBD this solves. 
  • How this supports your strategy. Make sure you’re investing in the right things by answering these questions.
  • Product outcomes. What are the high-level business objectives (like increasing revenue, reducing churn, or cutting costs) you’re aiming to achieve? What product metrics will you track to determine the product’s success? 

Part two includes: 

  • Your ideal state. In a perfect world, how would you describe the customer’s new experience? What can they do? How do they feel? 
  • Test, release, and iteration plan. What are you NOT building? What’s out of scope? What alternatives did you consider? 

Part three includes: 

  • Assumptions and risks. Jot down costs, timing, etc here. This is also a great place to jot down anything that remotely worries you about the project. 
  • Teams and cross-functional dependencies. What team(s) could be cross-functional partners or dependencies? 
  • Go-to-market (GTM) launch. How will you launch this product or feature to the market with your cross-functional counterparts? 
  • Open questions. List anything that’s rummaging around your brain as it relates to this product or initiatives that drove this project. 
  • Change log. Track any notable changes made to this project, like bug fixes or feature additions. 

How to use this Product Requirements Document template

  1. Create your PRD. Make your own copy of the PDR template above, rename your file, and update proper sharing settings. 
  2. Fill out your first draft of the PRD. We’ve included the different sections required for this template, with descriptions on how to fill out each section. It’s totally okay to leave sections blank and keep this private until it’s ready for review.
  3. Gather feedback and approval. Spend time getting input and alignment from your teams & stakeholders. Then, hold an in-person or async review to make decisions around key decisions and get approval to build your product/feature. Once this is complete, you can share with your design and engineering counterparts.
  4. Continuously update. As time goes on and your work evolves, keep this PRD fresh and accurate.