Product Managers are ultimately responsible for figuring out what to build and ensuring it is impactful.
Simple in theory, but not easy.
PMs have to source and process ideas from every direction, rationalize and advocate for which investments make sense, and hold steady in conviction about their roadmap while staying flexible for things to change as they learn.
For decades, the Product Requirement Doc (PRD) has been the instrument of the trade, the single source of truth for what to build and why.
In the 90s, PRDs spanned 20-30 pages and were meant to be the definitive record of every detailed change. With the evolution of agile development and the acceleration of software-centric businesses, product teams realized that static documents aren’t the best tool to represent dynamic creative work.
PRDs have miraculously prevailed, but Product Managers are still relying on the outdated concept of a single static document, which lands them in one of two ineffective camps.
At one extreme, the anxious Product Manager will spend too much time trying to create a perfect document that resembles a doctorate dissertation awaiting approval. This common failure mode shows up in teams that lack internal trust or have unclear ownership. The PRD becomes a process tool to solve a people problem.
At the other extreme, the overzealous Product Manager will spend too little time articulating their thinking, bypassing writing as a superfluous process that slows everything down. This common failure mode happens on teams that see a process as a barrier to progress, only to be met with a bunch of unresolved questions and problems to navigate downstream.
Neither view is ideal for modern product teams, whose work resembles any other creative pursuit: requiring enough constraints to get started, but also enough flexibility to enable new approaches or solutions as exploration gets underway.
Our Reforge members agree.
“As my team grows, I wonder if I need to go back to doing PRDs to get back into the “discipline of documenting what we’re building and why. We currently just document things in JIRA tickets, but it’s becoming increasingly messy as we grow.”
In this piece, we’ll help PMs think about PRDs as tools that enable progress rather than dictate prescriptive plans.
To get there, we’ll walk you through:
Of course, we’ll also share an in-depth example of a dynamic PRD, which you can use as a template going forward.
Meet The Authors
Natalie Rothfels is an Operator in Residence at Reforge and runs a leadership coaching practice. She has held product leadership roles at Quizlet and Khan Academy and was a classroom teacher before that.
Doa Jafri is an Operator in Residence at Reforge and an early-stage engineering leader. She most recently built and led teams at Glossier and Thrive Global.
Great PRDs Make Building Products Easier
First, let’s define what we mean when we reference Product Requirements Docs (PRDs).
PRDs are commonly an umbrella term for an evolving document that guides the development process by centralizing key information in one place that’s needed for alignment and the first steps of execution.
Or, as Fareed Mosavat puts it, a PRD helps answer “Should I build this? And how should I think about this effort?”
Instead of thinking about a PRD as a tool for refining their thinking and making progress, Product Managers see PRDs as:
A bureaucratic process or checkbox to barrel through
A useless exercise because things change are bound to change anyways
An unsolicited opportunity for others to give unhelpful feedback
A presentation to showcase their product brilliance
A log of decisions or user stories
Now that you know what one is, check out Natalie’s fully completed PRD Toolkit.
A good PRD may inadvertently alleviate some of these issues, but a great PRD focuses on none of them.
An effective PRD unlocks three key benefits that make building easier:
1. Enables alignment across leaders and teams
Great PRDs give teams and individuals the information and confidence they need to raise flags, ask questions, and iterate with minimal decision churn.
2. Unlocks cross-functional creativity and collaboration
Great PRDs leave space for cross-functional partners like designers and engineers to define the solution alongside PMs, leading to a better customer outcome.
3. Clarifies and pressure tests your thinking
The very act of writing forces our brains to think in a logical, structured way that others can then consume and interpret. This enables us to test if we effectively solve the customer’s problem, have a thoughtful plan, and have enough detail to take the first step on execution.
These benefits may seem like nice-to-haves, but they’re huge timesavers in the long term.
In fact, teams that don’t have them will suffer the following consequences:
You won’t remember what you decided (and why), or what you learned: Turns out, humans don’t prefer to think rationally. Slowing down to write articulate, clarify, discuss, and document your decision-making engages your System 2 thinking so that you can make more conscious and logical choices. In six months when your team is revisiting the same problems again, you can thank your past self for documenting your thinking effectively so you don’t make the same mistakes over and over again.
You won’t build collective intelligence and product intuition: Great product teams move more efficiently over time because they’ve developed a collective understanding of how customers think and use their product. Getting your thinking down in writing and bringing others along will help you build better products.
You won’t engender trust: People want to know that you’ve thought through something in a coherent way. The easier you make it for others to see your work, the less skeptical they will be in trusting your thinking. If they have no idea how you came to the conclusions you’ve drawn, they will have to fill in the gaps themselves.
You will struggle to get effective help and feedback: If people don’t know how you’re thinking about a problem or where you’re getting stuck, it can be difficult to know how to help. Think of your PRD as scaffolding that lets other people “climb up” to meet you where you are. Mediocre PRDs make it difficult for someone uninvolved to jump in and offer one bit of useful feedback.
Now if you focus less on the PRD as a waste of time and more on it as a tool to help you be more effective in the long run, you can easily avoid those consequences.
How a Dynamic & Evolving PRD Can Help You Build
So what’s the right way to think about PRDs?
Avoid trying to complete static, long, and overwhelming documents. Instead, you should think about it as a dynamic and evolving artifact that helps unlock the next stage of the development cycle.
Worry about your PRD being enough to get started, not about it being finished or perfect. Then update the PRD continuously as you learn more.
There are three main evolutions of a PRD that mirror the product development cycle.
Product briefs: also called product memos or 1-pagers. As the name suggests, these are typically concise single-page documents, sometimes with additional pages as an appendix. This is for clarifying the problem space and gathering early alignment on the investment focus area.
Product specs: also called Lean PRDs. These are typically 2-3 pages in length and are intended to inspire and enable conversation with cross-functional leaders around the solution space.
Full PRDs: also called 6-pager or traditional PRD. These can be 5-6 pages or longer in length. These are ultimately about unlocking execution and actually being able to start building something.
In this free PRD toolkit, we give you an in-depth example of a product brief, product spec, and the full PRD.
It’s important to remember that these three shouldn’t be viewed as entirely different documents.
Instead, these archetypes represent the evolution from a product brief to a full PRD. We find that the version we work on depends on where we are in the feature or product development cycle.
Let’s walk through how the document evolves as you go from one stage to the next.
1. It’s best to start with a product brief when we’re solving the problem space.
The problem space is where we are focused on identifying and prioritizing the most important problems to solve to achieve specific business outcomes.
A product brief is most appropriate at this stage because we are focused on getting input from company leadership on whether investing in solving the problem makes sense. A concise product brief ensures we get constructive feedback without going into too much unnecessary detail, leaving space for inquiry and dialogue.
Starting with a product brief is common for large-scope projects such as launching a new program, improving user onboarding, or increasing product retention.
A product brief typically includes descriptions of the following:
Opportunity: What is the problem we are trying to solve? For what audience segment(s)? Why are we prioritizing solving it?
Supporting Evidence: What evidence do we have to validate this opportunity and why are we best positioned to solve it?
Success Metrics: What are the key qualitative and quantitative indicators that will tell us whether or not we’ve addressed this opportunity?
Non-Goals: What are we not solving, and why not? Given we’re not solving these things, how does that impact possible success or failure?
Some briefs also include emerging hypotheses around the solution scope or user experience.
2. It’s common to expand a product brief into a product spec once we’ve solved the problem space and shifted our focus to the solution space.
The solution space is where we are focused on solving important problems that have already been identified and assigned.
A product spec is most appropriate at this stage because we have shifted our focus to creating the overall vision for the feature or product with cross-functional leads, as well as aligning on a high-level approach.
Using a product spec is common when we want to split large-scope projects into smaller medium-scope pieces. Continuing with our previous example, this could be improving user onboarding by fixing OTP (one-time password) authentication or increasing product retention by improving service levels.
To evolve your brief into a product spec, you’ll want to do the following:
Summarize or link out to docs that cover the problem space.
Focus the rest of the spec on the following:
Scope: What are the key user stories this feature will address? What functional requirements are in-scope for this project? Which of these requirements are must-have, and which are nice-to-have?
Experience: What do we want the user experience flow to be?
Risks: What assumptions or hypotheses may turn out to be false, and how do we plan on pressure testing them? What open questions do we need to answer, and how do we plan on answering them?
Your product spec doesn’t need to be finalized before you can proceed with development. You just need to document enough information to ignite meaningful conversation and then start building.
It’s okay – and encouraged – to return to your product spec and iterate on it later as you build and uncover insights you didn’t know upfront.
For example, when Natalie was building a new content marketplace product at Quizlet, her team initially thought that it was a requirement to enable students to rent rather than purchase content so they could spend less money. As the team started testing prototypes, it became very clear that students actually hated this concept, and felt like renting was a financial rip-off.
3. We can further evolve our product spec into a full PRD once we have a vision and overall approach to the solution.
A full PRD is most appropriate at this stage because we now need to partner with cross-functional ICs to map out the launch plan and execution details to bring the solution to life.
To evolve your spec into a full PRD:
Pull in your summary of the problem space
Include the latest, refined version of the Scope, Experience, and Risks sections
Add in the following:
Technical Implications: What, if anything, in the functional requirements do we expect to significantly alter the user experience? What metrics need to be instrumented for us in-product to gather data on feature usage?
GTM Plan: What is the feature rollout schedule for users? For each phase, how many users will we reach, and for how long?
Development Plan: What are the next steps or action items needed to accomplish this GTM plan? Who is the Directly Responsible Individual (DRI) for each action item? When does each item need to be done?
It’s important to create these new components - technical implications, GTM plan, and development plan - in collaboration with design and engineering counterparts.
The purpose of the PRD isn’t to dictate how the rest of the team will work. Instead, it should be used to provide a space where the team can collectively build an execution plan that works for all.
How to Know if Your PRD Enables Progress
Experienced product teams know that building is rarely a linear process. Trying to describe exactly what you’ll come across before starting any project is “a fool’s errand and creates a false sense of certainty in the process,” says EIR Behzod Sirjani.
“The best PRDs I’ve seen lay out the mountain we’re trying to climb, the first few steps we’re willing to take, and the general considerations we’re making as we move along the unknown path ahead.”
That’s why we encourage you to think of your PRD as a tool that enables progress rather than one that dictates a prescribed plan.
To check for that, here are some reflection questions for you and your team:
Do your PRDs enable alignment?
Can you clearly articulate what you’re trying to do and why?
Can you modify it appropriately to different audiences?
Can you highlight where there is likely to be agreement or disagreement?
If not, start with the product brief, then identify the areas your team is in agreement and disagreement before moving on.
Do your PRDs unlock cross-functional collaboration?
Are you getting valuable feedback and opinions from marketers, analysts, data scientists, or whomever else is critical to this project?
Do your meetings and discussion breed clarity, confidence, or connection?
If not, start with the product spec, then identify which x-functional collaborators need to be included and what would make it easier for them to engage.
Do your PRDs pressure-tests thinking?
Have we gotten smarter about the problem space, the solution space, or why we think this is useful work to do?
Is it clear to others why we’re doing this in the first place?
Are we able to have meaningful conversations about tradeoffs and risks that actually result in decision-making?
If not, ask someone outside of your team (perhaps another PM) to read through your product spec or full PRD and highlight to you which areas are least clear and where they got confused.
Do your PRDs unblock execution?
Do designers, engineers, and marketers have enough clarity on what we’re building and why so we can take meaningful steps towards building?
Can we track against some clear goals and milestones?
If not, come back to your product spec and work with your designer and engineer to identify the big risks and roadblocks to getting started.
Do your PRDs clarify what success looks like?
Have we clarified what success looks like such that we aren’t kidding ourselves after-the-fact and falling prey to the Texas Sharpshooter Fallacy?
If not, ensure that your product brief, product spec, and full PRD are all aligned on what success looks like. Make sure everyone on your team can name what success is before you start building.
Creating Better PRDs Going Forward
Let’s talk through where we’ve landed.
First, great PRDs should make building products easier. And building products is easier when you:
Are clear about what you want to build
Understand why it’s important to solve that problem, and what the world will look like when you do
Clarify the risks and the things you’re doing to mitigate those issues
Can anticipate what the roadblocks are going to be that may get in the way, and can elicit support around those things when you need it
Can learn from what you’ve done and don’t make the same mistakes over and over again.
These outcomes are easier if PMs see PRDs as a dynamic tool for thinking rather than a static document.
The evolution of a PRD can follow the ideal evolution of product development, starting with a product brief to align on the problem you’re solving and why it’s important. Then, a spec and full PRD can provide the scaffolding for deciding which solution to pursue and, ultimately, to build it.
Once you start viewing the PRD as an evolving guide to unlock the next stage of development, it’ll take the pressure off of trying to make it perfect and allow you to settle for good enough.
If you’re looking for additional support on how to build a dynamic PRD, we’ve got you covered with this full toolkit.