67e90e36a89f48e87627ed71eaec50a9
Jory MacKay
Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.
April 06, 2021 · 11 min read

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!


How to write a lean PRD (product requirements document)

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.

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.


Planio knowledge management with our Wiki

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:

  1. Product Purpose
  2. Features
  3. Release Criteria
  4. 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:

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.

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:

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:

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:

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.


Product Hunt example

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.