How to write the perfect PRD (Product Requirements Document)

If you are a Product Manager, chances are that you would be writing PRDs (Product Requirement Documents) regularly. You would be spending a good amount of time thrashing the PRDs out and conceiving them in such a way that it hits perfection.

And if you are an aspiring Product Manager, then knowing how to craft a perfect PRD is something you should definitely have in your repertoire.

So what does it take to write the perfect PRD? A PRD that can be easily understood by all the stakeholders? Poornima J (Associate Director of Payment Products, RedBus) took some time out and shared her thoughts on this one especially for members of the CohortPlus community.

Before we get into the details, we would let our readers know that CohortPlus is the largest and the most active community for Product Managers in India and one of the largest such community in the world. Rich and spam free discussions take place on the platform every day. Additionally, we have launched a special Product Management toolkit which contains links to top books, reports, articles, case studies and Product Management interview questions (with answers from members of the community).

Link to register on our Android app — https://goo.gl/7yz7E4

Link to register on the CohortPlus website — https://cohortplus.com/

Without further ado, here are all the details you wanted to know about how to right the perfect PRD —

What is a PRD ?

A PRD lays out the functionality of a product along with the required designs/wireframes, different stages of release/availability of the product; also declaring certain assumptions on both customer and product-development fronts.

I hate documents, Can I write an email or keep it more conversational? My Engg team anyways finds it boring to read these sagas!

The objective of PRD is to make the process of development much smoother. The medium of communication could be an email or a document or anything else which works for you and your team.

Ultimately, it is a product person’s responsibility, to bring on board all stakeholders and hence make your content to be interesting to read.

But remember, a good start is half done!

What are the benefits of drafting a document?

- For mature organisations, with multiple systems and teams, it helps to resolve technical and operational dependencies.

- Estimate on costs based on the scope defined

- Track different stages of the project based on release versions: ex MVP (Minimum viable product)

- Minimum surprises at the end (hopefully)

Is it different from technical specifications and project documents?

Yes

1. It presents the solution for the end customer and not the implementation details. The Engg. team would understand this and break down into implementation — sequence diagrams, resolve dependencies, etc.

2. It doesn’t track the release timelines. I am not a fan of business giving deadlines on projects. Timelines need to be given by Engg team as per complexity and PMs need to pick up the stories as per priorities (the famous interview question on how do you prioritise!)

Before you write:

Have a workshop with different stakeholders and brainstorm it so that all the flows are clear for you.

A lot of times, discussing the project with another product manager who is from a different vertical could help.

Which are the tools to be used for writing the PRD?

Google docs work best for me.

1. All stakeholders can review and add comments

2. Comments can be resolved and debated in the document itself.

3. Doesn’t go through versioning in a traditional way. You can send updates to relevant audience whenever you make changes.

4. You can choose to give different levels of access: edit, comment, read only, etc (I usually give only comments-permission to audience).

What does the PRD consist of?

1. Objective:

Define an achievable/implementable objective which can be measured (Remember — what gets measured gets managed).

- Avoid generic phrases like “To build best customer experience”

-While we all talk about customer experience on face value, there would be an underlying business value for every project.

- Highlight the stakeholders who would be benefited: be it improvement of a metric, introduction of a new feature, process improvement or automation

Example: Introduce relevant Add-ons along with regular bus ticket booking to get additional revenue.

2. Metrics Required:

While you can be objective, a quantitative metric is required to monitor the progress.

In the above example, revenue could be X crores per quarter (wrong/convenient metric if you just want to tick mark your goals: number-of Addons introduced).

You can have sub-metrics which will help you achieve the main goal.

Ex: Work on the attach rate of add-ons with each transaction. X% of transactions need to have goods ordered along with it.

3. Who are you building this for (Customers, User flows and tasks — helps to see the product from the end customer perspective):

Who is this customer?

What is the action taken?

In order to fulfill “Which/When in” need.

Depending on your segment, you can define the customer's age, gender, environment, etc.

A single process can have multiple customers identified. For example, for any refund failures through payment gateways, we wanted to automate the NEFT transfer to end customer in case auto-reversal of funds fails.

This is an internal process which has different user personas.

I am a customer care executive, who tried to process an exceptional refund for delay of the bus to end customer and hence raised a wire transfer request.

I am a finance person who received the request, downloaded the report and need to mark this ticket as resolved/errored as per status of transfer.

I am an end Redbus customer who is waiting for a refund on a delayed bus.

4. Different stages of the release covering present and future scope (present the priorities if possible and not the timelines):

Break down your projects into different achievable modules. As we are moving towards an agile mode of development, it is good to have these discussions with different stakeholders before starting a project and modify the modules as per customer’s response.

5. Include the support flows:

Customer care is an important aspect of any product release. Make sure that care team has access to all required information although it is not included to end customer.

Ex: Wallet which end customer can use to pay and buy different products. The wallet history as a feature may not be available in first cut (MVP) to end customer but support team needs to have access to this for answering customer queries like “Why is this amount debited? What is the balance now? I did not make this transaction- some fraud happened!”

6. Designs:

Prototyping attached with PRD for each user story would be a great help for Engg.

It helps them visualize the customer journey and makes your life easy too.

Constrained with design bandwidth before sharing PRDs? You can go for prototypes using simple wire-frames.

Some of the tools for prototypinh: Zeplin, Invision, etc.

7. Reports/Tracking:

That excitement of monitoring the improvement in sales/conversions/page clicks when you launch a new feature — how can you miss what metric you want to track?

Engg. and Analytics teams need to define the attributes and change the dashboards accordingly. Keep in mind cross-functional stakeholders while you define these metrics.

Ex: You are building a feature to re-target the customers who failed on bookings. If you do not tag the new booking made to the original failed transaction, you will not know what percentage of failed transactions/customers have you converted with the re-targeting flows.

8. Scaling up:

Let the team know about the future scope, volumes and additions which you foresee later. This helps them design the systems accordingly. Let’s say they are building for one Addon now and later you say that customer can buy two-three Adons in a single transaction.

The order-management system needs to accommodate this in initial purchase order design itself.

Do not overkill this — What is irrelevant? You want a bot to suggest a context-sensitive Add-on in future based on ML.

But what is relevant: every customer will be shown a different Add-on in future as per the customer segment

9. A little Hygiene on documentation:

As documents help for references in future mentioning below details would help

• Title and a tag line

• A small description which can capture the benefit of the project

• Author/product owner

• Date of writing the document

• Version: there could be multiple revisions so a number assignment helps to make sure all are on same content

10. Lastly, Here is an example of template for Add-ons:

Sample PRD is attached below —

Hope you liked the article. Thanks again to Poornima J (Associate Director , Payment Products RedBus) for this insightful writeup !