Writing a Product Requirements Document is a really important part of Product Managers’ role. Every PRD goes through multiple stakeholders, developers, QA Engineers, Designers, Marketers, Sales people, support team and almost everyone in the organisation. It is like the blueprint of the product (or feature) to be built hence it has to be perfect and easy to understand.

A PRD should be enough to make an impact and to convince everyone that yes this is something we need to build and it is going to make a huge difference (before that, you need to convince yourself the same backed by data and research 😉 ).

So, if you’re planning to write an effective, painless, and perfect PRD, let’s not wait!

When should you start writing a PRD?

Every Product Manager starts writing a PRD at some point of the product lifecycle, some do write it once the ideation phase starts, some do write it once they are sure on what to build, some write it when a developer asks 😉 while some don’t write at all. I’ll share my personal experience on when do I start writing a PRD.

Whenever an idea strikes me, I ask myself for the uncountable number of times, “Is it worth it?”, “Will this make an impact?”, “Is it something my customers are going to love (or remotely like)?”, Hope this is not a big mistake.

Once I convince myself of the above questions, I start digging. Dig into the data, dig onto the internet, think through it multiple times, and come up with a strategy. And tell myself, “Okay, this is going to be great! Let’s do this.” And this is the time where I open up confluence, set the Goal, set the purpose and get started with it.

The Purpose of the PRD should be effective. It should be convincing enough for everyone to believe that this has to be built. Remember, this is the source of truth and you have to make an impact effortlessly. Everyone reading it should be able to relate why is this feature important, why it has to be built. The Goal of the PRD should be able to convince and explain the same.

The Goal has been set, so now what’s next?

Once the Goal of the PRD is set, now the question comes, what is to be added next? Well, every PRD has a target audience for which you’re building a feature or the Product. The research on the same can never be enough. As I mentioned above that I dig and when I dig, I need to be the master of the same.

So, when you decide something has to be built, you need to research on it. Not one day, not two days, but endlessly. You need to be a master of that thing.

Remember, anything you are building is not for you, not for your team members but it is for your users. They are the ones that are going to use it. So, you need to make sure that after you are convinced, ask them, is this going to add value for them? Conduct user surveys, go on calls with them, talk to them, ask them, email them, whatever it takes. And once you have enough data, create user personas.

If you want to know more about creating user personas, you can go through this article by Hotjar.

Time to Write some good user stories

When you talk to the users, you’ll also come up with pretty good user stories. So, it’s time to break down the user problems into multiple, small user stories.

“A user story is an informal description of the use case written from a user’s point of view which describes the problem the user is facing”.

A user story generally goes like: As a user, I’d like to do ___. The user stories should be short, clear, and focused on a single problem at one time. So, note them down, note them all down.

By now, you have pretty much set up the base for your PRD. You have set the Purpose, Defined the audience, mentioned the problems that it’ll solve. So, Why and for whom is done. Now it’s time to define the What.

Yes, now we’ll move to the features.

Define a Sharp Feature Set

User stories are pretty much the reflection of what problems this feature or product will solve but for the developers and QA engineers, you need to be more specific in what needs to be built. Hence, we need to mention the clear feature set.

So, here you need to define that you will be building these all features and this is how they are going to work.

Chalk Out the User Experience

It is really difficult to explain a feature to someone without a wireframe, so create some lovely wireframes (rough would work too 😁), add them step by step with a brief explanation of how that’s going to work screen by screen. These wireframes should be self explanatory enough for someone looking at them to understand how this works. Small prototypes, if added, would be great too!

If you got the designs ready, you can add them as well.

Once this is all set, it’s time to work on the release planning.

Plan the Releases, Set Milestones

Release planning has to be done very smartly. Make sure you have already discussed the same with your engineering team and they are on the same page as you in terms of man hours required for the same. So, all the features you planned have to be divided into milestones, dates for the minor releases are to be set. Make sure to add a buffer for few days depending on your industry and your team as last minute delays are always inevitable.

Just like that, your roadmap and strategy is set.

I’m assuming you already considered the timeline based on the current pipeline and planning you’ve already done. 😉

Go for the MVP model if this is a bigger product.

Mention the Risks Involved

Here comes the tough yet the most important part. While digging, you must have already considered the risks which were involved in this feature (or product). Let’s make it public. Mention the risks involved in it and propose a solution for the same so no one gets their heads wrapped around it at the last moment. This is important as the engineering team needs to know and assess the same before starting the development.

By now, you’re almost done with 80% of the drafting. Now comes one more important part (did I say important again? Oh yes, this is important. The work that you do is important. Remember, it makes a difference 😃 ), the success metric.

Define the Success Metrics

For Product managers, creating something is a waste unless you measure it. So whatever you are creating should have a success metric linked to it. So, define the metric that you’ll be tracking in order to measure the success of the feature (or product). It can be anything that is directly or indirectly being affected by the change you are introducing.

Future Roadmap

Here you need to mention the future roadmap and strategies for the feature/product that you’ve built.

Go to Market- Growth Plan

Once you have built the feature, it’s time to market it now. Chalk out a plan, consult your marketing team, and write it down. Here, you need to mention what are the actions the team needs to perform in order to make the launch successful. It can be anything like writing blog posts, sending email and notifications to the users, conducting webinar, doing press releases, etc. Once you do it, you’re all set!