The PRD is a document that provides a standard of information needed to design and build a product capability that can be released within a quarter.
The purpose of the PRD is to have a single reference source for the product capability so that the team understands the objective, the LIMITED scope, and the core features of the product capability for a quarterly release.
Anyone can write a PRD on the development team, including product managers, product designers, developers, testers, etc.
Some scrum agile software teams refuse to write PRDs assuming it is only for hardware makers, architects, construction projects. However, in my personal experience, there needs to be unifying documents that gets everyone on the same page, and this is especially true when your scrum team gets to be 10+people, and when you're running multiple scrum teams. I have been part of a scrum team where user story creation gets to be a scramble of missed requirements and hacky development because the product owner did not take the time to think about what a product capability should and should not do based on a "this is not agile" misconception.
Thus, my solution is to write a bunch of small PRDs that is very limited in scope and easy to produce. In fact, this make the whole design and development team move with "more agility" because we can move very quickly to build what is in scope only, and move different capabilities in and out of our prioritized backlog.
This means PRDs are written mostly for "product capabilities" and not so much for a whole product (this is too large a scope for this document: there is another document for whole products). For example, I will write a PRD for the first version of the login/signup capability, and another one for single-sign-on. If both of these capabilities are easy for the dev team, then I may make one PRD for both. It really depends on our product and business objectives for the quarter, and the scope of the PRD will depend on this.
The PRD is meant to be maximum six pages, but typically one to two pages; nobody wants to spend more than 10 mins reading the document.
The PRD is meant to initiate action: the PRD author should spend more time learning about the customer's needs through design iteration and feedback, rather than getting the perfect list of product requirements.
The product management and design team should have completed a PRD for a capability at least six weeks ahead of its development. (I've written one in half a day, had wireframes done the next day, then had it reviewed and revised by the team on the 3rd day, for a small, but critical capability that needed to be started on for the next sprint).
Rule of thumb: the core features of the PRD are to be researched, designed, developed, tested, and released to customers within one quarter (three months). Currently, the assumption is that each team has at least one "major capability" release every quarter. Note: My experienced agile team of four people could design and build 3-4 capabilities.
The PRD is meant to be an assembly of core features that describe a product.
Information Hierarchy: PRD (Product Capability +Core Features) > Epics > User Stories
The PRD is used to create epics. It is recommended that the author create a list of suggested epics under each core feature; however, it does not have to be a complete list since it is bound to change during the development process.
The PRD does not have User Stories because user stories are product specifications that are too detailed for the spirit of a PRD (Exception: sometimes the PRD is small enough to be one Epic of less than 10 user stories, which then i'll leave it to the Product Owner to decide whether to include them or not).
If a product is significantly large, then it could take several PRD to complete, and there is a higher-level product document as part of the product roadmap (TBD on the hierarchy).
There can be multiple version of the same core features, each building on the next.
Once the contents of the CRD are agreed upon by the design, development, and business team, then it should be used to limit scope creep.
It is a fine balance between having too much information for a product and rushing to start development without well thought-out designs and customer experience: a rule of thumb is that a good PRD will allow the product management and design team to gather, design, and complete writing user stories to a maximum of three sprints (six weeks) ahead of the software development team.
"Always be shipping and iterating": all these principles and hierarchies are subject to modification if the writing and structure of a CRD starts "becoming the bottleneck", rather than a focus on customer happiness and shipping products they love at an accelerated rate.
The PRD writer has already gathered information and spoken to stakeholders and customers prior to writing the PRD.
The product management team has completed the business and market requirements analysis for the product, and product development is approved.
The need for a PRD is driven by the product roadmap and its quarterly objectives.
The product roadmap is driven by the annual company objective.
The development team is following a Scrum-Agile development methodology.
Product Capability Purpose
What is the objective(s) of the product?
What are our customers and/ or user's painpoints?
How does our product help them? Why does the product matter to the user and/or customer?
Why does our company need this?
User Profile(s)
Who, what, how, where, and why is the user(s) using this product?
Research Background
Add any links or attachments here during your user research. Note: This is not supposed to be a big section.
Assumptions
User Journey
Core Features
Write your Core features list
Out of scope
Epic Table/Requirements
Release Goals
(table format recommended, meant to be 1-2 sentences each)
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)?
Design
Low-fidelity: provide a link to wireframes and prototypes
High-fidelity: provide a link to wireframes and prototypes
Note: As your team becomes familiar with the design system (i.e. Material UI) and your designers start to re-use components, I found that the low-fi and hi-fi wireframes start to become the same.
Timeline
Assumption: This product can be started and released within a quarter.
Description Notes
1 PRD Author receives PRD request to be completed based on the product roadmap
2 PRD Author completes research: Customer, user, and stakeholder research
3 PRD Author writes the PRD Product Purpose to Release Goals sections, and gets continual feedback There is no real restriction. If the author wants to complete low fidelity wireframes, then they are free to.
4 PRD Author sources low-fidelity designs and gets continual feedback.
5 PRD Author sets up a meeting to present PRD and designs to entire team. To get approval, the PRD and designs shouldn't be a surprise to anyone on the team, which presumes they have already been sent the PRD and have given comments.
6 PRD gets team approval for scope.
7 Product manager sets up a meeting to complete a story map with entire team. The purpose is to prioritize and sequence the development.
8 Product manager estimates product development timeline.
9 Scrum-agile-style user story writing begins... High-fidelity prototypes to be started.
High-fidelity prototypes can be started ahead of user story writing if there is external user testing required.
Assumption: Scrum agile methodology is used.
At this point, the user story writing is optimally six weeks ahead of software development.