PRD is a Map and Map is not the Territory
“The map appears to us more real than the land.” — D.H. Lawrence
The map of reality is not reality. Even the best maps are imperfect. That’s because they are reductions of what they represent. And the same goes with a PRD. The most common definition of a PRD calls it an artifact used in the product development process with the core intent to communicate. PRD is a mere abstraction of the PM’s version of reality! Typically a simplified one. It is a birds-eye view of reality as it is expected in the future. And it is bound to be imperfect! This is important to keep in mind as we think through writing effective PRDs and building better products as a community.
First PRD, anyone?
Almost every product manager can remember their experience of writing that first PRD. Looking for the best template out there, making sure it is descriptive enough still not drifting the team away to even read it completely and so much more. And if we flip the pages to a couple of decades back, interestingly, the very first mention of a PRD I could trace on the web is from April 2001. It was a template published by NASA for their Space Shuttle Program (Wow! That’s close to rocket science). Here the PRD was still a Program Requirement Document, closest to today’s PRD.
The actual mention of a Product Requirement Document can be found only in April 2002. PRD, as we know it today, is almost exactly described in the class notes from the Software Evolution lecture from the University of Texas at Austin.
What is very surprising is that the concept of PRD wasn’t popular until few years after the entire dot-com-bubble saga. Numerous online shopping companies and other tech companies got built and went bust before people even started talking about PRDs. And to anyone who is part of a Product company, this might sound impossible. PRD is a starting point for most of the tech/ product/ marketing/ sales discussions today. It is the foundation of any feature or product getting built out there. And probably that’s why PRD as a concept was taught in lectures of Software Evolution course? Let’s try to delve deeper to understand this relationship between a PRD and the feature.
The Relationship Between a PRD and the Feature/ Product
If I had to use an alternate word for PRD, it would be “abstraction”. And this relation of PRD::Feature is very similar to that of a Map::Territory. PRDs are necessary but flawed!
A PRD is essentially a description of the Feature or Product and — as Korzybski introduced in his popular paper — the description of the thing is not the thing itself! A good PRD is more of a guide on navigating through the product development journey. And if we get obsessed with the detail, the only way is to have a 1:1 map of the territory. Which would be overwhelming! Practically, the better way of navigating through reality is through some level of abstraction. And that makes PRD such a useful artifact in the process.
But still, almost every PM can find people complaining about the PRD not being “real” enough. And the common pattern here is that stakeholders often misinterpret this abstraction as dogma.
“When we’re following the map without looking around, we trip right over them.” — The Great Mental Models
Context is the King
Similar to any model (of reality), PRDs are most useful when we consider them in the context they were created. What was the product manager trying to achieve? How does this sway what reflects in the PRD? And is the described context still relevant?
Almost any good PRD or the templates out there starts with setting the context in one way or other. What is important to remember here is that a PRD can capture the expected reality only considering the visible constraints at that moment in time. Just because it made sense when it was written, there is no guarantee that it remains to be equally useful in the future. What gets outdated in most cases is the context. The faster an organization/ market/ target audience or the context is changing, the harder it would be to keep the PRD up to date. It is therefore in my opinion, very important to capture the context as much as possible. At a later date, if someone had to update the PRD, they would know what exactly has changed that makes PRD not so relevant anymore.
“Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.” — George Box
Three Important Considerations
In order to use a map or model as accurately as possible, we should take three important considerations into account: Reality is the ultimate update. Consider the cartographer. Maps can influence territories. — The Great Mental Models
Reality is the ultimate update
When we are in process of building the latest cool feature or making a new product for the adjacent market, it is good to have a guide on hand. Everything from developing a new UI to writing a new microservice or even enabling yet another API endpoint needs to be aligned to what users want and what is that the guide says. While a PRD helps us navigate this journey better, sometimes things on “territory” changes faster than they are described. We should update the PRD based on the experiences of the territory, and we need to enable feedback loops. The loops created by the builders and the growth titans!
The best PRDs in my opinion are built collaboratively. A PRD that also has links to the system architecture engineering diagram, and to the MRD, and has captured the views of Sales as well. While too much information can dissolve the purpose of condensation, capturing multiple perspectives and enabling feedback loops is vital.
Consider the cartographer
PRDs are often subjective. They reflect the values, beliefs, limitations, and barriers of the PM drafting it. PRD also represents the state of mind and priorities of PM. And we often tend to misread them as a common goal of the organization. This is similar to how we often assume that borders on maps imply the common interest of everyone contained in them. And forget that it is the cartographer who had the most influence on setting the shape.
PRDs — just like any model — are most useful when considered in the circumstances they were drafted. What was the metric that the Product Manager was trying to move? How does this impact the picture painted in the PRD? What would change if those assumptions or insights were not true anymore?
Maps can influence territories
This central argument was put forth by Jane Jacobs in her work, The Death and Life of Great American Cities. She traces back the influence of city planners who had come up with elaborate models about the design and management of cities without paying much attention to how cities actually functioned.
Building a model and then fitting reality into it has always lead to negative consequences at the least. Jane highlights that the cities were changed to match up with these new maps. It is a hint about the impact of fitting complexity into simplification. And a forewarning of how the description of something can change that thing itself.
Conclusion
Looking at these pitfalls, it feels like there is no way one can write or use a PRD effectively?! But still, PRDs are valuable artifacts in the product development process. We need to be wise about its limitations and accept the fact that this is an abstract description of something a lot more complex. It will always be subjective, representing a particular state of mind and PM’s version of how reality would look in the future.
This does not mean the description or PRDs are unusable. We often need an abstraction or condensed version in order to simplify and relate to the complex reality. Having a guide is important and necessary to align direction. But this should not stop us from incorporating the feedback loops and collaborate to line up to reality, as close as possible. Descriptions are flawed but useful. To be able to build great products, we must think beyond the PRDs.
