When one of my latest PRDs was picked up in the sprint, I had a few realizations on this concept that I never though it before. Coincidentally, at that time I was also reading The Great Mental Models by Shane Parrish which also motivated me to this school of thought as well. What intrigued me was how a PRD and a Map are only a description of reality. And a lot more happens on the “territory” which doesn’t get captured on the “map”. But these limitations and flaws are what makes a Map or PRD useful.
While am drawing links between a PRD and a Map, both are orthogonally opposite in a way. A map is built for existing territory but a PRD is written with a (hypothetical) feature/ user story in mind for a (part of) product that doesn’t exist.
Map = snapshot of reality as it was in the past
PRD = snapshot of reality as it is expected in the future
This is a thought experiment & my personal experience about building better products while acknowledging the inherent flaws of artifacts used in the process!
“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 Product Requirement Document (PRD) calls it an artifact used in the product development process with the core intent to communicate.
PRD is merely an 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?
When I had to write my first PRD, it was overwhelming! 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 I believe that almost every product manager can relate to this experience of writing that first PRD. While googling the best practices, I got curious about the history of PRDs. 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.
Digging further, 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.
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. Understandably, PRDs are flawed but necessary.
Moreover, similar to how any map has a scale defined, PRDs are most useful with a clear scope laid out. Not everything can be captured in the description. And one can't target solving all the (product) problems with one cool feature. Similar to how creating a map needs access to the ground investigation or other maps (of a larger scale), writing a PRD needs insights from the users. I personally prefer connecting with the users over a call or engaging through their feedback posts or support chats.
Almost every time I wrote a PRD, I could find my team grumbling about it not being “real” enough. And until a few weeks back, I would have similar thoughts while going through the PRDs written by my friends or colleagues. The common mistake we all were making was to 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 influence what is reflected in the PRD? And is the described context still relevant and to what extent?
Almost any good PRD or the templates I have come across start 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
Lenny Rachitsky has curated the best PM templates out there from our favorite product companies. These have helped me personally to tweak and attempt writing efficient PRDs.
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!
My personal best experience of writing a PRD was from the one that was 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. The important questions I ask while looking at any PRD (including my own) are: 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? And what alternate approach I could have taken towards this problem?
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 for all of us on 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. Doing research and talking to (potential) users is the easiest way to define the 'scale', and capturing 'context' is the best way to keep PRDs valuable. Descriptions are flawed but useful. To be able to build great products, we must think beyond the PRDs!
cover image via. pexels.com/@slon_dot_pics-129524