What are product requirements documents and why do you need them?
Paul is a product manager, and he takes great care of writing proper user stories for all features and manages an up-to-date backlogs in Jira. Nevertheless he feels the “big picture” gets lost in translation while the engineering team is implementing the backlog. Heck, sometimes even Paul himself gets lost in the sea of tickets, and has to remind himself of why an initiative was started in the first place.
Maggy is responsible for Marketing and PR. She is often taken by surprise when a new product feature is ready to be shipped, and has to scramble to get the message crafted and distributed.
Bert runs business development. While Paul collects his input diligently, both Paul and Bert feel they could be better aligned on who they are launching a new product initiative with or for.
Does some of this sound familiar? Writing Product Requirements (usually in the form Product Requirements Document, PRD) can help to align cross-functional teams and to communicate the big picture around product plans. And it is really simple to do.
Product Requirements != Features
Product requirements are not features. At least not only. The product requirements should focus on the problem the product or a particular product initiative is trying to solve for the customer, and why it is relevant.
So the product requirements are about the what and why. Whereas features, user stories, or technical requirements are about the how.
Furthermore, the product requirements should address everything that is relevant for a product beyond its features and functionality. This includes in particular
- Communication, product marketing, and wording/terminology
- Launch and going to market
- Customers, customer needs, and launch customers
- Addressed market segments and pricing
- Non- functional product requirements (performance etc.)
The anatomy of a product requirements document
Below I’ll introduce the sections you would typically find a product requirements documents, and what they may contain. Here’s a publicly available Google doc template, in a long and in a short version. (Note: these templates are also provided as core part of the functionality of the shipit product management tool. Both as Google Drive and Atlassian Confluence versions.)
Introduction
This should contain a quick overview of the initiative, and focus on the why: why is this needed, why is it relevant for customers, why are we building this.
Customer needs, market and business model
- Who are the customers who will use this feature or asked for it? In general terms (personas), but also specific customer names
- How many customers have asked for this feature? Ideally provide counts or list from feature requests or your CRM tool.
- How will this initiative be priced? For a full product this is the full business model, for a new initiative for an existing product the question is how current pricing will change (or not).
Expected results
What do we expect to happen after we launch? This is very important to write down and check back after launch. It also is crucial to explicitly align everyone’s expectations and have them explicitly recorded before launch.
Product marketing, marketing and communications
- Key metrics: relating to the above: how will traction and success be measured?
- Product marketing and communication: key messages, wording, links to working docs of blog posts, press releases etc. (Before launch).
Personas
The user personas of our product or initiative
Functional Requirements
This is the set of product functionality. You can write these in various ways:
- User story type: I recommend to stay on the “Epic” level and put further details and detailed user stories into your ticketing system.
- “Jobs to be done”: what customers/users want to achieve.
- It’s generally a good idea to link to your ticketing system, once you start entering epics, user stories, and tickets. For example you could link a list of relevant Jira epics.
Non-Functional Requirements
These are typically requirements for uptime, performance etc. Most typical performance metrics to consider are throughput and latency.
Design and UX
Link to any design in UX materials you may have in for example Figma or Sketch.
Technical Specifications
Links to detailed technical and engineering notes, if relevant.
So you see that the PRD is a place that “holds everything together” by linking to various places. It is the umbrella unit for all the various disciplines that will be involved in shipping: engineering, design, business development, marketing, etc.
What’s the difference to Jira, Trello?
I get this question a lot when talking about product requirements. As you may have noticed, the PRD contains pretty much everything that is crucial for the launch and does not live in Jira/Trello typically. So, again, usually everything besides the stories and features. It’s also the place that should give one simple, quick overview to get started or check back. Something that’s often lost when faced with a long backlog of tickets.
The hierarchy of product, initiatives, epics, user stories, and tasks
You may wonder how the product roadmap items and the requirement documents (PRDs) relate to Epics and User Stories of Scrum. It’s quite simple, they are another, higher level of abstraction. The Product requirements typically stay at product or product initiative level. (An initiative would be some major effort for a larger, existing product. It would cover many epics and user stories, and could take many sprints, and up to 3 month or so to complete. Think of things such as adding an E-Mail Marketing tool to an existing CRM Software.)
Your product roadmap would typically contain only things that are “large enough” i.e. on said initiative level. It would not list individual features. These stay in the backlog of your ticketing system. Furthermore, the roadmap does not have to reflect all the “little” changes and features that may be going on outside of the key initiatives.
A hierarchy of these artefacts and the tools they live in could thus be listed like this:
Format and alternatives
We have described one way of writing product requirements above. Even though there is a lot to cover, it’s recommended to keep the documents short. Alternatives to a PRD could also be the famous Toyota A3 report, which summarises everything that’s relevant on one A3 format of paper, or a simple one-page kind of document per initiative.
If you like this format, I recommend you try the tool shipit, which helps you manage your roadmaps and product requirements with a straightforward approach.
