Once a product has been given the green light for development, such as a next-generation prosthetic, companies often create a product requirements document (PRD) to outline expectations. This document reflects all previous research and prototyping while outlining the larger production process to ensure a successful product.
Each company can approach product requirements from a slightly different angle, especially since a significant amount of product development now happens simultaneously rather than sequentially. However, these documents are still important to ensure that everyone on the team remains on the same page during the development process.
For the most part, lean approaches to business have truncated PRDs so that they focus on only the core elements without superfluous information. However, there are still key sections that the document must contain. The key parts of the PRD include:
1. Product Purpose
While the focus of the PRD is the solution to a problem, the document should actually start by outlining the issue being addressed. Before getting into the solution, it is important to understand fully the problem. The product should have defined demographics and this sector should clearly explain how the design appeals to each of the intended demographics.
Often, this topic has already been discussed extensively, but it is still important to include to ensure that nothing gets lost in the development push. Teams need to have a clear direction in terms of purpose and context so they can make informed decisions about feature tradeoffs, which are inevitable in virtually any process.
This section should avoid industry jargon as it may be used by several different teams. In the end, the section should be streamlined and answer the questions “Why?” “So what?” and “Who cares?” Any tangential information can get removed, as it will only generate confusion. Make sure all stakeholders understand this section completely as it serves as the basis for all development work.
2. Product Features
The features section is the heart of the PRD. All major features should be covered and addressed in terms of both user experience and interaction design. This information is critical for engineering teams.
This section should additionally tie each feature to specific product objectives, a process known as requirements traceability. Doing this makes it much easier to figure out the potential business impact of cutting a particular feature, which is imperative to consider when changing or removing a feature.
The PRD should rank features according to their importance to the final product. This ranking is considered along with the potential business impact to figure out how to proceed if some features need to be cut or replaced due to time or developer constraints.
All companies rank features using different methods. The important thing is to achieve internal consistency. Everyone involved with the design process should understand how and why features are ranked where they are.
3. Release Criteria
Another key element of the PRD is the criteria for release. After all, it is important to understand when the product is actually ready for beta testing, otherwise the design process could continue indefinitely as perfection is not a realistic goal.
While the release criteria section often becomes quite technical, it is important to remember that the document is focused mostly on describing goals rather than creating a blueprint on how to achieve them. The discussion about release criteria should start early so that it can be reviewed frequently and formalized by the time build stage is reached. Ideally, stakeholders agree on the criteria in the earliest stages of development.
The release criteria should address functionality by stating the mandatory functions and perhaps a baseline percentage of features that should be completed. Usability is also important to consider. How long does it take for users to complete key tasks with the product?
The section also needs to touch on reliability and the maximum acceptable failure rate, as well as system recovery from these hiccups. Other topics to consider include performance and supportability. Think about maximum response time and the ability of the product to be tested, serviced, and configured.
4. Schedule
Creating a schedule for product development can prove extremely stressful. Too often, design leads stress over exact timing, which is often a fruitless labor. Avoid exact timing as it could hold you accountable to features that ultimately need to change as the market shifts.
Instead, think about rough windows that provide the necessary flexibility without allowing the development process to continue indefinitely. Creating a rough timetable sets stakeholder expectations and helps keep teams on the same page in terms of timing to avoid situations where features might get scrapped due to time constraints.
This section should also consider all the potential issues related to timing. Think about the workflow constraints that teams are likely to encounter. These constraints could be related to budgeting or resources, for example.
Including these elements makes everyone aware of potential issues so they can plan ways around them. With all these elements considered, teams can be more realistic in creating timeframes for the development of the various features required by the product.