The One Thing You Should Avoid When Creating PRDs
When I first started out in product, I stole a PRD template from the internet and Frankenstein’d the living hell out of it until it worked okay for our team. The end result looked something like this:
You could repeat section 2 as much as you needed depending on the size of the project. I don’t know if you can tell by just looking at this outline (specifically item 2.5), but these PRDs ended up north of 20 pages long. Yes. 20+ pages of wordy requirements and overly-detailed user experience flows.
I blame my liberal arts degree and diagnosed Obsessive Compulsive Disorder.
As you can imagine, having a PRD exceeding 20 pages makes it extremely difficult to maintain, follow, and communicate changes. The engineering and design team had to constantly read the entire document as often as possible to ensure they haven’t missed anything and then ensure their own lengthy design docs were kept in proper alignment. Because QA plans were created from the PRD, there was no wiggle-room for mistakes, interpretations, or engineering/design freedom. This mostly resulted in a lot of misaligned design, development, and QA efforts that would end up having to be redone, costing us a lot of precious time.
Me when I present a 28-page PRD to the engineers that have to build it but have no say in the solution.
PRDs should be a living document that is being improved upon as the feature or product is being shaped, designed, and developed. But the value that flexibility brings is almost completely obliterated when the PRD comes overloaded with in-the-weeds details. That brings us to the one thing you should avoid when creating PRDs…
Stop focusing on the “how”
AKA…stop being a product dictator. AKA…you can lead the product without being a control-freak. AKA…your teammates have good ideas and you need to leverage them in order to make the best and most-agile product decisions.
The focus of my first PRD template was almost all put on the “what” and “how” instead of the “why.” The reality is, if you put enough information in the document to explain the problem and why it matters, the in-the-weeds details will sort themselves out naturally due to increased participation and collaboration with your engineering, design, and QA teams. You want to make a shift from dictating exactly how the product should function and instead focus on providing a ton of historical context, customer feedback, market trends, product limitations, and company vision so the “why” of a project is extremely clear.
Focusing on the “why” helps engineering and design think like a Product Manager because they are contributing to the solution and then making design and development decisions based on the vital information across all facets of the business, customer base, and market that they are not typically privy to. It also allows you as a Product Manager to achieve the absolute-best possible product because you are able to use the information and expertise from these very technically-savvy teams.
Lastly, you will make friends! Back in my 20+ page PRD days, I maintained friendships with the engineering team by cracking jokes and keeping the mini fridge near my desk stocked with 10% ABV tall boys. Now, I maintain friendships the completely authentic, sober, and non-manipulative way. In all seriousness, engineering and design having the ability to shape and contribute to the product solution that they will be building is really great for morale and growing relationships between Product and Tech (but I still keep tall boys on hand for emergencies).
My PRDs now stay in the 2–3 page range.
Conclusion
Focusing and communicating the “why” of your project within your PRD and then working with your engineers and designers on the best possible solution will help you build well-rounded, customer-concerned, product-driven, market-influenced, architecturally-sound products.
