Guide to Product Requirements Documents with Template

Here comes is deep-dive into working with Product Requirements Documents (PRDs). It is a how-to guide that also looks at benefits and pitfalls, with a template and an example.

What is a Product Requirements Document?

A document to clarify thinking and enable collaboration

A PRD is a technique used by product managers (PMs) to clarify and express their thinking about a feature. Well-written PRDs can work wonders when it comes to enabling collaboration with team members and other stakeholders.

Epic document or feature document would be better names

Actually, the name product requirements document is not very good, as it typically centers around a feature and contains more than just a set of requirements. The term "requirements" is also problematic, as it links back to the era of waterfall, where PMs simply polished and handed down requirements. The Agile way to think about it is rather to have a discussion around user stories. Nonetheless, the term stuck, and so now most people talk about "PRDs", even though sometimes more apt terms are used, e.g. epic documents, feature documents, or feature specifications.

Benefits of writing a PRD

Pulling together the available information and structuring your thoughts into a piece of writing is valuable not just for the end result. The act of writing forces the act of thinking. And there is enormous value in stopping to think as you close in on a solution and start to consider actually building it.

Your should aim to harness the perspectives of your team and stakeholders so that you can ship the feature in the best way. However, interaction time is often limited, making it is hard to properly get their perspectives. By writing things down, thoughts are exposed and can be more efficiently discussed.

Shipping a feature is a complex project, with lots of decisions of widely varying character to make, together with a group with completely different ways of thinking, and in a process that is often far from linear. Together with several different tools and documents to update across, this becomes a total mess. By working in a structured way and with the right tooling, a PRD can act as a single source of truth across the process and greatly unmess the situation.

Developing people is to a large part about developing their thinking. A team with a habit of writing PRDs also regularly express their thinking, expose it to each other, and then discuss the way they think, giving ample opportunity for feedback. Over time this does wonder both for the professional development of junior and senior PMs alike (it is also a challenge to give feedback on the way someone thinks), and for effectiveness (as the team coalesces on style, both writing and finding information becomes easier).

When to write a PRD

What development efforts to write a PRD for

It does not make sense to write a PRD for every development effort, but there are two indications to look for:

Where the PRD fits in the product management process

Looking across the product management process, writing the PRD is the main activity in the definition step.

The trigger for starting to write a PRD is that it becomes relevant to properly define what it would mean to pursue a solution further. The process is not entirely linear, but feature definition is typically preceded by feature prioritization, which is in turn driven by a combination of work across strategy (where goals are often expressed using OKRs), discovery (where it is really helpful to work with Opportunity Solution Trees), and ideation (where it can make sense to filter the inflow of ideas using something like RICE).

After a feature is properly defined, the next step is to refine the feature further in collaboration with team and stakeholders, and potentially do further solution discovery and validation with users.

How to work with PRD-writing

4-steps to a great PRD

Before going into proper definition

A good general advice for PMs is to allow themselves to have something like a loose knowledge base of ideas, where stub documents can be created early on, and where they can then over time file new thoughts and link to e.g. insights hub, discovery documents.

At the this stage, PMs do well allow a rather loose format and not to overdo it. If they are too hard on themselves to do more than that and expect to properly define every conceivable feature, they would do nothing else.

Then, at some point, the trigger to more properly define a feature often comes during feature prioritization discussion or maybe out of discovery work. This is when it is time to properly move into doing definition.

Step 1 - Make a clear point of departure

To make a distinct point of departure, you first need to pick up on the trigger of realizing that this epic is a candidate for delivery and then carve out time to think about the epic.

If not done before, elevate the epic from just being part of some notes you have, into being part of a more structured process. Product management is not project management but PMs still need to manage projects. This epic just became a project, and the PRD is the main project document.

Block time to think. Determine the premise for the epic. The most minimal version of this could be to just name the epic. But it is often worthwhile already here to write one or a few paragraphs that articulate the problem to solve and maybe some notes on e.g. context, hypothesis for a solution, and measure of success.

Step 2 - Identify the key sources of insight

Based on the epic you scoped out in the first step, you should have an idea of what the relevant sources of insights are. In this step, you attempt to pull in existing thinking and data. This could be e.g. received customer or internal feedback, notes and comments from interviews and experiments, data that substantiates the problem, a reference to current OKRs, and previous thinking and sketches on what the solution could be.

If you are using an outliner, it is easy to just dump all this data and collapse, so you have a clear overview and won't have to scroll more and more as you add things. Keep any references on where insights came from. Try to refrain from overthinking in this step, it is a bottom-up exercise to prepare for the next step.

Step 3 - Structure your thinking into an outline

Armed with the premise and the existing input, it is time to take a step back and try to think top-down on what topics you will need to cover in this PRD. I spent 6 years as a consultant at McKinsey, and if it is one thing from the management consulting toolkit that I have seen product managers benefit from adopting, it is this kind of structured top-down problem-solving. By spending a little time up front to lay out the structure, a lot of time can be saved down the line.

When determining topics to cover, and thus the headings to use in the PRD, it is often a good approach to go back and forth between the premise, the already existing input, and a set of potential headings in a modular PRD template, so that you are reminded of topics that are good to cover. There are headings that will be crucial for some epics, but not relevant at all for others, such as "Legal" and "API". Typically it is enough to arrive at a 2-level structure, with something like Problem-Solution-User Stories-Rollout as level 1 headings, and the headings below that depending on context.

If you are using an outliner <link>, this step will be both faster (as you can quickly slot in the existing input under the right heading) and easier (as you can collapse down to show headings only to more clearly think about what headings might be missing).

Step 4 - Get to a good starting point and test it with the team

The goal of the definition step is to get to a good starting point, where you can effectively test your thinking with the team. When you have the premise, the topics to cover, and existing input under respective topic heading, you are much better positioned to come to that. However, you will still need to do some thinking to articulate the epic and figure out the most critical issues to resolve.

It is often valuable to make at least some headway on the main topics and write one or a few paragraphs in full sentences, on e.g. the underlying problem, the measure of success, the hypothesis for high-level solution, critical validation needs, as well as writing a first cut of user stories or even a rough user story map.

At this point you are in a good position to take a step back and ask yourself what the most critical issues for this epic will be. It could be a risky assumption to validate, a choice of solution to pursue, what user stories to include in the MVP, what user flow to choose or another implementation decision. Make sure to type explicit questions to be decided where relevant.

Problem solving and communication go hand in hand, and so if you have done the structured thinking in previous steps you are now in a position where you are able to communicate your thinking on this epic i an effective top-down manner, which is always appreciated by stakeholders.

A last note on this step, is that there are different schools on how far to take it, ranging from Matt LeMay's one page one hour pledge to the Amazon 6-pagers. What is best depends on context, but we have generally seen a leaner approach works better, as it brings in the team earlier and better enables fast iterations.

After having properly defined the feature

Once you start to collaborate with your team, you move out of the definition step and into the refinement step. Later on when you hand over the feature as user stories in the issue tracker, you move into the development step.

If it is possible to let the PRD live as the single source of truth for the feature through both of these steps, you will save yourself a lot of time, not having to update or copy-paste across potential sources of truth. The ability to make this happen depends to a large part on the tool you use for writing PRDs, and we will come back to that further down in the article.

The ultimate PRD template setup

The conundrum of whether to use a template

Many teams look at the option of introducing a normal template with a fixed set of headings, and then face difficult question, where either decision seems wrong.

This is the wrong question to ask.

How to get the best of both worlds

As we described in the 4-step process, the PM should not be a box ticker but a structured problem solver, figuring out what topics to cover on a case-by-case basis. This means that a single massive template won't do. At the same time, a template is valuable for the support and standardization it can provide.

This conundrum can be solved by working with modular templates with many potential topics with sub-templates, where the PM can pick the topics to use for any single epic, can meet both these types of needs.

The anatomy of a modular template

To help people find their way it is a good practice to have some high-level topics more or less fixed, and then rather vary the headings below them depending on context. Working with hundreds of PMs across thousands of epics, we have seen four main topics that can serve as fixed level 1 headings, as they always either come up or should have come up: Problem, Solution, User stories, and Rollout.

Problem section

Before diving into the solution, always make sure to have the problem articulated and properly substantiated. 

A short problem statement goes a long way. If this is all you after you first come in to think about the epic, that can be good enough. You can always come back later to define more exactly what the problem and to add more details to substantiate why this is a problem worthwhile pursuing.

Depending on context, it can make sense to add headings below the problem, e.g. measure of success, background information, target audience, customer feedback, internal feedback, supporting data, and maybe an opportunity tree.

Solution section

Once you have articulated the problem to solve, if you have a solution in mind, write the overview of the intended approach to solve the problem. But before detailing the exact user stories for the feature, it is worthwhile staying a bit to think high-level about the contours of the solution and what is needed for it to make sense.

If you do not have a single hypothesis for how to solve this problem, it might be too early to think about it as an "epic". To get to the point of having a solution it can be helpful to go back to the problem section, add an opportunity tree, and have a problem solving session with team and stakeholders.

Do not move ahead and spend time thinking about a solution if you cannot articulate the problem and what you are trying to achieve with it. If you find yourself in that situation, go back to the problem section and think some more.

Depending on context, it can make sense to add headings below the solution, e.g. alternative solutions, user flows, lo-fi sketches, validation (making sure you have the riskiest assumptions covered), competitor comparison, use cases (as a complement to user stories) <link to blog user stories vs use cases>, and dependencies.

User story section

Express your epic as a set of user stories. That way, you can get different parts of team & stakeholders on the same page and avoid painful handovers. Everyone can relate to a story from a user.

The best way to think about negotiating requirements for new features is by working with user stories on a user story map. Ideally you should use a tool that supports user story mapping as part of the PRD.

The best practice is to try to draw up a user story map with a few user stories when you have the contours of the solution to pursue figured out, and then iterate on that with the team as you move in to refinement

Rollout section

An important but often overlooked part of delivering product value is going beyond developing the feature to look at the actions needed to ensure the epic is successfully implemented and gets all the way into the hands of happy customers.

Depending on context, it can make sense to add headings below the rollout, e.g. marketing, sales, customer success, analytics, and partners.

A modular template example

Further down, we will look at what a PRD based on a modular template can look like once it is a completed document. But if you would like to try our what it is like to work with a modular PRD template, you can try that out here 👇.

Pitfalls of writing PRDs

Even though the PRD is the main activity in the definition step of the product management process, there are PRD-related pitfalls with implications across all the steps.

The proper tooling for writing PRDs

Criteria for selecting tool to support working with PRDs

You can of course write PRDs with any document-writing tool. But if you want to set yourself up for success, it is worthwhile thinking about what tool to use.

Outliner capabilities for structured writing

Writing a PRD is as much a process of thinking as it is a process of writing. Thinking properly about an upcoming feature requires structured problem solving. It requires both a bottom-up approach of gathering and categorizing all incoming ideas and facts, and a top-down approach of starting with the topics and sub-topics that need be covered. Working with a tree structure allows for combining the top-down and the bottom-up approaches.

Outliners are a type of tool built for this. They are designed to enable users to work effectively with text and other information in such tree structures. Work is visualized as a bullet tree, where it is possible to expand and collapse parts of the tree, as well as split, merge and rearrange information with mouse or keyboard shortcuts. Together, outliners enable users to work with structure at the speed of thought. Such outliner capabilities greatly benefit PRD-writing.

Modular templates to augment PM workflow

As described earlier, teams of PMs struggle with the conundrum that they can benefit from agreeing on the types of topics to cover in their PRDs (helpful to junior PMs, standardization enables efficiency, easier to navigate for stakeholders), yet having to a start with fixed set of headings goes against the workflow of great PMs (unnecessary initial cognitive load, not known what topics will actually be used).

A solution to the conundrum is modular templates, where PMs can pick the topics and sub-templates they need for each epic. It offers a great balance between starting with low cognitive load yet still covering the most relevant topics, based on product management knowledge. Therefore, it is helpful if PRD is written in a tool that supports work with such modular templates.

Enabling the PRD as the single source of truth

The goal of the definition phase is to get to a good starting point for discussing the epic with team and stakeholders. For many, that is where the role of the PRD ends.

However, if the PRD can stay relevant and serve as the single source of truth throughout the process, that can help untangle the mess of tools and documents that many PMs face today. In turn, that also makes it more worthwhile investing in the PRD, allowing the whole team to benefit more from a structured approach to problem solving.

For that to be the case, the PRD needs to be written in a tool that supports the work that comes in the later phases. This requires both general features for real-time collaboration (e.g. see others in doc, comment, mention, assign), as well as features and integrations to support specific PM practices (e.g. user story mapping, facilitated decision-making, design work, and issue tracking).

Comparison of tools for writing PRDs

Google Docs

Google docs is a great tool for writing and collaborating around different types of documents in general, and it is the most common tool used for PRD writing. However, it's lack of specific support for PRD writing and the product management process in general means that many teams that use it are looking for a replacement.

Confluence

Confluence is a great tool for working with a company wiki and setting up formal documentation that is easy to find, and it is used by many teams for writing PRDs. However, it has only limited support for real-time collaboration and it too lacks the specific support needed to take PRD writing to the next level.

Delibr

Delibr is a tool that is tailor made for PMs that write PRDs and that becoming more and more common. It helps team of PMs be more proactive and deliberate about their PRD-writing, and supports them with the features they need throughout the product management process.

A best practice PRD example

About the example document

Before going in to the actual document, as "best practice" is a contentious phrase, I'd like to first briefly explain the setup and add a caveat.

The setup

To make it as relatable as possible I tried to pick one of the epics I have seen the most times - Google sign up/login. Maybe you have done it (and recognize the thinking) or maybe you are about to do it (and get clarity from the example). The below example is a mix of a lots of documents I have seen doing more or less the same thing.

A caveat

I have seen many different takes work well, applying the approaches differently. Thus, I was hesitant to say “this is what a good epic document should look like”. But because many asked, here below is my take on how a good epic document could look. Please take it for what it is, an example, and be mindful that a lot of the choices depend on both company and feature.

What a PRD for Single Sign-On could look like

Below are screenshots from the document. But, as the document is written in an outliner it is better to experience it that way, and as expanding and showing all parts here would take up too much space the below is just an abbreviated version to give a taste. To get the full document, sign up to Delibr here, and get the document added to your workspace as a demo document.

Get more help working with PRDs

If you still want more help in working with PRDs after having reached the end of this long article, we'd like to offer you two options, catering to different tastes - the extraverted, and the introverted.

For the extroverted knowledge extractor

If you kind of read the article, or watched the video and would like to bounce your thoughts with us at Delibr over a video chat, we are happy to help (especially if your product team uses Jira Cloud)! Grab a time with us to discuss your setup for working with PRDs here. We have had these discussion with hundreds of teams, and so can typically be very helpful, but we also always like to hear more about how different teams work. It will be great!

For the introverted voracious reader

If you actually read all of this article and still want to read more about how to work with PRDs, you are in luck - as I wrote a whole book on the topic. Either buy the book on Amazon or click here to get it for free.