Using Product Requirement Docs for Scoping Features & Uncovering Unknowns
Using Product Requirement Docs for Scoping Features & Uncovering Unknowns
Write things down. It'll help you & your team scope the work, discover issues before they arise and get aligned. (#50)
I like writing things down. Writing helps clarify my thoughts. It forces more prescriptive and transparent sharing compared to meetings, where ideas are exchanged verbally. Writing reveals gaps and encourages structure. It’s harder to go off on a tangent when writing versus meetings, where the loudest person in the room dominates. Writing equalizes people’s ability to share ideas. (Note: Although I’m using the word “writing” this is also true of doing any visualizations; i.e. customer journey maps, diagrams, etc.)
In product management, we use Product Requirement Documents (PRDs) for scoping features. It allows you to take an idea (from the most nebulous to the most precise) and map it out further. It forces people to be thoughtful about what gets built (or doesn’t!) and exposes gaps in people’s understanding of why they’re doing something.
Nothing of any significance should be built into your product without using a PRD. I’ve used them to scope Minimum Viable Products (MVPs) before, which can be fairly extensive. And I’ve used them to scope small features, which have a tendency to balloon as you write things down. Scope creep remains one of my all-time favourite buzzwords. 🤣
Here’s my PRD template. You’re welcome to copy it and use it as you see fit.
Next, I’ll break the template down, piece by piece.
Then talk about how you use PRDs for big and small features.
Then share thoughts on where I see new founders or less experienced product people make mistakes with their products (which PRDs can help uncover).
Finally, I’ll share other templates that I like.
Let’s get started…
My Product Requirement Document Template
Here’s a screenshot of my template, which we’ll dig into below.
1. What problem are we trying to solve?
Every PRD starts with the problem. If you can’t articulate the problem clearly, don’t keep going. Instead, go “back” and do more customer discovery. Talk to more users/customers. Dig into your data. Figure out where the pain is and how you might prioritize that pain.
If you’re using the PRD to scope the initial MVP, then you really need to understand the problem deeply. I’ve written about this before.
My structure for a problem is User + Need + Insight (or Deeper Need). While describing the problem, you also must define who has it. Ideally you have an insight (or at least you’ve validated a deeper need—one that’s social/emotional versus functional) that you’re anchoring everything on.
You also explain how you came to the problem. What work was done to validate it? This is helpful for providing context to other team members, but also to “check yourself” — did you really do enough digging?
2. What are our assumptions / hypotheses?
Everything you build is an experiment. You may have a lot of evidence that you’re right, but you won’t know until you put it (feature, project, MVP, etc.) into people’s hands and see how they react. That’s why we highlight assumptions / hypotheses in the PRD.
A hypothesis is structured as follows: “We believe [something is true] and we know we’re right if [this happens / we measure this result].” You setup experiments based on what you believe is true, and you’ve defined the test and its success criteria.
This is akin to applying the scientific method. There needs to be rigour to your experiment design and execution. Note: You’ll likely never test things as rigorously as scientists, in a controlled environment, but the more you treat what you’re building as an experiment, the better off you’ll be.
I’ve gone into depth on assumptions and how to use them, and provided a simple Assumption Tracker you can use.
3. What are we building?
Describe, as succinctly as possible, what you’re building. Incorporate “why” into this to reinforce the reasoning (and to double check that your reasoning is sound). For example:
A dashboard for paid users to visualize their current financial status. The dashboard needs to include A, B and C in order to give users a quick snapshot, which they need on a weekly basis to understand Z.
Free users will see the new dashboard, but won’t have full access. We will share A with them, but then encourage them to pay in order to unlock the full experience.
This is similar to an epic in agile methodology. It’s high level and in this case fairly big.
For experienced product managers and teams this may be enough to break up the work into smaller features (stories in an agile context) and get started. For less experienced teams, I encourage them to write more. The risk is that everything is prescribed by the author (and we find ourselves using a waterfall methodology) but as long as others contribute, this section of the document becomes a living breathing scope document that helps really define what is being built.
4. How long will it take and who will work on it?
At this stage you may not have everything defined clearly enough to scope effort accurately. Go with basic t-shirt sizing: S, M, L (you can include XS and XL, but I find that’s overkill). This is important to gauge whether you’re biting off more than you can chew and need to break things down further.
Write down who will do the actual work. This will depend on people’s availability and when you’re planning to do the work, and on people’s expertise. For example, you might have a developer on your team that’s familiar with a particular section of the code base.
It’s also important to define key stakeholders. Who else has to be involved? In a corporate context, if you’re building products within large companies, this list might be fairly extensive. You want to define this upfront because it’ll have a significant impact on how the work gets done.
5. Risks
Everything has risk. Even small features have risk. It’s important to think through this and do so collaboratively with everyone. You might be trying to build a new feature that’ll touch part of the tech stack with a lot of tech debt. Or you might have dependencies tied to a 3rd party or another team.
A product manager’s job is to look around corners. If you don’t think through and write down the risks they have a habit of coming back and biting you in the ass.
6. Metrics / success criteria
If you’ve listed your assumptions / hypotheses, then this work may be done. You need to define “winning.” How will you know if what you’ve launched is working? Did you solve the problem? Did you create value?
You need to measure success qualitatively and quantitatively.
Especially with bigger features / projects, don’t rely exclusively on quantitative data. Actively engage users/customers. This is where your customer success team (if it exists) is crucial. They’ll handle the positive and negative feedback from what you ship. Sales too, because they might want to leverage what you’ve built to drive sales. Turns out you can’t ship features / projects / product in a vacuum, everyone needs to be aware of what you’re doing, why you’re doing it and how you measure success.
I’ve written extensively about how to use metrics:
7. Future feature ideas
I’ve never met a founder, product manager or startup team that doesn’t like talking about what else can be built. Don’t shut down immediately. Great ideas may emerge. But you can’t build everything at once, you need to break things down into smaller, deliverable chunks.
I use the future feature ideas to accomplish two things:
Capture everyone’s input and make them feel heard (+ good ideas may come out of this!)
Proactively define tradeoffs. For example, someone might say, “We absolutely need X built.” You can add it to the PRD or you might say, “Let’s put that into the future feature ideas.” They might respond, “Absolutely not, we need it NOW!” (Let’s assume they have a good reason with evidence.) You can now say, “Sure, but we need to take something off. So let’s swap with Y, and move it down to future feature ideas.” I’ve laid this out as a rational conversation. It doesn’t always go that way because people want everything, all the time, instantly. Your job is to rationalize that, and use the PRD as a way to factually scope the work.
Using PRDs for Small and Big Features
Using a PRD for small features is (relatively) easy. You might be tempted to skip this step, but don’t. I would spend the 30-minutes it takes to write things down, collaborate with others (developers, designers, executives, etc.) and sharpen your pencil on what has to be built.
Product Requirements for Small Features
A PRD for a small feature should have:
Crystal clear clarity on the problem, ideally with quantitative data that validates the problem (i.e. “We’re only seeing 10% of people complete X. If they don’t complete X they can’t get the value of Y. So we need to increase that %.”)
1 or 2 key assumptions / hypotheses because the test is relatively small. For example, if you’re making a small change to an onboarding or activation flow you have minimal variables to deal with and a clear experiment to run.
A small t-shirt size. Small features should not take big effort. If a small feature requires big effort you need to have a commensurate hypothesis that suggests huge improvement.
Minimal risk. Small features should not have huge risk. If they do, you need to be very clear about it and question whether it’s worth making the change. It all comes down to impact.
BTW, in my experience, what often starts as a small feature becomes a big, complex feature through the PRD. The exercise of writing things down unlocks a bunch of other requirements, debates, etc. that have to be sorted out. If you don’t write things down and get alignment, these issues will come out too late. The PRD gives you the tool to openly have these debates and make better decisions.
Product Requirements for Bigger Features
A PRD for a bigger feature is more complex. If you’re building something bigger you need to define the scope very clearly. This likely includes:
A much more granular description of the feature(s) being built.
A visualization of the customer journey / workflows being created; you want to define step-by-step how people will interact with the new feature(s) and how they affect users’ existing behaviours with the current product (if it exists).
Mockups (low and/or high fidelity) of what’s being built—it’s important to bring the scope to life through visuals.
A breakdown of milestones and how you might deliver the bigger scope iteratively.
PRDs for bigger features should help you uncover unknowns. This is a critical job for product management and product building teams. You should be constantly asking yourself, “What don’t we know?” Big problems rarely emerge out of what you know (and how you use that knowledge to build product). It’s the unknowns that get you.
As a PRD is being written, encourage everyone to jump in and ask questions.
“If we do that, won’t it affect that other thing?”
“Why would we build X that way?”
“Did you think about how doing X will change Y?”
“You need to consider these other variables if you want to build X that way.”
“How will you handle A, B and C?”
PRDs are discovery documents.
They emerge as requirements documents, and can evolve into scope documents but they start as discovery documents.
Discovery: Start every project asking key questions: Who, What, Why, How and When. The PRD has spots for all of this.
Requirements: Define the requirements to answer key questions. Ask more refined questions as you go along.
Scope: Lock in the scope, get into the nitty gritty, and get building.
PRDs for bigger features often get out of control. They become extremely long and overly prescriptive. I still err on the side of “more versus less” in these scenarios because otherwise you’re going to miss things. This is also why writing things down in a collaborative document is so powerful; nothing should get lost and the trouble spots will become apparent based on where people are commenting or editing heavily.
Don’t worry about following the same PRD template for small and big features. Filling out the PRD isn’t winning, capturing the details and forcing yourself (and others) to think through them is the point.
Things That People Often Miss When Writing PRDs
There are a few things that people often miss writing PRDs, especially less experienced product builders. I’ll admit, some of these are nitpicking, but the process of thinking through them and making that a habit is important.
Error states: When people write PRDs they usually focus on the “happy path” (i.e. the expected path they want users to go through), but shit always happens. What are the possible error states? How do you handle them? What does error messaging look like? Is there any standardization to it?
“Weird” data entry: Happy paths rarely afford for people entering “weird” data. For example, someone might put in a dollar value with four decimal places. How do you handle that? Someone might put text where numbers should go or vice versa. Someone is using a field the “wrong” way. Often “weird” data entry breaks things because it wasn’t contemplated in the scope. That’s bad and you need a standard way of handling these situations. Sometimes users are trying to do things in unexpected ways, which you have to figure out and understand.
Blank starts: Have you ever logged into a software product for the first time and shown a “blank canvas”? It drives me nuts. They’ll typically present a tutorial or walk through, which everyone skips because they want to dig in. Then they realize they don’t know how to. Every time you build a new feature think about that first user experience. Is it easy? Is it clear? Does it fit seamlessly into their day and how they’re using your product already?
Edge cases: There are anticipated and unanticipated edge cases. You need to define the anticipated ones; edge cases that you know might happen, and then you have to decide if you’ll address them or not. In some cases you might ignore an edge case, for now, even though it may lead to user frustration.
Time to value: How quickly will a user get value from what you’re building? Is that fast enough? How will you measure this? Time to value (TTV) is not prioritized by product managers and teams as much as it should. People who ignore TTV often over-build, instead of stripping things down to their core with a focus on generating value as quickly as possible.
Other PRD Examples
Here are two other PRD examples that I find helpful:
Lenny Rachitsky’s PRD: This is very similar to mine. It’s clean and simple.
Kevin Yien’s PRD: This one is awesome. Kevin used this when he was Head of Product at Square (he’s now Head of Product at Mutiny). Kevin’s PRD is much more in-depth. It’s what I use most commonly for big features (I use my template for smaller features or as a draft of initial thoughts). Kevin’s goes into more detail, including defining non-goals, key flows and logic, the launch plan, change log and FAQ. I appreciate how Kevin’s PRD allows you to really dig in and ask better questions. You should uncover a lot more unknowns through this framework, including more edge cases.
Courtesy of a tweet by Carl Vellotti I came across ChatPRD by Claire Vo, which is your “on-demand Chief Product Officer.” Specifically it can help you draft PRDs from scratch. I tried it out and it’s pretty cool. Give it a whirl and see what you think!