A great Product Requirement Document (PRD) unites a team around a project.
It serves as a blueprint, guiding the development process from start to finish.
It defines a “finish line” – the point at which the team’s job is complete.
This post will cover the ingredients of a great PRD, highlighting the key elements that should be included to ensure its effectiveness. We’ll explore the three concepts you need to understand to create a PRD that sets the stage for a successful product development journey.
This post focuses on each of the key elements of the following statement:
“A great PRD is collaborative, accessible, and prioritised.”
Each section correlates to one of the above aspects. They provide justification and guidance on how to replicate them in your PRDs.
There is no right answer when it comes to creating a PRD. Every project is different, and the PRD should be tailored to suit the product’s and team’s specific needs and requirements. It’s about understanding the audience and purpose of the PRD for that project and crafting a document that serves as a valuable tool for everyone involved.
Let’s get stuck in.
A great PRD is collaborative
“A PRD is not a set-in-stone dictate of what a product should be; it is the start of the social process called design, and to varying extents, there is room for negotiation.”
The primary goal of the PRD is to align everyone involved in the project on the priorities and specifications of the product. Without collaboration, there is no alignment. When the PM dictates the PRD to the rest of the team, we lose the feeling of teamwork.
While the PM owns the PRD, it should coalesce the views and expertise of all teams involved.
Collaborative PRDs are better
In our experience, situations where the engineers have taken an active role in the PRD have tended to be more successful.
A PRD informed by a real engineer’s experience is grounded in reality. This ensures the document is realistic and achievable within the project’s constraints.
The PRD can be seen as a puzzle. The PM is the only one that places the pieces together, but each team/expert in their own right influences their respective piece.
Everyone’s Resource, Everyone’s Responsibility
As our friend Carl Bettag says;
“It’s not a real thing if it’s not in the PRD”
Keeping the PRD up-to-date and ensuring that all stakeholders are informed helps maintain alignment and fosters a sense of ownership and responsibility among team members.
As engineers, we are responsible for effectively communicating our expertise and views to the PM. We can’t expect the PRD to reflect it if we don’t do that – PMs don’t read minds.
Balancing Collaboration and Control
Keeping this collaboration in check is essential – the PM needs to decide what’s required and what’s not. It’s their job to listen and understand the views of engineers and then make decisions about how that’s reflected in the final PRD.
A great PRD is accessible
Electrical requirements can inform the mechanical components of the product – that’s why the team needs access to the entire PRD, not just their section.
This sounds obvious, but we’ve worked on projects in the past where the PRD was gatekept, hidden behind layers of confidentiality. It’s usually a symptom of a lack of trust and hampers the team’s ability to do their work. It limits creativity by reducing their input on the project to what they’re directly responsible for.
Get the level of detail right.
For your PRD to be read, it needs to be readable.
Nailing the level of detail is the first step towards a readable PRD and a successful project.
Too detailed and your PRD becomes an Engineering Requirements Document (ERD). Too high-level and it ceases to become useful to the engineers who need to design a product.
We’ve had the best experience on projects with a PRD and ERD. It might sound redundant, but having the ERD as a more specific and technical version frees up the PRD to stay high-level – like an executive summary of the project’s components.
Key to nailing the level of detail required is appreciating the following:
“The truth is that the uncertainty is never gone — just hidden. There are infinite real-world variables in building software products — in constant motion. Any comprehensive document is laced with hidden assumptions: the API docs are correct, the data is reliable, our polls are unbiased, etc. You only remove uncertainty by shipping.”
While this is clearly a reference to a PRD for software, the same concept applies to hardware. Examples of similar assumptions in our world are:
- The IP testing goes well,
- We’re able to pass FCC certification on the first try,
- Power consumption is as forecasted, etc.
- The product passes reliability testing
Internalising this puts a ceiling on the level of detail worth going to. Even the most detailed, dense, descriptive PRD leaves room for uncertainty by making assumptions. It’s an inescapable fact. It’s on you to choose how much uncertainty you’re willing to have (and where you want it).
Attempting to eliminate uncertainty by getting too specific isn’t just ineffective – it’s impossible.
A great PRD is prioritised
If everything is a high priority, nothing is a high priority.
The effectiveness of prioritisation lies in the differentiation between its levels. Make your use of each level of priority consistent and intentional.
There is a tendency to put a lot in the must-have, only for engineers to point out that we’ll run into problems with all those hard requirements. For example, the product will be too expensive, big, power-hungry, and too late on schedule.
In real projects, low-priority features often get left out.
This happens because low-priority features aren’t worth enough to the company (otherwise, they’d be a higher priority). Revenue is king; companies run and grow on it. Low-priority features would add unacceptable cost or delay to the project and are often promptly slashed by the C-suite.
Prioritisation allows for flexibility
The PRD can suffer from being a rigid document in a dynamic world. Engineering and product design is constantly moving and adapting to new influences. Deadlines slip.
Properly implemented prioritisation in the PRD allows for flexibility within the PRD. Despite changing what’s written in the PRD, priorities mean there’s a range of success rather than one exact version.
Flexibility in the PRD also helps in managing trade-offs between competing priorities. For example, suppose a new feature is proposed mid-development. In that case, the team can assess its impact on the project timeline, budget, and overall goals and decide whether to incorporate it into the current iteration or save it for a future release.
Conclusion
A well-crafted Product Requirement Document is more than just a list of features; it’s a strategic blueprint that unites a team around a project. It clarifies project priorities, defines a clear “finish line” for engineers, and serves as a north star for the whole team.
Three key concepts must be understood and implemented to create a great PRD: collaboration, accessibility, and prioritisation.
- Collaboration is essential – A PRD shouldn’t be a dictatorial document but the start of a collaborative design process.
- Accessibility ensures that the PRD is readable and available to everyone involved in the project.
- Prioritisation is essential to focus on what matters most. By distinguishing between priority levels and using them intentionally, resources are used effectively on the most critical tasks.
By understanding the importance of collaboration, accessibility, and prioritisation, teams can create PRDs that are valuable tools for guiding successful product development journeys. Let’s aim for PRDs that unite teams, provide clear direction, and set the stage for successful outcomes.