What is a Product Requirements Document(PRD)?

The product requirements document or PRD is a document that describes the product that the team has set out to build. It serves the purpose of being the guiding document that answers all the questions that a team may have while developing a product.

The PRD is typically written and maintained by the product owner. This may be the product managers, Heads of Products, CEOs or anyone else on the team who are responsible for the overall vision and execution of the product.

How detailed should a PRD be?

Product Requirements Document Comic Strip
Source‌‌

Since agile practices started taking over software development processes, the need to craft long, all-encompassing PRDs have faded to give way to more succinct product specs.

Today, PRDs are generally high level product wikis and in most cases contain a collection of individual spec documents.

Together, these individual specs paint a bigger picture and serves to showcase the product as a whole.

Crafting a compelling Product Requirements Document

A lot of groundwork needs to be done in order to craft a compelling product requirements document. An effective PRD serves as the go to resource for any team members looking to answer questions about the product, its scope, features and quality requirements.

In order to cover all of these topics and communicate them effectively, the product owner needs to spend enough time researching and building clarity on a variety of topics.

Product owners should spend enough time talking to customers, understanding their pain points and requirements better. Any ambiguity in this stage will make it extremely hard to create a clear, concise PRD.

In addition to knowing the needs of the customer, it is important to understand the competitive landscape and other solutions available to the customer. This will not only put you in a better position to articulate your value proposition but it also helps you think of and craft feature specifications better.

PRDs for feature development

In many cases, product managers who own specific parts of a product end up creating PRDs for the features they manage. This is very often the case in larger companies with more mature products.

The main reasons for maintaining separate documents for each feature/product group could be because of any of the following:

  1. Individual feature groups may target different customer personas in the same market.
  2. The size of feature building teams may be very large.
  3. The scope of the entire product may be too big to fit into a single one size fits all PRD.
  4. Features development teams may need specifications in greater granularity than an overall PRD can provide.

Parts of a PRD

1. Introduction

This section introduces the reader to the product at a very high level. This would typically consist of a high level overview of what pain point the product solves, who the customers are and how the product would function.

Here is an example of a concise introduction from the product hunt PRD written by them in early 2013:


Intro section of Product Requirements Document
Introduction Section of the Product Hunt PRD (source)‌‌

2. Product Goals

The second section focuses on customer pain points in greater details and how the product solves the problem. It is also important to showcase how the product is different to the other alternatives in the market.


Goals section of Product Requirements Document
The Product Hunt PRD describing the product purpose (source)‌‌

The product manager might also use this section to describe the product’s positioning in the marketplace, especially if he feels it may help the readers understand product differentiators better.

3. Features

This section describes the features that the product would contain. The features usually contain mockups and wireframes attached. Each feature can be briefly described with a link to the relevant epic/story.


Feature descriptions in Product Requirements Documents
Feature Descriptions from the Product Hunt PRD (source)

If the feature comprises of a series of user stories, a tabular column with the links to the relevant stories can be added for easy navigation.

Another important point to note is that the feature spec has to include visual design and user interaction. These details are sometimes part of the document but are generally found in the user stories that the document links to.


Mockups in Product Requirements Documents
Detailed mockups and other assets can be included in the document or detailed user stories can be linked to (source)

4. Tech Notes & Quality Guidelines

This section consists of guidelines for engineering teams and QA teams working on building and deploying the document. The acceptability criteria outlines the overall quality checks that need to be maintained while building and releasing the product.


Technical Notes for Product Requirements Documents
Tech Notes from the Product hunt PRD (source)

5. Timeline

The timeline section gives an overview of release targets and when each feature is expected to reach completion. This is a fairly brief overview of development targets and can be changed over time. A more detailed development and release plan can be described in the product roadmap.

6. Other Optional Sections

Other sections that you could consider including are

  1. Detailed user personas and use cases
  2. Design notes
  3. Analytics or Performance Metrics

Best Practices when writing a PRD

The most important job of a PRD is to serve as the go-to document  for the development team and other stakeholders that are working on a product. Here are the best practices to follow when creating a PRD:

  1. Use language that is simple and try to minimize jargon (unless it is in the engineering notes section)
  2. Clearly define user pain points and product goals before diving into feature details.
  3. Describe each feature along with supporting mockups, wireframes and prototypes.
  4. User interaction and visual design can be included directly in the PRD or as links to relevant user stories.
  5. Define clear release criteria in terms of performance, scalability, releasability etc.
  6. Offer an overview of planned timelines.
  7. It is normal for user requirements and specs to change over time. Understand that the PRD is a living document and needs to be constantly revisited and kept up to date.
  8. Keep whatever is useful, remove anything that is obsolete or is no longer helpful to the readers. The aim is to have a concise document that is easy to maintain and always remains easily navigable.