by Jerry Cao
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.
In this piece, we?ll look at Product Hunt?s product requirements document as a best practice and explain how to make it work for you.
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.
For a detailed PRD, you can reference this expansive PRD template. For a more lightweight option, check out how to write a simple PRD.
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.
Source: Product Hunt Product Requirements Document
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??.
Source: Product Hunt Product Requirements Document
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 featureswill 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 some of today?s most successful companies prioritize features, check out the Guide to Minimum Viable Products.
Source: Product Hunt Product Requirements Document
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.
IV. State the Constraints & Establish a Schedule
Excruciating over exact timing is dangerous since it can hold you accountable to features that might change depending on the market. Instead, a rough window provides flexibility while helping to better avoid feature creep since it sets stakeholder expectations. In addition, writing down any workflow constraints (for example, budgeting or resources) can also provide a more accurate picture of the factors affecting timing. With both the constraints and rough date in writing, you have a more informed way to work backwards from the end date and assign realistic sprint lengths to each feature.
Use What Works and Scrap the Rest
Building your product is an ongoing process and the last thing you probably want to do is throw more paperwork into your sprints.
Source: Feature Flow
But a certain level of documentation is necessary to keep some order in all the chaos. It doesn?t need to be exhaustively detailed, but it should provide some idea of what exactly everybody is building.
User requirements coming from product management needs to be translated. Dependencies among different technical entities have to be understood. And internal and external testing feedback must be captured to justify changes. In between all this, you?ll need to answer stakeholder questions like ?How is everyone staying on the same page?? and ?How will we realize our goals in the set time limit??
The product requirements document is just another helpful reference point as you prepare for the ultimate product test ? your launch date.
For more smart ways on incorporating documentation into the design process, download the Guide to UX Design & Process Documentation.
