Photo by Jonathan Kemper
The first time I found out about product requirements documents was like discovering super powers. No, really. I went from “Why are we doing this feature” and “Who are the target audience” and never receiving a definite response to now writing these documents for myself and the team, so nobody forgets what we discussed and planned several months before. These documents are an essential part of the way we work, just like a legal contract. And this is why we help you write them by generating from a template.
PRDs are used in many big and small companies. Giants like Spotify, Google, Amazon, Uber, Facebook are using these documents to plan and document upcoming features. A simple document helps everyone to stay in sync in terms of what you’re building and why. A well-documented requirement improves understanding while a poorly-made document can easily confused your whole team. What can go wrong here? Turns out many things.
Let’s go through a fictional scenario where you work for an imaginary IT department of a large hospital. During one of your quarter planning meetings you receive a document with the following intro:
Next quarter we need to upgrade our old queueing system and rewrite it from scratch.
The document continues with the required changes, timelines, affected customers, and other details like budget, design, etc. Would you approve this feature? Why? Or why not? Is this information enough to make a business decision?
The obvious flaw in this statement is that instead of describing a business problem we are greeted with a solution: queueing system upgrade. Instead of asking why, we get the what: a new queueing system. With that much information it is a pure gamble: your company can waste resources on doing work that nobody or just a handful of affected customers need. Let’s try to update it and include the missing bits:
Next quarter we need to improve our queue notification system as lots of messages are left undelivered.
This is definetely an improvement over the previous problem statement. We get the “why” which is messages are not getting delivered to the target recipients, however this still lacks important information: numbers. It is hard to make a weighted decision without knowing if we’re talking about 100 messages or 10 000? Is it daily or monthly? How does it compare to the number of delivered messages?
Business decisions must be backed by the analytical data. So we’re back at the dashboard and come up with a new description:
Next quarter we need to improve message deliverability in our queueing system since 12.5% of the messages are lost in transit or not getting delivered at all.
We have identified the problem, we know how many messages are lost, and we can potentially solve that with a new system. Sounds like a good plan! Except, it isn’t. Or rather not yet.
Every day about 1000 customers use our queueing system to book appointments, 125 of these never receive a confirmation. Sounds like a problem that needs solving as 125 customers can generate considerable revenue for us. But do we know how many of these 12.5% actually skip their appointment and never arrive? How many of these customers try to book again? What percent of these call or write to customer support? This data would help drill down to the core of the problem and find the monetary value of the solution.
Next quarter we need to improve message deliverability in our queueing system since 12.5% of the messages are lost. As a result, 38% of these customers call our support via landline and 7% contact via website which is ~11% of all of the support requests. An extra 3.5% of these customers never arrive for their appointment.
At this point it is clear how 12.5% of undelivered messages can cause financial losses to the business. We can start gathering technical requirements which might actually tell us we do not need a complete rewrite and instead might need a small update. We might want to discuss this with other departments and see if they are affected by similar problems. How critical this is to business and when can we possibly start the development.
It is important to know that at the stage of planning, a product requirements document is not a call to action but rather a call for discussion. A short and consice PRD can help the stakeholders make a decision.
In shipit we use ideas to discuss potential features and draft them into proper features. When these take shape, we convert ideas into roadmap initiative by placing them in the “Later” section and then assign scores to these in order to decide what goes into which quarter.
Sign up for a free trial to try it and automatically save your PRDs to Google Drive, Atlassian Confluence, or Notion.