While the bulk of documentation is produced in the earlier stages, the implementation stage is one of the most crucial phases of the UX design process.
While you do a lot of concepting during the research, analysis, and design phases, it’s now time to get to the heavy lifting. We understand that documentation doesn’t always equal a product, so that’s why we’ll just explore the essentials.
The Anatomy of the Product Requirements Document
Once you get to the “Build It” phase, the previous research and prototyping should give your team a high-level understanding of your product. All companies are different, so some stages of product development can happen simultaneously (instead of sequential).
Regardless, you should be able to ask any 5 team members about the overall purpose, features, release criteria, and timeline for the product and they should give you roughly the same answer. In today’s Lean and Agile world, the PRD may be trimmed down (or simply represented by a prototype) so we’ll focus on just the core elements.
The PRD is the heart of your product and serves as a living document for any designer, developer, or stakeholder to understand the status and purpose of the product.
As illustrated above, failure to document requirements can lead to wildly different assumptions. Because there’s been debate around the danger of excessive design thinking as well as its vital role in product leadership, the PRD helps balance the design team’s focus on usability and aesthetics against engineering’s functional concerns.
The product curation company Product Hunt shows that a PRD doesn’t need to be 100 pages long — just define the problems the product will solve with a general description of features (and plenty of mockups from previous stages). The technical details should be saved for the FSD.
According to Ben Horowitz and David Weiden, both notable venture capitalists, the PRD is the most important document a product manager maintains and should be the product Bible for marketing, design, and engineering. Good product managers not only keep PRDs up-to-date on a daily or weekly basis, but they view the entire PRD process as ongoing — the document is never truly complete, it simply evolves as the team iterates.
Marty Cagan, Partner at the Silicon Valley Product Group, explains the four core sections of a PRD — defining purpose, describing features, setting release criteria, sketching rough timing — which we’ve adapted for our purposes below. According to Cagan, the PRD’s goal is to explain the “What”, not the “How”. In each section, remember to be clear on the problem being solved versus the solution otherwise you may lead the team to make incorrect assumptions. The engineers, designers, and UX folks are the ones designing solutions for the product — don’t piss them off by making the PRD a recipe rather than a guideline.
I. Define the Product Purpose
Make sure you discuss the user problems (not solutions) that must be addressed, the target demographic (companies, customers, users) and various use cases for each demographic.
While this has probably been discussed to death before, it’s important to reiterate them during as you build the product otherwise it might get lost in the development shuffle. What separates a top 1% product manager from a top 10% product manager is understanding that the team craves purpose and context when feature tradeoffs are inevitably required, so forget the marketing jargon and only talk about “Why?”, “Who cares?”, and “So What?”.
II. Describe the Product Features
The features section is the body of the PRD.
Features must be described with regards to the interaction design and user experience to give engineering the most flexibility. More importantly, you must map features to product objectives (known as requirements traceability) so that the business impact can be clearly understood if someone cuts a certain feature during development. Ranking these features will also help you prioritize in case there’s scheduling shifts or you discover some features should be replaced as you progress in development. To learn more about how some of today’s most successful companies prioritize features, check out the Guide to UX Design Process & Documentation.
III. Outline the Release Criteria
How will you know the product is ready to release for beta testing? While this section can be the most technical of the PRD, we still are just describing goals — not a means to achieve them. You’ll want to outline criteria in these five areas:
- Functionality — Is there a baseline percentage of the original features that must be retained? What are the absolute mandatory functions?
- Usability — Is the program aesthetically striking and intuitive to users? What is the acceptable time to complete tasks for each use case?
- Reliability — What’s the maximum acceptable failure rate? Are these failures predictable? Can the system recover from these failures?
- Performance — How fast must it be? What is the maximum response time, throughput, and memory consumption?
- Supportability — Is it testable, serviceable, installable, and configurable?
It’s important to start the discussion around release criteria as early as possible, iterate, and formalize them as you approach the build stage. These should be reviewed and agreed by stakeholders during the early stages of development. Otherwise, if you wait, you might just set the bar at wherever the product currently stands.