Jory MacKay on April 06, 2021 How to write a lean PRD (product requirements document) for your next project in 5 steps (with free template)
🎁 Bonus Material: Free one-pager PRD template!
A product requirements document (PRD) is one of the most important documents for teams using traditional project management. However, an increasing number of Agile teams are starting to see the value of adding more planning to their process.
At first, this seems counter-intuitive. Agile is all about staying lean and adapting to user feedback, right? So why bother writing out a bunch of requirements that are going to change after your next sprint retrospective?
Jump to a section
The awkward truth is that 70% of projects fail due to a lack of requirement gathering. Yet despite this, too many teams think Agile is an excuse to build blindly.
So how do you balance the structure of long-term planning and resource gathering with the flexibility and feedback-driven nature of Agile development?
Enter the one-pager PRD: A simple, concise document that gives your team and stakeholders a vision of what you’re making, clarifies user stories, and ensures you’ve thoroughly thought through your product’s requirements.
In this post, we’re going to run you through how to research, write, and present a product requirements document that’s actually useful and valuable, no matter what software development process you use.
What is a product requirements document? (And how it is special?)
A PRD is a document that describes the purpose, features, functionality, and behavior of the product you’re about to build.
While a statement of work or project plan will dig into the specifics of how you’re going to build a product, the PRD is more focused on what is being made.
Most people would associate this with the waterfall (or traditional) development methodology, where you create a detailed plan of what’s going to be made before you start building.
However, Agile teams are taking an increasingly adaptive approach to project planning, by constantly adding requirements to their backlog and prioritizing them as they come up. But beyond just playing a functional role in your product’s development, a one-pager PRD can quickly become your team’s guiding light.
The essential elements of a lean, mean one-pager PRD
Choosing what goes into your PRD is a balancing act.
Too much information makes the document an obstacle to your Agile development. Too little, and it can’t deliver those important benefits we just discussed.
To get the best results, your PRD needs to contain the following key elements.
- Product specifics: What are the essential details regarding the product creation process? For example, who’s on the team? What’s the current status of the project? When’s your release date?
- Goals: What is your team trying to achieve with this product release? How does it fit in with your business objectives?
- Background and Assumptions: What’s your why? What made you start work on this product? Maybe you’ve identified a new trend in the market, new competitors have launched, or customer interviews have revealed a new opportunity. Whatever the reason, record it in your PRD along with any assumptions that have influenced your decision.
- User Stories: What features will the product include? Write up or link to your user stories, along with any relevant information needed to clarify those stories, such as interviews you’ve carried out and what metrics you’ll use to measure success.
- Design and user interactions: Your design is an integral part of the product and should be addressed in your PRD. Include your most high-impact wireframes and mockups for your features and specify how the user will interact with those features.
- Problems to solve: Although your PRD shouldn’t cover how you’re solving your users’ problems, you have to know what those problems are. It’s likely your understanding of those problems will need to increase, so include any outstanding questions you have or any additional research you’ll need to carry out.
Finally, a PRD can also include what you’re not doing.
Knowing what you need to work on is obviously necessary, but being clear on what you’re not doing can be just as important.
This is especially true when you’ve identified features that are potentially useful—and may even be implemented in a future release—but are not a current priority. To keep your team from being distracted, call out these features and make it clear they’re not to work on them (at least not yet).
If you don’t know what you’re aiming for, how will you know if you’ve achieved it?
How to write a product requirements document (PRD) in 5 steps
Now, it’s time to put it all together so...
Start by selecting a place where your PRD will live–preferably somewhere it can easily be updated and accessed. This is a living document that will evolve along with your project. So make sure that you’re using a collaborative tool like Planio team wiki.
Not only does a wiki give your team’s knowledge and document structure and clarity, but by keeping everything inside your project management tool you can quickly reference specific issues or projects, link to documents and code repositories, or even follow pages to get notified when changes happen.
With the right tool in place, let’s run through a simple process for actually writing your PRD.
To do this, we’re going to break the document down into four sections inspired by product executive Marty Cagans original guide to PRDs:
- Product Purpose
- Features
- Release Criteria
- Schedule
Editor’s note: Interestingly, Marty no longer advocates using a PRD. This isn’t because he thinks they’re ineffective, but because it’s easy for product managers to spend too much time working on them and not enough on the actual product. By keeping your PRD lean and focusing on the essential elements, you can still enjoy the benefits without spending undue time and resources putting it together.
Step 1: Define your purpose
Elements covered: Product specifics, goals, background and assumptions
If you don’t know what you’re aiming for, how will you know if you’ve achieved it or not?
Writing down these details forces you to get specific about who the product is for and why you’re building it. As an added bonus, it can also highlight any gaps or ungrounded assumptions you’re making.
Your purpose should be as clear as humanly possible. If anyone on the team is unsure or still has questions, then it isn’t clear enough. If there are any gaps, don’t ignore them. This will form the foundation of your PRD, so it has to be rock solid.
Here are a few simple questions to answer in order to fill out this section:
- What’s the elevator pitch? How would you describe your goal in one or two sentences? What makes this different or unique from what’s out there currently?
- Who is it for? Think about your ideal user(s) and how they’re going to interact with your product. Name them if possible and write a brief description.
- Why are you building it? What do you know about the market, user, and your own company’s goals that make this the right product to build? What assumptions are you making about all three of those categories?
Don’t confuse your purpose with the solution. Defining your purpose should help you have a clear picture of where you need to go, spelling out your destination. It is not a map of how to get there.
Step 2: Describe your features
Elements covered: User stories, designs and interactions, problems solved
How will users actually use your product?
Here’s where your PRD gets into the meat of your next project by answering some key questions about the proposed outcome.
- What are the core elements of your product (from the user’s perspective)? How will your users interact with your product? Are there terms they need to know? What’s the flow of your core interactions?
- What problems are you solving for your users? Why should they care about this? Here’s where you can use your user stories to connect your ideal users to their desired features and outcomes.
- What will the product look and feel like? Include a few key mockups or links to prototypes so that everyone on your team can connect what’s in the PRD to how it should look when it’s finished.
Again, clarity is essential. Your description needs to be sufficiently detailed, explaining the specific ways your users will interact with the product (without going as far as prescribing a definite solution).
This should build on your work from the previous step, rather than being a standalone exercise. The features you describe should be clearly mapped to the product goals you listed in the first step.
If you have a feature without a goal, is it really a necessary feature? If you have a goal without a feature, how can you expect your product to be successful?
It’s your job to understand and communicate dependencies and gather requirements. Having requirement traceability built into your PRD helps you understand how your features relate to your goals, enabling your team to make smarter decisions and fully grasp the impact of adding or cutting those features.
Step 3: Set release criteria
Elements covered: Release goals, what you’re not doing
How will you know when your product is ready for release? As an Agile team, you’re used to regularly shipping software. But what we’re talking about here is simply setting goals for when your product will be ready for testing (as opposed to the more technical pieces you’ll add during sprint planning).
Think about setting goals around these five criteria:
- Functionality: What needs to be included in the release? What are the essential features or functions that can’t be missing?
- Usability: How easy and effective do the core functions need to be? How important are UX and design at this stage?
- Reliability: How consistent should the product be? What level of failure is acceptable?
- Performance: What will be the minimum expected performance? How fast should it be at carrying out required tasks?
- Supportability: What levels of ongoing maintenance and support will be possible (or are realistic)?
To be clear, this step is simply about setting goals. Not coming up with solutions.
Equally as important is being clear about what you’re not going to do. Setting release criteria helps you know when you can drop user stories or push them to a later release.
While this step will undoubtedly involve more technical details, this is still about the destination rather than the exact route you’ll follow to reach that destination.
A PRD spells out your destination. It is not a map of how to get there. Don’t confuse your purpose with the solution.
Step 4: Set a timeline based on constraints, not dates
Elements covered: Timeline, budget, and resource constraints
A PRD shouldn’t have an exact timeline as it can hold you accountable to features or decisions that might change due to feedback or changes to the market (which is something Agile was developed to avoid!)
Instead, a better option is to build your PRD around constraints. In the last section, you wrote out the product constraints–what you’re building and the minimum acceptable release criteria. In this one, you’ll write out the workflow constraints.
Timing, budget, and resource constraints give you a more accurate way to work backward and assign realistic sprint lengths. Here are a couple of questions to help you clarify the workflow constraints you’re working with:
- What’s your ideal launch date? When do you want to go to market or start beta testing? Is this flexible? By how much?
- What are your other constraints? Do you have budget issues to consider? Are other teams dependent on your release? What other resources are you short on?
Step 5: Share with stakeholders for feedback
Finally, a short PRD is a great opportunity to get early feedback and buy-in from stakeholders.
This document isn’t meant to be written by one person and then locked up never to be seen again.
While you need to work with your core team to create the document, everyone involved in the project should have the opportunity to review it and add their thoughts. This is where keeping it somewhere public like a Planio team wiki is such a great option!
However, asking for open-ended feedback can sometimes be a disaster, especially when you’re dealing with people outside of your core team. Make sure to set the context and be clear about what kind of feedback you’re looking for:
- Explain that this document is a guide. Let them know that it is a guiding document for what is being built and not how you’ll get there. Ask them to think through it from the user’s perspective rather than as a part of the team.
- Ask if your assumptions are correct or if you’re missing any key considerations. Did you go into writing the PRD with the right assumptions? Are there key elements that they think you’re missing?
- Ask about additional constraints: Stakeholders often have insight into constraints and upcoming business decisions that you don’t. What do they know that could impact this project before you get started?
A (slightly longer) PRD example: Product Hunt
It’s one thing to understand the benefits of a PRD, but when you start following the steps it can get confusing.
What information is essential for your product? How much detail should you go into? In an effort to keep things lean, it’s easy to miss out on vital information. At the same time, a PRD can quickly become bloated with unnecessary details, taking up too much of your team’s time and becoming so large that nobody wants to review it.
If you’re looking for a great (albeit, slightly longer) PRD example, the team behind Product Hunt has shared their original product requirement’s document.
Product Hunt’s PRD is especially good at answering the specific questions of who it’s for and why they’re building it. They then dive into the what, covering the different user stories and including mockups of what they might look like.
As a bonus, they also include previous iterations (“Old stuff below”) to allow the team and stakeholders to track how ideas around the product have changed over time.
Why spend the time on a PRD? How to sell your Agile team on the need for a one-pager product requirements document
Done correctly, a product requirements document can offer Agile teams several significant advantages, all on a single page.
But if your team is skeptical, here are just a couple of the big reasons why they should consider using one:
1. A PRD creates a shared understanding across teams
Creating and releasing a product is a team effort. However, if even just one team (or teammate) is pulling in the wrong direction, you’re going to have problems. At best, you’ll face delays and communication issues; at worst, lack of cohesion could derail the whole project.
A PRD answers the core questions about your project in a simple and concise way.
As Jerry Cao from UXPin explains:
“You should be able to ask any 5 team members about the overall purpose, features, release criteria, and timeline for the product and they should give you roughly the same answer.”
By getting all those details down into a PRD, you have a reference that anyone on your team can check at any time. With a one-pager, you have the additional benefit of a concise description that’s easily skimmed.
2. A PRD helps break Agile teams out of ‘product tunnel vision’
Technical teams have a bad habit of jumping straight into how they’re going to build products and solve problems.
This is only understandable. When you spend your life immersed in the technical details, it’s easy to think that’s what your users care about most. However, the truth is very different. As Martin Cagan of the Silicon Valley Product Group explains:
“An all-too-common mistake, especially in high-tech companies, is to assume that if you like your product, then your customers will too.”
Rather than obsessing over what specific technology you’re going to choose or being at the bleeding edge, a PRD forces you to think through your product from the user’s perspective.
And while a PRD is a powerful way to do this, it’s not the only tool you can use. In fact, Amazon bakes this right into their product discovery process.
Before any feature can be built, the product manager is first required to ‘work backward’ and write an internal press release announcing the finished product. This helps them keep their focus on the customer problem, rather than fancy new tech.
While you may not want to write a press release every time you start a new project, a PRD can achieve the same outcome by keeping your attention on what the product needs to accomplish from the user’s perspective.
3. A PRD helps you gather requirements in an Agile world
Lastly, and most obviously, a PRD helps Agile teams bridge the gap between high-level product requirements and the implementation details of the development-team.
Gathering requirements is tricky in Agile and can even seem counter-productive. However, rather than spending vast amounts of time and effort on requirement gathering, a lean PRD delivers the best of both worlds.
Master the delicate art of documentation in Agile and your team will thank you
Documentation can feel like a waste of time when you’re running an Agile team that’s constantly changing and adapting. However, a certain level of planning can save you from falling into chaos when things change.
A lean PRD is a guiding document for Agile and Traditional teams alike. Use it to map out your ideal release, think about your product from the viewpoint of your user, and home in on what you’re building.
