Writing a great PRD isn't easy — but the effort is well worth it. PRDs do more than help you communicate new features to your colleagues; they also help you figure out how you can use each new feature to solve problems and achieve your goals.
Here's a list of things that every product requirements document should have. Each section of this template is important in its own way. And when they all form a cohesive whole, the result can transform your product management workflow:
This an intro to your PRD, where you'll give some background information to your reader to help them understand what the feature is. You can keep things at a high level and answer questions like:
Having your "Objective" section is almost like having "big brother" watch over you — in a good way. It ensures that you are building out each feature relative to the high level goals that your product team must achieve. It also focuses your attention (and readers' attention) on the core product or feature.
In essence, it helps you make sure that your team stays on track and avoids feature creep.
Consider your PRD's Core Components section to be its Table of Contents. The Core Components section lists the key parts of the product feature. This helps readers understand what the rest of the PRD will focus on.
For example, let's say you are building out a new e-commerce feature to help your users buy packs of colored pencils. The core components for that PRD might include:
In a way, your PRD is like a pyramid. You start off at the top of the pyramid, where you define which problem you are trying to solve. As you move down the pyramid (and the PRD), you go into more layers of detail on all the different components of each feature. This Core Components section helps your reader gain a high-level understanding of which pages will need to be built, and what is involved in building each page.
The User Flow section is a space for you to define the consumer journey. There may be some overlap between this and the Core Components section. But only the User Flow section goes into detail about how the user gets through each step of the process. While the Core Components may lay out all the different pages and features which are involved, your User Flow is the step-by-step process that your users take in achieving their goal.
Going further on the colored pencil example, your user flow might be something like this:
For this section, we took the pages from the Core Components section and built out a few key actions from each of the pages. This explains what the user flow looks like from start to finish. Now, you can paint a picture of what this feature does and how each user can navigate the flow. You also gain a strong understanding of this new feature's key components.
So far, you have defined your new feature's key objective, core components, and user flow. Now, it's time to define the specifics of each page. On each page, you will outline all elements of the feature you're working on — and all of the different states that may exist.
First, you should list out all the different elements on the page. As you do so, remember the core goal of the product or feature that you're building. Any elements that you spec out should be directly related to that goal.
For each of the elements, you should go into more details to help your team understand what each component does, which states should be accounted for, and which type of development should be set forth.
Here is an example of the types of information you may need to provide, along with questions you should ask yourself (and answer) when writing the PRD:
As you go through this exercise when writing your PRD, remember its core goal — to get everyone on the same page so they can understand how the feature works. To accomplish this, you'll want to provide enough detail so that anyone who reads your PRD will have a full understanding of what the product does.
When writing your PRD, you should work with your teams to put proper tracking in place to measure how well your product or feature is doing. Without proper tracking, you're flying blind and won't have a clue as to what's happening with your feature. Unless you know exactly what your users are doing, you won't know how to improve your feature (or where to make improvements in your feature).
The first step in this process is to list out the 3 main questions you'd like to answer. These are questions — also your key metrics — which will help you understand whether your product or feature is doing well.
So, for the e-commerce feature we've been going through, Purchase Conversion Rate would likely be a key metric. This is the percentage of your visitors that are converting (aka buying) a colored pencil. In order to track this information, you could look at the # of people who visit the pages of each step of your funnel.
Let's take a look at an example. Here is some fake data on the # of people visiting each page of the funnel:
Did you notice the number of people who get their purchase confirmation (conversion) relative to the number of people who visit your checkout page? That's a huge drop off when compared to other pages. So, this data indicates that you should spend more time optimizing your checkout page. Focusing your efforts on improvements to that page will increase your percentage of people who make a purchase.
The next step would be to review your Checkout page to confirm which parts of the page people are clicking, and what might be preventing them from making the purchase.
These are the types of questions and hypotheses you should make when thinking about Analytics. You should also track these questions and hypotheses to answer them once your feature has been launched.
This section will help your team understand how the product may evolve over time. This doesn't need to be a hugely in-depth section, but it will help your team see the product or feature through your eyes.
Remember that as a product manager, you need to be its go-to expert. You likely have a lot more product knowledge than others, and you should share this knowledge to help your team get on the same page.
Never assume that others know what you do — and vice versa. The strongest step you can take as a product leader is to share your knowledge with your team.
Take the example of a contractor who is building a 50-story skyscraper. Perhaps you plan to start with a two-story building today, but in the future, you plan to add a lot more stories to that building. Your architects must put in the proper foundation to support that 50-story building in the future. Preparing today helps you succeed tomorrow. Scaling your product successfully involves planning for what will come next.