5 Simple Steps to write your PRD – Project Requirement Document

Product Requirement Document

It’s the best way to communicate your product idea to the Engineering team

Product Requirement Document a.k.a PRD is the most efficient way of communicating the product idea. If you ask “Why to document when its easier to get on a call/ meet & explain” continue reading…

It’s best because,

Writing/documenting brings clarity
It pushes you to think about actual metrics that matter & helps you in articulating your idea better
Helps in circulating the product idea to many stakeholders & get their unbiased opinion which otherwise wouldn’t happen.
Helps in making product initial discussions better & productive.
It doesn’t require any pre-requisite skillset to document it.

Step 1 — Start by introducing your idea in a tweet’s length.

If your product’s introduction takes paragraph(s) length to explain, then it’s time to re-think. Maybe, you are trying to solve too many things. Most of the successful products do one thing & does that very well. At your product’s inception stage, it’s much required to focus on one core area & build that well.

Don’t believe it? Think about your favorite product & you will realize they do one thing & they do it best.

Step 2 — Jot down your target end-users.

Who are you building this product for & how are they going to benefit from it? Few examples-

Uber’s PRD would have mentioned it as, urban commuters who are looking for a taxi ride at ease.
AirBnB’s PRD would have mentioned, travelers who would prefer private homes to stay when they travel.

Step 3 — Note down “Why is it important to build it?”

This is a critical area of writing your PRD. Once you have a solution in mind & are clear about to whom you are building it, it’s most important to ask this “Why” to yourself & your founding team members.

When done right, this will surface up your USPs. This section will enforce a bit of research on your competitors & understand what can you do better to thrive in this space.

Step 4 — Narrate a typical user flow

Coming to the important & crucial part is to understand what’s in your mind when you imagine yourself as a user using your product.

User flows is a collection of user stories. These user stories are written in layman language with no mention of technology/ design. Refrain from using any sort of jargon here.

To write a user flow, you can follow the below-mentioned user story format.

Format: As a < type of user >, I want < some goal > so that < some reason >

Real Examples

As a user, I want to <browse movies> so that
As a user, I want to <send connection request>to my friend, so that
As a user, I want to <place a food order> so that <it can get delivered to where I stay>

You go on writing all possible user stories that narrate a typical user flow when one uses the product. If you feel there are more roles to your application, try covering them.

Roles are essentially different user types who would use your product differently.

Examples of roles are:

The user stories mentioned above when grouped as per roles will be:

User Role

As a user, I want to <browse movies> so that
As a user, I want to so that
As a user, I want to <get recommendations of movies> so that <its convenient to watch movies of my choice

and so on…

Super Admin Role

As a super admin user, I want to <create movie entries> so that <they can be visible for the users to browse & watch>
As a super admin user, I want to <categorize movies into genres> so that <it’s easy for users to search them>
As a super admin user, I want to <few movies to appear at the top for all users> so that <ads can be injected in them>

and so on…

Step 5 — Try jotting down Sucess metrics for the product

Give an insight into what metric would you consider as a success metric for your product. Note the metric can be derived across various departments ( technology, design, on-field operations, marketing, etc.,)

It goes like –

“An end-user able to book an order within the span of 2 mins” — Metric on Technology & Operations

“User using the app at least 10mins a day” — Metric on technology & design thought process

Think & jot down the metrics of success since it becomes very important for everyone involved & associated in product building activity.

It helps to set all the steps towards metric’s vision from day 0
It simplifies prioritization & decision making. Anything that doesn’t add up to the metrics identified can be parked to later phases of product building.

Finally, wrap up the PRD by pasting all those important resources which you feel are necessary for others to know.

This area acts as a resource dump area. Typically, it would have the founder’s mind-map, product references, any relevant articles talking about the problem, etc which will come in handy for any team members who would look into it.

We advocate all the Founders who come to us to follow these 5 simple steps to communicate their idea to us. This not just helps them, but for us too in understanding your idea without any assumptions.

A well-documented PRD is a reflection of clarity in the Founder’s mind & what better way to start the discussion?

Want to get started writing a PRD? You can find the template which we use here. Make a clone of it & get started in the right way

You can look at more such process we follow here

Get a quote