How to Write a Product Requirements Document (PRD)

A guide to writing excellent PRDs

Writing a Product Requirements Document (PRD) is one of the strategic and exciting tasks in Product Management. I could liken a PRD to a few things, but the most intriguing is a life manual. Did you get that? No? Stay with me.

Imagine that right after your placenta was delivered, a pamphlet followed — a manual of some sort that would guide your parents through your growth. It would tell them when your education should start, the number of days you’ll spend at every phase of your life, the specific people you’d have to meet in life, and your goal. Fancy, right? Product Managers hold this power, too, but only over products (obviously, lol).

What is a PRD?

A Product Requirement Document (PRD) is a document that clearly interprets your product in understandable terms. It outlines its purpose, features, functionality, and performance process. It is usually written by the Product Manager. It addresses what to build, who the product is targeted at, and why it will be developed.

Why is a PRD Important Anyway?

• Alignment

It is a great way to ensure that all the team members (development team, marketing team, stakeholders, etc.] are on the same page. It eliminates the problem of miscommunication between the parties during the development stage.

• Assessment and Accountability

Everyone at different stages can revert to the document as the marking guide for what has been done. To assess progress, you can always compare what you currently have with what is stipulated in the PRD. The PRD holds the development team accountable. Also, it shows a timeline so everyone knows what should be done at a specific time.

• Clarity

A PRD helps to clearly outline the process ahead and what it involves and should achieve, providing clarity to the Product Manager and other team members.

“A PRD serves as a living document for any designer and developer involved in the project to understand the purpose of the product and its current status.”

[Nuclino]

What Should a PRD Include?

Writing a PRD sounds like a stressful task. You may have questions about what to include or leave out or how to cram all the information you have into a small space. Below is an outline of sections you should add to your PRD; they would help to give you a sense of the structure to create.

1. Purpose

A great approach to this section is to write a problem statement and what you hope to solve. Talk about what you want your product to solve concisely and clearly. To guide you in writing this section, ask yourself:

• What is the problem I’m trying to solve?
• What’s the vision and mission?
• Who will it help?

Now, write this section to answer those questions.

2. The Target Audience and How it Helps Them

Yes, in the previous section, you brushed the audience topic. In this section, you’ll need to explain the needs of each category of your audience and how your solution will help them.

An example:

• Category A: Older women who struggle with hair loss
• Category B: Women with inherited hair loss
• Category C: Women who want healthier hair

From this breakdown, you can deduce that I would be working on a hair product to battle hair loss, regardless of age, but specifically for women.

3. Features

In this section, you’ll iterate different features and categorize them. Maybe you just rolled your eyes and wondered, “Which categories again?” It’s just a way to assign priority levels to your features. Here are some sample categories:

• Must have
• May have
• Should come later (in subsequent versions)
• Shouldn’t have

4. Wireframes

Here, you include a sketch (wireframe) of the product to be built. It would give perspective on what the solution should look like.

5. Non-Functional Requirements

This section outlines the non-functional details like whether you want to have app and web versions, the supported browsers, etc.

6. A Proposed Timeline

Create a timeline and break it done. Instead of giving ten (10) months for the development and launch, break it down into something like “2 months for research, 4 months for building, and 4 months for testing”. Doing it this way will help you to know what exactly you should be doing at a particular time and not lose track of time.

7. Potential Blockers

What are the things that may threaten your work along the line? Including this part prepares the team to face them and figure out a way to work around them.

8. Metrics

Here, you write out the criteria for launch, i.e. the conditions or prerequisites to meet before you are ready to go into the market.

You can also write out your success metrics. What would need to happen for you to consider your product a success? It could be in terms of numbers of users, countries reached, etc.

9. Manpower

In this section, you should outline who your team will contain. You mustn’t necessarily have names set out, but you can list the roles. Also, write out the stakeholders involved in this process.

10. Author and Edit History

This part should be included at the top of the document to show your name and the curation date. It should also show details of updates, including the dates and people who made the updates.

Tips for Writing Excellent PRDs

Now that you know what your PRD should include, below are some tips to help you.

• Write in simple terms to reduce the risk of miscommunication or misunderstanding.
• Keep it short. Many say a one-pager is the best kind of PRD. I think that a one-pager PRD is easy to read by everyone, but if writing a one-pager will make you leave out crucial information, then take more pages. Just make sure you go straight to the point, using as much space as you NEED.
• When writing the metrics, use numbers. Instead of saying “Many African countries in a short while,” say, “7 African countries in 3 years”.
• Don’t assume; write all that’s necessary.
• Add the sections you want to include to a checklist and tick them as you go so that you do not skip anything.

I’m confident that after reading this extensively, you will be on the right path to writing excellent PRDs. If you do not have a product to work on, you can experiment with fictional products. Ensure you practice so you can get better at it. You can also share your PRDs via email or Twitter if you need a third eye to look through them.

I wrote about the basics of Product Management in a previous article; you can check it out here.