Why you should always write a detailed Product Requirements Document
And who really reaps the benefits
Photo by Windows on Unsplash
If you’re a new PM or looking to break into product management, I’m sure you’ve already heard about the Product Requirements Document. You’ve probably heard that it’s a list of requirements that needs to be built as a new product or feature.
Often, new and even seasoned PMs forget the value of writing a detailed document. I have been guilty of this myself. Sometimes we don’t have as much time as we’d like. And we reason to ourselves that nobody really reads the doc anyway, right? People usually give us a call when they have a question. As long as the details are in our heads, we’re good to go. And we resort to a few lines on a spreadsheet or a couple of slides on a PPT.
But the truth is - a PRD is so much more than just a list of features. There are a number of stakeholders who rely on this document as a source of truth, and plenty of good reasons to keep writing them. When written properly, a PRD is the most important tool in a PM’s arsenal.
In this article, I’ll cover the anatomy of a good PRD, the different stakeholders, and ways in which writing a PRD can help you as a PM.
The anatomy of a good PRD
As I mentioned earlier, a PRD is more than just a list of features. I’ve seen PMs write a bulleted list of UI screens and call it a PRD. And it always makes me think - well, no wonder nobody is reading your docs! It needs a lot more useful information if you want it to be used as a source of truth.
The first section of your PRD should always have the why and the who.
What is the objective or the problem statement?
Who is the user of this feature?
Then comes the data section. This part contains all the market research you’ve done. This can include
Support tickets from existing customers
Product usage and adoption data from various tools
Competitor product analysis
Next is the part you’re familiar with - the feature list. Now that you have clarity about the reason you’re building this feature, who you’re building it for, and what the current status of the market is, you can finally get to the details. This section typically includes
List of features and use cases
Rough mockups to visually represent your ideas
First-time discovery and Onboarding
We’re not done yet. The list of features is only half the story. It’s important to outline the various impact areas, especially if you’re working on a complex product.
How to position this feature across various pricing plans (if you’re working on a SaaS product)
Do you have a mobile app? How is that impacted?
Do you have a marketplace? Are there integrations and API changes to consider?
Is there any data migration required for your existing customer base?
This list of impact areas must be built by you over your journey as a PM because each product has its own unique constraints. If you’re in the fintech industry, you’ll have to add a section for risk and legal. If you’re in e-commerce, you’ll have to consider supplier and vendor impact.
Finally, we come to post-release items.
What is the GTM plan for this feature? How are your customers going to hear about it and start using it?
What are the success metrics for this feature? How will you track them? Are there any additional events that will have to be configured by the development team?
The various stakeholders of a PRD
Some companies have a document-heavy culture, which is being further reinforced by the new normal of remote work. More people are working in an asynchronous manner, and this makes it even more important to have a master document that captures everything,
At the same time, there are still many companies whose culture is still heavy on meetings and calls. In such cases, even a brilliantly written PRD will need to be explained in person at first.
But this doesn’t mean that your PRD will remain forever unopened. Once you’ve spent that initial meeting explaining your feature, that’s when the real work starts for the other teams. At that point, it is helpful for them to have a checklist or a reference to use while doing their part.
In the absence of a thorough doc, you are likely to be bombarded with messages all day like “What opens when the user clicks this button?” and “What happens if there are no records?”. These messages eventually snowball into meetings, and we know what a waste of time that can be!
Remember that while you have the details clear in your mind from the beginning, not everyone does. And it’s your job to ensure that the others get there too.
These are the main stakeholders of your requirements document.
Designers: They need to understand the problem and the user they are designing for, as well as the complexity of the feature
Developers: They need to understand the different flows expected so that they can plan the architecture, the backend, and the frontend development accordingly.
QA: They need to write test automation and manual test cases, and will need help in understanding what’s considered a bug and what isn’t.
Marketing: They will be preparing content and will need to understand the user and the problem statement so that they can tailor the content appropriately.
The rest of the product team: Other PMs will invariably work on features that impact yours. Or ownership could change and they might end up working on the same feature someday. They’ll need a place to verify all impact areas and decisions taken.
The most important stakeholder
At the end of the day, YOU are the most important stakeholder. Throughout the entire product development process, you are the person who is expected to set the direction and drive things forward. You’re expected to know every little detail and make hundreds of little decisions throughout the life of the feature.
And we’re just talking about one feature here. Realistically, you’ll probably be doing at least 4 or 5 of these in parallel at any point in time. Maybe more, depending on your level of seniority.
I hate to be the one to break it to you, but - you’re NOT a superhero.
It’s ridiculous to expect yourself to keep all these things in your head, and be able to access them whenever someone needs it. Would you ask your user to remember a bunch of data when you could easily store them in your DB and provide a search experience? No. Then stop expecting it from yourself.
Putting things down in a document removes them from your mind and gives you the bandwidth to focus on other important things. The tiny details can reside in a doc. Your brain is destined for better things.
Ways in which a PRD can help you
Free up your mind
As mentioned above, PMs are polymaths who work on multiple things at the same time. You may have every little detail in your memory, but that’s an awful waste of your brainpower. Putting the fine print in a doc can free up your mind and make you more creative and sharp in the long run. It can create the space for long-term strategy, vision, and innovation.
“If you’re always being forced to make decisions about simple tasks—when should I work out, where do I go to write, when do I pay the bills—then you have less time for freedom. It’s only by making the fundamentals of life easier that you can create the mental space needed for free thinking and creativity.”
Be better equipped for negotiation
Negotiation is a large part of a PM’s job. Many times, a perfect flow simply cannot be compromised even if it increases engineering complexity. When we have a detailed document that outlines a clear objective and tons of market research, it can go a long way in helping us persuade other teams to take difficult decisions. Which of the following arguments would you trust?
“This is a really important feature, all our customers will definitely use it!”
“We’ve received 57 tickets from existing users in the last 4 months asking for this upgrade. Also, 4 out of 5 competitors provide this functionality so we might end up losing customers to them.”
Expert Power
Expert power is a form of power where you have sway over people by being an expert at something. Your knowledge and skill give you credibility and convinces people to listen to you.
Let’s face it, as PMs, we don’t have any other kind of power or authority. We’re nobody’s boss. We can’t build features by forcing anybody to listen to us. The only tool we have is our knowledge of the customer and the market and what’s best for the product. Putting these down in a structured PRD can signal to others that we know exactly what we’re talking about because we’ve clearly done the heavy lifting to become an expert.
“To use expert power in your career, pursue expertise in your field. When you demonstrate a high level of competence, people may begin to defer to you or follow your advice because of your experience.”
Download our free PRD template
If you’ve read through this article and you’re a little worried about where and how to start, we’ve got you covered! Here’s a template that’s been tried, tested, and improved by PMs with many years of experience.
Remember - this is just a starting point. It’s up to you to customize it as per your company and your product’s needs. Some of the sections in this template may not be relevant for you, and you may think of new ones that are specific to your product. Be sure to keep making edits to this doc throughout your journey as a PM.
Can we have a feature to bookmark articles please? Would really ease filtering through so many.