What is a Product Requirements Document?

This guest blog post was written by Lisa Hamilton, Experience Content Manager at Axiom Law (axiomlaw.com). Lisa is a certified MadCap Advanced Developer and content professional who manages user content and communications for legal technology and cloud solutions. She is also a contributing member and meetup organizer for Write the Docs (an international technical writing community).

THE MODERN PRODUCT REQUIREMENTS DOCUMENT

Guidance for creating a PRD (product requirements document) no matter what you call it, how your teams work, or what tools you use.

Keep reading for ideas that you can put to work right away, whether you’re creating your first PRD, modernizing your current PRD template, or still deciding if you want to write PRDs.

WHAT IS A MODERN PRODUCT REQUIREMENTS DOCUMENT?

A product requirement document, or “PRD” for short, is a tool used in software development including SDK software to communicate the requirements a product, capability, or feature needs to have and guide the teams who will design, build, test, and deliver it.

Think about a PRD as the story of what you want to build and for who, typically in terms of a problem solved for users or value to the business. It transforms your idea into something that can be built.

If you’ve been working in tech for a while, you probably associate PRDs with waterfall software development. But with modern methodologies like Lean, Agile, Iterative, DevOps, and others, you may want to consider modernizing your PRD to better align with these faster-moving and lighter-weight approaches.

DO YOU NEED ONE?

This is a fair question to ask given demands to deliver more, sometimes smaller product features, faster. It’s tempting to skip the PRD and just work from user stories, mocks, prototypes, and Jira tickets. Some might already plan on how to create online help documentation. 

But if I’m responsible for bringing a new product, capability, or feature to life and want to feel confident in an outcome that I’m accountable for, I’m probably creating that PRD in one form or another. 

It doesn’t need to be fancy or formal (unless you want it to be). Just the motion of creating a PRD and following a structured development process and conversation design process, even for small teams or product features, can eliminate many risks, prevent common oversights, alleviate frustrations that often arise from unclear expectations, and ultimately help you build better products and get them to market faster.

Just doing bug fixes, making back-end changes, or cleaning up some tech debt? Work that doesn’t affect the user experience probably doesn’t need a PRD. Most teams handle those stories with a development ticketing system like Jira.

Still not sure if you want or need a PRD? Consider incorporating a lightweight PRD, and then reassess how it’s working for you periodically.

WHO CREATES IT?

PRDs are typically owned and initiated by Product Manager, or someone acting in an equivalent role in your organization.

Job titles aside, creating a PRD can be done by anyone with the knowledge and ability to:

• Identify a user or business need that can be fulfilled by a new product, capability, feature, including updates to existing functionality and usability improvements.
• Articulate the vision and get buy-in from business stakeholders and technical leads for the product team(s) who will be involved in or doing the work.
• Define detailed requirements and specifications, ideally in a way that balances business value, technology, and user experience.
• Assemble, lead, and inspire a product team to transform the vision into products that delight your customers.
• Set goals, success measures, and take responsibility for the outcome.

HOW IS IT USED?

A PRD signals the beginning of the product development process and is a great tool for kicking off the project, managing scope and outcomes, keeping teams moving in the same direction, and measuring success. 

Kick off your project

Presenting the PRD communicates the start of the project to relevant stakeholders and key contributors—people who are sponsoring, doing, affected by, or have an interest in the work. Use whatever format works best for you—this could be a Word doc, Confluence page, Jira story—anything you can easily share and update.

Don’t expect people to read the PRD. Get on Zoom or in a conference room and use the PRD to lead a strong kick-off conversation. It may be tempting to just wave your hand and send an email, especially if you’ve gone the modern, lightweight PRD route. But a personal walk-through sets a collaborative tone and helps eliminate ambiguity around ownership and accountability. 

The PRD review is complete when you:

• Get agreement that the work is needed and will solve the stated problem or fulfill the stated goal.
• Inform all parties who have an interest in the work and give them an opportunity to weigh in.
• Define technical requirements and provide relevant context, answering the question, “what do the teams working on this need to know?”.
• Identify dependencies, assumptions, and risks. This can include any projects or processes on which timely, successful completion of your work depends or that might affect your timeline, resources, or requirements.
• Start filling out a “question and decision log” with feedback from the initial PRD review.

Pro tip: Read every word in your PRD as you lead the conversation. As a writer, it pains me to say that the world is full of headline readers, and your PRD deserves more—not due to pride of authorship but because overlooked details can be costly.

Manage scope

You’ve kicked off your story and presented your PRD, large or small. It now becomes an important change-management tool, helping you avoid scope creep and deliver what was promised. Here are a few ways you can use a PRD to manage scope with your desired outcome in mind:

• Ensure that designers and developers refer to it as they design and build.
• As you hold product design and development reviews, match that work carefully against the market requirements, key business metrics, and success measures in your PRD. If you spot something off—maybe you missed a product requirement or something different (or additional) is being built than what you asked for—have a conversation around that to course-correct.
• Keep an eye on any other non-functional requirements to ensure they’re being addressed.
• Gauge progress against any time commitments and take action to keep teams moving forward if needed.
• Monitor and update the Question and Decision log. Communicating these details to team members who are relying on the answers or are blocked by a decision is critical in avoiding unnecessary delays.

Keep teams aligned

A good PRD serves as a single source of truth that keeps teams aligned so you don’t have to.

Sort of. While you won’t just hand it off and expect teams to deliver a successful product, no questions asked, a lot of questions you do get can be answered by referring to the PRD so you don’t have to keep repeating yourself.

Two important takeaways here are:

• Get your product design team and engineering team to rely a little more on the PRD and a little less on you. That starts with a well-written PRD and may require gentle nudging until it becomes muscle memory.
• Make sure everyone who is assigned work is operating from the PRD. Don’t forget supporting cast members from QA, User Education, Customer Support, Marketing—anyone who is contributing to the work.

Manage and measure the outcome

When the work is complete, your PRD should help you answer these questions:

• Does each user story meet all technical requirements?
• Have all non-technical requirements been met?
• Did you solve the stated problem?
• Did you achieve the desired outcome? Think about the key business and success metrics you identified and how you will track and report on those to measure success.

At this point, an effective PRD becomes a project artifact and sometimes a basis for retrospectives or future work.

WHAT SHOULD A PRODUCT REQUIREMENTS DOCUMENT CONTAIN?

What you include in your PRD is up to you, but the following checklist provides a great place to start. Pick the sections that you think will work best for how you work and build a reusable template. For each section you’re free to incorporate full paragraphs or single sentences to build a long or short form PRD.

1.     Business value

 What problem are you trying to solve?

• Outline a high-level direction for the product.
• Describe how it benefits users, the business, or both.
• Explain what informed the work.
• Frame language to garner support and inspire teams.

2.     Key business metrics

What metrics will you use to measure success?

• What is the metric?
• What are you trying to change?
• How will you know it is successful?

3.     Technical requirements

What user stories are needed to deliver the desired outcome?

• Include one user story per technical requirement so that each unit of work can be completed independently.
• Use the “As a…I need… so that…” format for each user story to reinforce user and business needs over technical implementation.
• Don’t be too prescriptive. Keep user stories focused on the problem to solve and then let your expert designers, developers, testers, and writers solve it.
• Include any considerations around technical architecture here, or create a separate section for these if you anticipate any complexity.

4.     Other (non-technical requirements)

What user stories are needed to deliver the desired outcome?

• Include one user story per technical requirement so that each unit of work can be completed independently.
• Use the “As a…I need… so that…” format for each user story to reinforce user and business needs over technical implementation.
• Don’t be too prescriptive. Keep user stories focused on the problem to solve and then let your expert designers, developers, testers, and writers solve it.

5.     Stakeholders

 Who needs to be informed, consulted, or involved in this work?

• Create a matrix with all potential stakeholders and make it a PRD template element that you fill out for each story. You’ll be less likely to overlook someone with a matrix to follow versus thinking of the right people for each PRD.
• At minimum, include business sponsors, decision makers, and technical leads.
• Consider stakeholders from Product, R&D, QA, User Education, Training, IT, Info Security (if new data will be collected), Marketing, Sales, Legal, Finance, Customer Support, or HR. This may vary widely for your organizational structure, products, and services.
• Do not include entire teams here. Designating a lead or owner for each area is sufficient.
• For clarity, include the department, and role for each stakeholder.

6.     Assumptions, dependencies, & risks

What constraints or limitations might you face?

• Confirm each assumption, dependency, or risk that you identify.
• Include any assumptions you are making about audience behavior.
• Identify other features, teams, timelines, events, processes, or tools that your work depends on.
• For each risk, outline the impact and any potential workarounds.

7.     Supporting documentation

Are there any documents or resources that might help stakeholders better understand what informed this work? You might include things like:

• The product roadmap
• A business initiative document 
• Links to related stories or epics
• Product or user research

8.     Testing plan. What does your QA or test team need to know?

• Call out any special testing requirements, for example use cases or data.
• Describe any specific or critical test cases you believe should be covered.

9.     Documentation & training plan

What does your product requirements documentation and/or training team need to know?

• Describe who needs to know about this product or feature.
• Call out any special technical documentation, communication, or training requirements.

10.  Question & decision log

How will you keep track of questions that you need to answer and decisions that are made?

• Capture questions that arise during PRD review or at any point along the way.
• Record answers to questions.
• Record decisions that you make and why you made them.

TAKEAWAYS

Whether you’re creating your first PRD, modernizing your current PRD template, or still deciding if you want to write PRDs…

•  A PRD tells the story of a product, capability, or feature that you want to build in a way that guides the teams who will design, build, test, and deliver it.
• PRDs are typically created by Product Managers or someone in an equivalent role.
• The modern PRD format, content, and size is flexible and adaptable to how your organization and teams work.
• At minimum, your PRD should include business value, user stories, and success measures.
• A lightweight PRD is better than no PRD in helping to minimize risks and prevent critical misses.
• The PRD should guide but not necessarily prescribe how the work is completed, in particular around design. Let your design and development experts find the best solution for the problem you’re asking them to solve.
• The PRD is a living, working, shared document that remains in motion and provides important checkpoints throughout the development life cycle.

Once you’ve got your PRD in good order, be sure to reassess performance and evolve it periodically, and any time your methodology changes.