Practical Blog ProductDo

The Worst Mistake You Can Make in PRD

In theory, everything is simple: one of the main tasks of a product manager is to understand what customers or users need and build a solution for these requirements together with the development team. Another task is to explain it to everyone in a short and understandable form.
For this, the PRD (Product Requirements Document) structure is used, and despite the fashionable term, these are just clear answers to the main “complex” 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.com, Spotify, Amazon, Google, and so on. Since dozens of projects/features are launched in such offices at the same time, the magic of a one-pager PRD document allows everyone, from a programmer to the CEO, to understand what is actually happening. Well, let’s see what can go wrong here.

Attempt #1

Imagine you are reading this PRD in the IT department of an airline:
Problem: in Q3 we need to replace the old booking/change ticket notification system with a new one.
<constraints/what/who>
Yup, so instead of a business problem, the author of this PRD is trying to give us a solution! Not that they are evil, it’s just that our brain is designed in such a way that it immediately says “yeah I understand it, it’s super easy” and the fact that the old system is bad seems obvious. By the way, those who like to read about our brain and thinking might want to check Thinking, Fast and Slow by Daniel Kahneman.
Now, getting back to our JPM: they replaced the complex question "why" with a simple question "what". There are two dangers of this mini text replacement.
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, "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.

Attempt #2

After getting some advice from you, 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.
<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 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 PRD 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.
<constraints/what/who>
Now we are talking! Are you ready to start developing according to such requirements?

Personally, I'm not ready yet. It is, of course, sad that 10% of messages are lost, but after all, we are an airline, not WhatsApp. How much does this affect the main business metrics of our product (flights)?
How many people call us and yell at support agents? How many miss their flight and then we have to deal with the re-issuance? How many of those 10% of users simply cancel their flights?
Or maybe these 10% do not need notifications: they bought a ticket, added it to calendar and forgot about it until they arrived on time for their flight? Then why would we waste time updating the system? There are 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. The objective of those cases was like this: we rescheduled a flight but the passenger did not receive any notification (because of those 10% failing to be delivered).
<constraints/what/who>
Now our JPM had it right! And now we can clearly see the problem: our "only" 10% of undelivered messages lead to quite serious consequences for business.
Then you can collect other requirements, for example, note that all your internal clients cannot immediately drop everything and migrate to your new system, etc. After that, assemble a team to think about technical limitations, say, you only have Python programmers in the team and you are partially in the cloud and then, after all, come up with the solution. It is very likely that you’ll end up with some other solution than “let’s replace the old platform with the new one.”
Is there anything else?
That seems to be it, huh? What else can go wrong here?
In fact, quite many things. Of the things that you, as a PM, are able to control, it can be "why don't you check it with other departments?"
It may happen that your new air delivery department has just developed a new system for their needs (notification to ground delivery services) and you can realize the dream of a software architect and reuse the 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.

To conclude

All in all, a short and clear PRD helps everyone (programmer, fellow OM, client, designer, tester, manager, CEO) to understand the problem in five minutes and make decisions at their own levels.
I hope this practical case helped you to better understand the importance of PRD, and how important a clear "why" inside it is.
If you want to get more practical cases and dig deeper into a daily work of a product manager in a big company, explore our simulators. We at ProductDo are always happy to share our first-hand experience.