The PRD Burger Sauce 🍔 - Part 1
Product requirement documents, also known as PRDs, vary from company to company, and even from PM to PM within a company. In this 3 post series I share my secret sauce to make the best PRD.
After closing my startup I understood I wanted to work as a PM and started applying to places. I have never worked at a big company as a PM before and didn’t know all the terminologies nor the processes. As part of the interviews, it was common that I would be asked to create a product requirement document (PRD). After doing some research on what a PRD was, I managed to create a template that I used. It covered all the necessities. At least I thought it did. When I presented my PRD to the hiring team, every company would look for or request different items. There was no structured format they all agreed on.
Over the years of working as a PM I have noticed that there is a general understanding of what a PRD should have in it. How it is presented and what it actually holds makes a really big difference for clarity, context and getting approvals.
Having a good ‘go-to’ template helps. It creates consistency across a company and a common language for all. Over the years I have improved my template. It covers all the critical parts and will help you, as a PM, make sure the idea is clear to you and to others. It will help you pass the message along in a way that will keep people focused and not puzzled. I use it for several cases and I'll elaborate on that as well during this 3 post series.
Below you will find the content of my template with explanations about each part.
The breakdown:
Motivation
Business value and use cases
Flow overview
Detailed requirements
General comments
Goals
KPIs
North star
Secondary metrics
Counter metric
Design/mocks link
Events link
Copy/text link
A/B test details
Let’s dive in.
Motivation and business values are the first two things I focus on when I start writing a PRD. This part usually takes the longest to complete (at least for me) and is critical as it will set the context and reasoning to why this PRD has the right to be done. It will also show how it fits to the company’s plans and strategy.
Motivation
Why are we working on this?
This is different from our goal, but of course connected. Here we state what got us to pursue this.
Some examples are
Data we reviewed. It could be qualitative from user interviews / reviews or it could be quantitative such as our users’ engagement with our product.
Research. This could be a research task for us to get to know our users better or their personas.
Business needs. While everything can be seen as a “business need”, the idea here is that the drive is coming from the business, which isn’t always right, but needs to be done. For example swapping a current provider’s API to another due to a new contract (there could be many reasons to do this, usually cost is the main one).
Business value and use cases
By now we understand the motivation for writing this PRD. But who cares, right?
I might be motivated to do a lot of things. They need to be aligned with the company’s mission/goals. We need to make sure it drives the business forward. Don’t confuse this with the ‘business need’ I mentioned in motivation. They might be related but not identical.
Some examples are:
Increasing our self-serve motion
leveraging an acquisition channel we have but do not do much with
While we always want to do things for our users and to benefit them, this is still a business and we must remember that. We shouldn’t let JUST the business drive us, but it should definitely be on our mind. If we can’t think of the business value, we need a really good reason to continue with the execution of this PRD.
Flow overview
Once we discussed the WHY (motivation and business value), let's discuss the HOW. Based on the complexity of the feature I present this differently to the forum. I usually write out the flow (A user lands on the home page, the user clicks on ‘Get Started’....). I write it out in bulleted format so it's easier to read.
If there are several journeys users could go through based on the different actions they take, I define and share that here as well. I think that having wireframes/low fidelity mockups provides extra clarity here and is wise to have.
NOTE: It is VERY important to explain that these mockups are not the final version but a very general ideation in order to share my thoughts. Design and final flow might look very different. I won’t go into the ins and outs of this, but it is very important that the team understands this in order to work at our best. I have seen many PMs do this part without mocks and it works fine. It's really whatever works best for you. Lenny and Ravi discussed this as well and I recommend listening to it regardless.
To summarize, always start with the why. This will provide clarity and context to you as well as the forum. The motivation and business value will cover that. Make sure to really spend time and think שbout it, this is the basis for the whole PRD.
The full flow will connect the why with the how. Mocks make it easier to explain but are not a must.
In the next post I'll discuss the more technical part of the PRD:
Detailed requirements
General comments
Goals
KPIs
North star
Secondary metrics
Counter metric
Let me know how your PRD sauce is different and why.