Three Bad Approaches To Writing PRDs, and How to Fix Them.
Let’s examine some wrong ways to write a Product Requirements Document (PRD) and propose three steps to fix it.
One of the main tasks of a PM is to understand what customers or users need and, together with the development team, build a solution for these requirements.
There is a bridge in the middle — a clear and concise document that aligns everyone with a PM’s thinking. This document is called PRD (Product Requirements Document). Despite the fancy term, these are just answers to the main “power” questions.
- What is the Business Problem?
- What are the constraints?
- What and when will we do?
- Who does what?
This structure is used in all big companies: Uber, Booking, Spotify, Amazon, Google, etc. Since dozens of projects/features are launched in these companies simultaneously, the magic of a one-pager PRD document allows everyone, from a developer to the CEO, to understand what is happening. Well, let’s see what can go wrong here.
Attempt #1
Imagine you start reading this PRD in the IT department of an airline:
Problem: in Q3 we need to replace the old email notification system with a new one.
<Details: constraints/what/who>
See the problem with this “problem”? If you want to practice, stop here and try giving feedback to the Junior PM who brought it to you.
No, really, think for 20 seconds at least 😊.
Okay, so instead of a business problem, the author of this PRD is trying to give us a solution and replace the complex question “why” with a simpler question “what.” This small text replacement has two dangers.
Firstly, the company might spend a year or even more on a change that no one needs. Not all old systems are bad; a lot of deep banking and aviation software work on code from the 80s.
Secondly, predefined “what” kills the creativity of the team in the development and product departments. After all, perhaps there are other solutions to the same problem, and some of them might be more efficient and faster, but they are automatically discarded since the “correct” one has already been chosen by a product manager.
Attempt #2
After getting some advice, the JPM comes back with the updated PRD:
Problem: In Q3, we need to improve the conversion of message delivery: now many of them do not reach passengers.
<Details: constraints/what/who>
What do you think about that one? Feel free to stop here for a moment to think about a possible answer.
This formulation of the problem is much better: at least the question “why” is clearly visible, but something is still missing. It seems to lack numbers and connection with business: what is “a lot?” Is 100 a lot? What about 1000? Per day or month? This problem definition needs some more improvement.
Attempt #3
Here is an update:
Problem: In Q3, we need to improve the message delivery conversion rate: now about 10% of messages per day do not reach passengers.
<Details: constraints/what/who>
Now we are talking! Are you ready to start developing according to such requirements?
Personally, I’m not ready yet. Of course, it is sad that 10% of messages are lost, but we are an airline, not WhatsApp. How much does this affect the main business metrics of our product? How many people call us and yell at support agents? How many missed their flight, and do we have to deal with the re-issuance? How many of those 10% of users cancel their flights?
Or maybe these 10% do not need notifications at all: they bought a ticket, added it to the calendar, and forgot about it until they arrived on time for their flight? Then why would we waste time updating the system? There are (always) more important things to do.
Attempt #4
Our JPM tries hard and seems to be getting there:
Problem: In Q3, we need to improve the conversion of message delivery: now about 10% per day do not reach passengers. About 24% of these passengers call support, which loads it up to a peak of 85%. Moreover, 2% of passengers end up canceling their trip. Finally, in the previous quarter, we had to litigate in 16 cases (claims for missing flights due to absence of confirmation).
<Details: constraints/what/who>
Now our JPM had it right! We can clearly see the problem: our “only” 10% of undelivered messages lead to serious consequences for businesses.
The rest of the PRD
We just solved the first part — the business problem. The rest of the PRD requires you to think through the causes of this problem and potential solutions.
- Maybe you need just a simple bug fix in an old system (then stop writing PRD and add a JIRA ticket instead).
- Maybe you need to invest in a retry mechanism. Ok, then list your requirements — how often you want to retry, after how much waiting, etc.
- Or maybe you need a whole new system, then list all the features you want to see there.
Last check: socialize your idea
Before you start implementing the solution, cross-check your ideas with other departments. Things can surprise you even here!
It may happen that your air delivery department has just developed a new system for their needs (notification to ground delivery services). You can realize the dream of a software architect and reuse a single system for two cases. Programmers have closed their eyes with pleasure now, and I, a developer in the past, too :)
Or maybe your company has more serious problems (for example, the pricing platform is broken), and then your boss / CEO will ask you to switch your attention and development there.
A short and clear PRD helps everyone (developer, fellow PM, client, designer, tester, manager, CEO) to understand the problem in five minutes and make decisions at their own levels.
Note how crucial it is to define the beginning of it (product problem) right and avoid the three most common PRD dangers: 1. Instead of the problem, PM states the solution immediately. 2. The problem is not quantified. 3. The chosen metric of a problem size doesn’t reflect the actual problem size.
I would like to thank Tremis Skeete, Executive Editor of Product Coalition, for his valuable contributions to the editing of this article.
I also thank Product Coalition founder Jay Stansell, who has provided a collaborative product management education environment.
