How to succeed at Product Requirements Documentation

Easy steps to create a PRD plus download Product Hunt’s guide.

I’ll try to answer

J. Antonio Avalos

question about PRDs in this post. If there’s a topic you want me to cover, you can let me know in the chat 😉

Product Requirements Documentation (PRDs) it’s the foundation that sets the ground for a smooth and efficient development process that usually leads to a successful product launch. This live doc is also known as Project Specification, but its name can change for each organization.

Also, it can vary in format for environments with agile or scrum. But the main goal is to easily communicate to all the interested parties what is going to be build, without focusing too much on the how (that’ll be a Project/Product Plan).

Personally, I’ve experienced how this doc makes a positive impact on different teams. It helps to create a balance between design, engineering, and product management to ensure that the product meets the goal. The lack of this vital document at the beginning of every project can lead to different assumptions about the desired outcome, as illustrated in the next image.

What the customer really needed from Behance

Sadly, around 70% of projects fail because of the lack of requirements gathering. Many organizations and product teams see Agile as a way to start building blindly and documenting “when there’s time for it”. But the truth is, if you don’t know what you are building, how will you know if you’ve achieved it?

---

“If you don’t know what you are building, how will you know if you’ve achieved it?”

---

In Good Product Manager, Bad Product Manager written by Ben Horowitz and David Weiden, the authors describe PRDs as:

In Product Requirement Documents (PRDs) are an essential tool used by product managers to keep track of their product. They must be constantly updated and be used as a guiding document by the product team. PRDs are never truly finished and should be used to guide the product team through their iterations.

Also, in Marty Cagan and the Silicon Valley Product Group guide on How To Write a Good PRD, says:

The purpose of the PRD or product spec is to clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior. The product team will use this specification to actually build and test the product, so it needs to be complete enough to provide them the information they need to do their jobs.

Convinced already? Let’s jump into the structure of a PRD then!

The Structure of a Product Requirements Document

As noted in Marty Cagan PRDs guide, there are four main sections for this document:

1. Product Purpose

2. Product Features

3. Release Criteria

4. Schedule

5. Extra Step!

1. Product Purpose

This section outlines the goals and objectives of a product, who it's for and why it is being built. It describes an ideal user with their interaction with the product and details the assumptions being made about the market, user and company's goals.

Also, it forces the team to be specific about the end user of the product and can highlight any potential gaps or assumptions. Making this part specific as humanly possible, will make the purpose clear for everyone.

• Respond to: Who is this product for? How will the ideal user use it?

• Respond to: Why are you building it? Why is this important?

• Create an Elevator Pitch: Describe your goal in one or two sentences, adding the unique value your product will offer.

2. Product Features

This section will outline the needs of the user and the tasks required to meet those needs. It will also prioritize features and explore edge cases to communicate to design and engineering, based on user feedback data.

This part is about covering the different elements of a product from a user's perspective, the problem it is solving, and what the product will look and feel like. This includes user stories to connect users to their desired features and outcomes, as well as mockups and prototypes to illustrate how the product should appear when completed.

Answer this from a user’s perspective:

• How will the user interact with the product?

• What is the user journey?

• What problem is it solving for the user?

• Why should the user care about the product?

• What does the product look and feel like?

3. Release Criteria

This part can be very technical because it requires the product manager to help and guide engineers in building features that the user will find valuable. To achieve this, the past elements such as user testing, user stories, and usability tests can be included with acceptance tests to ensure each feature is ready for the launch. Otherwise, how to know when the product will be ready for testing and release?

Quoting from UXPin, these are the five areas to cover:

• Functionality — Is there a baseline percentage of the original features that must be retained? What are the absolute mandatory functions?

• Usability — Is the program aesthetically striking and intuitive to users? What is the acceptable time to complete tasks for each use case?

• Reliability — What’s the maximum acceptable failure rate? Are these failures predictable? Can the system recover from these failures?

• Performance — How fast must it be? What is the maximum response time, throughput, and memory consumption?

• Supportability — Is it testable, serviceable, installable, and configurable?

4. Schedule

The purpose of this section is to focus on product constraints. Here there’s no need to have an exact timeline of each feature. Why? Because user or stakeholder feedback and the market can affect these elements and other decisions later on.

Instead, focus on workflow constraints such as budget, resource, and timing to get more realistic sprint lengths. Determine what would be the ideal launch date and what other resources are available to make this happen.

Don’t hold yourself to a specific date, instead clarify your workflow constraints:

• What’s the ideal launch date?

• When can the beta testing start?

• When would be ideal to go to market?

• How much flexibility do you have?

• Are there budget issues to consider?

• Any other resources you’re short on?

• Which teams dependent on the release?

5. Extra Step: Get Feedback

This final extra step is a big plus, in my opinion. Many teams work so hard to create a good and solid PRD just to never see it ever again. However, this is a great opportunity to share it with stakeholders and get valuable feedback early on and even a buy-in!

It is important to involve your core team and have everybody review it. Also, invite everyone that is involved in the project to get their comments or thoughts. Collaboration is always the key, but keep in mind that there’s a way to ask for feedback and be conscious about what type of feedback you’re expecting. Open-ended feedback can lead to disaster.

Make sure to set the right context and explain what the PRD is about:

• PRD is just a guide: It should not be used as a guide to determine how to build the product, but rather to ensure that any product developed meets the user's needs.

• Clarify your assumptions: This guide is an opportunity to ask if your assumptions are correct or if you’re missing some considerations that should be included in the PRD.

• Collect constraints: Ask Stakeholders about additional constraints that might impact a project before it's started in order to ensure a successful outcome. They can have more insightful information about business decisions that you don’t.

Wrapping up

Remember, a Product Requirements Document helps you start any project and have everyone involved in sync. It should be stored in an accessible place for all teams and stakeholders involved.

It is a living document that will evolve aside of your project. But don’t fall in the trap of doing a very extensive documentation that will consume most of your attention and it’ll very hard to read for everyone. Sometimes, a one-pager is better but this depends on any project.

There’s a great (and very famous!) example from Product Hunt. This example of PRD its only 7 pages and describes a clear goal for the user, who it is for, provides customer validation data, and provides UX mockups for design direction.

Publications I enjoyed reading this week

• Product Management IRL

• Product Party

Referrals and free stuff

• Build apps with Airtable and without developers for free.

• Ace Your Next Product Manager Interview.