How I formulate and use my Product Requirement Docs
Product Requirements Docs (PRD) might be one of the product managers’ best friends. Personally, the PRD not only helps me communicate how a product or a feature looks like to the rest of the team, but also keep my thoughts in line and allows me to make more informed decisions about the next steps.
I have worked on many iterations of the PRD template that I am using now (and will probably work on even more in the future) and at this point, I feel that the current template, that I will showcase in more detail on this post, works effectively.
I start filling a PRD for each product or feature I am working on alongside my team, from the idea conception phase, even before we decide if we are going to build this or not. At the early stages it can be just a set of raw thoughts and I am trying to share it with the rest of the product team, asking for as much feedback as possible.
During the product brainstorming process, the PRD is a continuously updated draft, like a living organism, until the product team comes down to a final concept. So, here’s is how it looks like:
Intro
In this section, I use to store some basic information, so that the readers will have a basic understanding of what are they looking at and which people are responsible for crafting not only the document, but the described concept as well. I prefer a table format, including the following information:
- Product / Feature Name
- Target Release
- Related Epic(s)
- Document Status (Draft / Final)
- Document Owner
- Designer
- Developers
- QA
Objective
In this section, I am clearly stating the objective of the product / feature that this PRD was built for. Usually, it’s more efficient to be as short as possible, but still fully understandable by the reader. The fewer words you need to use to describe an objective, the more clear and specific it is. If you need more than one or two sentences to describe it, you may need to take a step back to the product or problem definition phase and re-evaluate if what you decided to build is the right thing or more importantly you have defined correctly the problem you’re trying to solve.
Background & Strategic Fit
Here’s where questions like “what is the strategic added value of this product to the company” or “how is this feature enhancing my product” have to be answered. Usually, I am trying to simply state how the product matches to the overall company strategy or how a feature is fitting to the product and contributes to the long-term product vision. If you can give a proper and convincing answer to this question, then you most probably can achieve many more like convincing the management to approve any resources you need, in order to move forward with product development.
Assumptions
This is the section that I would love to leave empty. But unfortunately, this is not possible in most of the cases. The more assumptions you make, the higher the chance to guess wrong. That’s why we call them assumptions after all and this is why it is so important to document them exhaustively. Usually, assumptions are related with how we think that the user will behave, or interact with the product. Market research and customer interviews have been the most important tools for me to help me verify my assumptions, minimising the risk of making important mistakes in the problem definition or product design phases. I suggest to try and verify every single one of your assumptions before moving forward in the later stages of product development.
Components
Whereas the previous sections could be filled in the early stages of a product or feature birth, this and the following sections differ. From now on, you are starting to describe how the solution you came up with looks like and how all the components that compose it, work together to solve the identified problem. In the components section, you have to thoroughly describe all of the components that constitute your product or feature.
Flows
The flows section, is where you need to describe how the components are going to interact so that the product or feature will work. It’s essential to add as many details as possible. By nature, a flow is usually best described visually with flow charts or something similar, but I’ve found it very useful to also add verbal description in this section. It helps resolve any ambiguity that could be created by the visual elements. You may also add any wireframes or prototype designs in this section, in case the product or feature you are about to build will have a user interface.
MVP
This could be a sub-section in the PRD, but I believe that this is maybe the most important one. Wether building a product (where you definitely need an MVP) or the simplest feature, I like to design a short-term solution as a subset of the fully-blown solution to help me test and hopefully verify some of my core assumptions as quickly as possible. So, in this section I am usually documenting how this MVP is going to look like, the necessary tasks that will take the product to this point and what I need to validate with this MVP in order to move further in the rest of the product development cycles.
Analytics
At this stage you have to write down, everything you want to measure regarding the product or the feature you are building. However, once you right down all the metrics you want to track down, take a step back and think if you really need all of them. Obviously, the more visibility you have in numbers, the better insights you’ll acquire for future developments of your product or feature. However, it occurred to me a couple of times to waste time and effort to measure things that did not actually offer any value.
Success Criteria
Well, this is the moment of truth. Here’s where you have to describe how success looks like for you. For me, it’s usually a mix of numbers and some qualitative criteria related both with the users and the well-functioning of the product or feature I am looking to develop. It’s critical though that your success criteria are valid, or else you may end up with a product or a feature that is ostensibly not working well and you cannot find why, no matter how hard you try.
Questions
The questions section is where the team or any reader can add their questions regarding the product. The questions may concern any assumptions made (see the section above) or anything related with how the product is designed or working. What I love about this section, is that people with minimal to full context regarding the product or feature can contribute and even a very simple or minor question can give you a brand new idea about the product or show you something you’ve missed.
As mentioned, the shape of the doc described above has been through many iterations and will definitely go through more. Depending on what you are building, you may make any necessary changes in the format that serve you or match to your own style. Despite the iterations that this template has undergone, I’m always trying to keep the basic pillars there, so that I can keep a stable train of thought in my own product thinking and also align the thinking of my team mates, so that our product development process will be seamless. It also makes it easier for the rest of the company that have no to minimal context about a product, understand why and how we build it.
