The Ultimate Guide to PRDs
Pro tips for writing a great Product Requirements Document
Your PRDs are part of your legacy as a product manager. Love them or hate them, Product Requirements Documents (aka PRDs) are a big part of a product manager’s life. We use PRDs to describe the problem that needs to be solved and how our team will solve it. Everyone in your company will look to your PRDs to understand what your team is building, and years from now, your future colleagues will dig up these docs to learn about past features.
Unfortunately, most new product managers don’t get any training on how to write a PRD well. As a new PM, you probably got assigned a problem to solve (or a feature to launch 😛), and someone told you to write a PRD. They probably sent you a link to a PRD template and expected you to figure it out from there. That’s how I got started, and 10+ years later, I’m here to share PRD lessons I’ve learned the hard way.
Today, we’re talking about five critical mistakes product managers make when writing PRDs and how to avoid them; then, I’ll walk you through my process for writing great PRDs and (bonus!) I’ll share my PRD template with you.
Five ways PRDs fail (and what to do instead)
Mistake #1: Your customer problem is a solution
A product manager’s job is to figure out what problems are most important to solve for your users, so in every PRD, you need to describe what user problem you’re setting out to solve. A big mistake I see PMs make is describing the customer problem in some variation of “our app can’t do X,” where “X” is a feature the product doesn’t have. You’ve just described a solution, not the problem.
We include a description of the user problem in our PRDs to paint a picture of the user’s world so that everyone involved with designing the solution has the context of the pain we’re trying to fix. When you describe the problem as “our app can’t do X,” you’re missing the opportunity to help everyone understand your user’s world.
What to do instead:
The customer's problem should be from their point of view, not yours. Instead of describing what your product can’t do right now, explain why users want it – what will it help them achieve? What pain point will it fix for them? Your PRD should paint a vivid picture of who the user is and the problem they are facing.
Mistake #2: You don’t have success metrics
Success metrics are the quantifiable measurements you’ll use to determine whether your feature was successful. They are your goals. Every feature you launch should have a goal. We’re running a business here, after all. Failing to define the goals upfront is a big PRD mistake. Without success metrics, your team won’t know what you’re aiming for, and worse, after you’ve launched the feature, you may disagree on whether or not it was a success.
I learned this lesson the hard way. As an associate product manager, my product area was new user onboarding, and I was responsible for the product’s user activation metrics. One of my early features improved the user activation rate (a higher percentage of new users were activating their accounts) but negatively impacted average spend per user (new users were spending less on the platform). So, was this feature a success? Unfortunately, I didn’t define what success should look like upfront, so everyone argued about it.
What to do instead:
Your PRD should define the metrics and measurements you’ll use to determine if you’ve successfully solved the problem. Consider what success will look like, and describe in your PRD how you will know if we've solved the user problem. How you define success will vary depending on your business, strategy, team goals, and other factors. Success could be determined by the adoption and usage of the feature or how your feature impacts other business metrics. Most importantly, make sure you will be able to track the metrics you’ve defined.
Mistake #3: You’ve given too many details, stifling creativity
This is a rookie mistake that a lot of product managers make. They put too much detail into their PRDs, making the requirements too prescriptive. This backs their team into a corner where only a single solution is possible, killing creativity. Here’s another video to explain this problem.
Tiktok failed to load.Enable 3rd party cookies or use another browser
The example I gave in the video above is pretty simplistic. Not using the words “can push a button to…” in your user stories can definitely give your team more space to be creative with their solution ideas, but here’s another less obvious example:
Recently, I wrote a PRD for a startup team. The company faced a big user problem: their customers were overwhelmed by their product. The product keeps track of a user’s activities on their computer to help them understand how they spend their time. Users typically had hundreds of recorded activities at the end of the day, leaving them overwhelmed trying to make sense of it all.
Many people at the company already had a solution in mind; they wanted to use data science to cluster similar activities together so that users would have a smaller, less overwhelming set of things to review at the end of each day. My task was to write a PRD for this clustering feature, but as I started writing, I realized we were leaving other solution options on the table. If I narrowed in on “clustering” from the start, the PRD would be too prescriptive and could stifle other creative solutions.
So I took a step back. Instead of naming the PRD “Activity Clusters,” I called it “Activity Aggregation.” The requirement was to find ways to “aggregate” (not “cluster”) similar activities to reduce overwhelm. I stopped using the word “cluster” and deliberately talked to the team about “aggregation.” Why? Because clustering is a specific data science method, a specific solution, I wanted everyone to step back and think about alternative solutions, especially any that might be easier and faster to implement. Ultimately, the team designed and tested two solutions. Clustering was one solution. The second solution was a simple filter on the activity list to give users a sense of control. Clustering would take some time to refine and get right, but filters were easy to build, so we could immediately deliver value to users. The language used in the PRD and our team meetings made all the difference; it opened the team up to additional creative possibilities.
What to do instead:
Be careful with the language you use to describe the requirements in your PRD. Focus on the user’s problem and what’s required to solve that problem. Even if you have a solution in mind, resist the urge to describe a specific solution in too much detail. Try to describe the requirements as generically as possible so that your team can think creatively about solution options.
Mistake #4: You didn’t define the scope
Great PRDs include boundaries– they tell the team what is in scope (what must be part of the solution) and what is out of scope (what they should skip). Without boundaries, your team won’t know where to focus and could get bogged down in unimportant details. As the product manager, it’s your job to describe in the PRD what is most important to your user and the business so that your team can stay focused on the most important things.
What to do instead:
You need to prioritize. Tell the team which requirements are most important so they can focus on those first in the limited time you all have to build a solution. I like to break up requirements into three buckets:
Must haves - these are use cases that the chosen solution must address. They are the most essential requirements for our users and our business.
Nice to haves - these are requirements that we’re willing to live without. We want our team to focus on building the “Must haves” first and only work on these if they have the time to spare.
Out of scope - these are use cases that we have explicitly decided we will not solve now.
To determine how to bucket your requirements, go back to your success metrics and consider the minimum requirements to achieve success as you’ve defined. Those requirements are your “must-haves.” Anything else is either “nice to have” or “out of scope.”
Mistake #5: You left out the why
The last PRD mistake we’ll cover is a big one – leaving out the why will leave your team unmotivated. Businesses don’t exist to build technology for technology’s sake. You need to explain why it’s vital for your team to work on solving the user problem. Without a strong rationale, you likely won’t get approval to start work in the first place, and even if you do, you’ll have a hard time convincing your team that it’s important to work on.
What to do instead:
Your PRD needs to build a strong case. You need to explain why it’s important for your company to solve the problem. Consider the benefit to your customers and the business if you can solve the problem successfully. Describe the opportunity and add some urgency to the mix; explain why focusing on it now is important. Include customer quotes and data to help the team feel your customers' pain and the opportunity on the other side when you launch the best solution.
How I write PRDs
To maximize collaboration and creativity, here’s my process for writing and using PRDs:
Start with the four critical sections.
Every company has its own version of a PRD template (if yours doesn’t have one, you can borrow mine here!), and no matter how long your template is, I believe there are four sections of any PRD that are the most critical. They are 1) the customer problem, 2) the why, 3) the success metrics, and 4) a prioritized list of requirements.
Whenever I draft a PRD, I start with these four critical sections. First, I’ll write the customer problem and the why – it’s essential that I clearly describe the problem our users face and why our company should invest in solving it. Next, I define the success metrics to tell the team how we will know we’ve solved that problem. Finally, I work backward from the success criteria to list the requirements in priority order by considering what must be true to achieve the success criteria.
Notice I haven’t defined a solution yet. I like to write “TBD” in the solution section of my PRD drafts because I want to discuss options with my teammates first.
Collaborate to get the best solution.
PRDs are best used as a collaboration tool. I fill in the four critical sections first to frame the problem for my team; then, I schedule working sessions with my teammates (my product design and tech lead partners at a minimum) to explain the problem to them and discuss possible ways to solve the problem.
Make adjustments.
As these discussions and working sessions start, I adjust the PRD. The PRD should be treated as a living document, not a locked spec. Your PRD should be the cornerstone of collaboration, so update it regularly as you work with your team and the plan evolves.
There are two areas in particular you’ll want to keep updated:
Your list of requirements. You’ll probably need to clarify the requirements and re-order them as your design and engineering partners start to weigh in on how to solve the problem.
Keep track of assumptions, risks, and dependencies that teammates and stakeholders point out.
Finally, when your team has decided on a solution to pursue, go back to the solution section of the PRD and fill that in. I like to describe the solution as a hypothesis; it’s a bet our team is making.
Keep the source of truth accurate.
As work begins to build the chosen solution, you’ll inevitably encounter roadblocks or edge cases you hadn’t planned for. When these things come up, update the PRD so your document won’t get stale. And come back to the document post-launch to link to or add details about what happened. What did you learn? Was your hypothesis correct or proven wrong? What will you do next? Your future self (and colleagues) will thank you for keeping excellent documentation of decisions and outcomes.
Want more help with PRDs and other product management skills?
👉 Get my PRD template to write product specs like a pro here
👉 Book a 1-on-1 training call with me on Skillshare here
👉 Check out my Product Management Foundations course, launching in January 2024, here
You got this!