How to write a lean PRD (product

requirements document) for your next

project in 5 steps
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
What is a product requirements document? (And how it is special?)
The essential elements of a lean, mean one-pager PRD
How to write a product requirements document (PRD) in 5 steps

› Step 1: Define your purpose

› Step 2: Describe your features
› Step 3: Set release criteria
› Step 4: Set a timeline based on constraints, not dates
› Step 5: Share with stakeholders for feedback

A (slightly longer) PRD example: Product Hunt

Why spend the time on a PRD? How to sell your Agile team on the need for a one-
pager product requirements document

› 1. A PRD creates a shared understanding across teams

› 2. A PRD helps break Agile teams out of ‘product tunnel vision’
› 3. A PRD helps you gather requirements in an Agile world

Master the delicate art of documentation in Agile and your team will thank you

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).

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:

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:

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.

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:

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.