The Product Requirements Document or PRD describes all aspects of a new idea required or desired to make its realization a success. The PRD is the bridge between the often vague project briefing and the highly detailed engineering implementation plan. It is also known as the Program Of Requirements (POR), Product Specification, or Product Nucleus in some circles.
The purpose of the product requirements document (PRD) or product spec is to clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior. The product team will use this specification to actually build and test the product, so it needs to be complete enough to provide them with the information they need to do their jobs.
Some products are simple enough not to require a PRD, but it is indispensable for more complex products. With complex integrated products, many different aspects come into play to meet their own set of requirements. There is hardware, software, electronics, user experience, assembly, branding and labeling, packaging, interoperability, service policy—the list goes on.
A PRD is first and foremost a broadly scoped outline for the development trajectory that makes the requirements explicit from the perspectives of different stakeholders, product aspects, and processes involved. User testing of current products, user surveys as well as observational studies but also design explorations, technological developments, new business strategies, socio-cultural trends, repair and maintenance, a changing environment, new production processes such as digital fabrication, logistics, packaging, legislative regulations, anthropometry data, and literature are all viable sources to generate requirements for upcoming products.
A PRD is most of all an overview of product features, an explanation of how they contribute to the success of different stakeholders, and a demonstration of how they will play out in different use cases. In its most compact form, an initial PRD is nothing more than a shortlist of key requirements that may grow longer and more accurate over time to reflect the evolution of design decisions.
Besides guaranteeing a successful translation of the project originator’s vision to a tangible product, there are multiple advantages to setting up a PRD:
- It evaluates and spots future obstacles
- It helps establish evaluation criteria for the success of new products
- It conveys the priority of the product’s different aspects: A good way to convey prioritization is using a triage; divide all requirements into must-haves, want-to-haves, and nice-to-haves. This way, designers and engineers know that without meeting the must-haves, the product will never even come to fruition. And without meeting at least a few want-to-haves, they may create a minimum viable product, but customers and product managers alike may not like it. The nice-to-haves are extras that will be developed in case of extra available resources. Assigning a priority number, say on a scale from 1 to 10, to the different requirements also aids in concept selection as it makes it possible to calculate a success score for each concept, for example, through the Quality Function Deployment method or other types of decision matrices.
- It instills awareness of the various customers and use case scenarios
- It firmly roots the role of product management into new development processes
- It ties product development to a comprehensive vision rather than just being a series of feature additions and improvements
- It ensures the soundness of the design
- It provides a full overview of the project which will help everyone to tell and sell its story
- It improves multidisciplinary teamwork and comprehensive mutual understanding
- It relieves the stress of the unknown by making the project comprehensible for those involved which uplifts the spirit and gets people in gear
Expressing Requirements with User Stories
A big part of building a software system is determining what the customer wants. We call these requirements, and there are many techniques for eliciting or discovering requirements from a customer or user.
User Stories
Once a requirement is elicited, it needs to be expressed in some form. One technique for expressing a requirement is called a user story. A user story is simply a requirement, often from the perspective of an end-user, which is stated in natural language. A user story looks like this:
As a ______, I want to ______ so that ______.
Put the user role into the first blank. This may be quite simple for software in which there is generally only one type of user, or a bit more complex in cases where the software may do different things for different people. Either way, this clarifies who wants to use this feature.
In the second blank, put the goal that the user role wants to achieve. This will lead to some feature that you want to implement.
After so that, put the reason why the user role wants this goal. Sometimes this clause is omitted if the benefits are clear and generally known.
PRD Document
The PRD then goes on to describe the sources of the requirements: the stakeholders and their role in the product life cycle (PLC), as well as use cases demonstrating the envisioned use of the product’s key features by real people in real situations.
The requirements themselves are best grouped under the product’s different aspects because this is the most complete way of listing them. Different stakeholders and use cases may bring up overlapping or identical requirements. At the same time, a clear categorization of the product’s aspects in areas such as hardware, technological functionality, interactivity, software, aesthetics and customization, manufacturing, and regulations results in a list that thoroughly covers all the points.
A PRD typically starts with a title page that contains general information such as the project name/code, company and division, responsible manager, date of creation, and version of the document.
- Title section
- Project title and/or code
- Responsible manager(s)
- Date of creation
- Document version
Define your purpose:
It is essential that the product manager establish a very clear, concise value proposition that lets her easily communicate to everyone – the product team members, company executives, customers, the sales force – what the point of this product really is.
- Introduction: The introduction then sets out the context of the project and describes why the new product needs to be developed in terms of needs experienced by different groups of people towards the desired future situation involving the new product.
- Background Information / Context
- Problem Definition / User Needs: Customer satisfaction surveys to gauge need among users, technology developments
- Objectives: The body of the PRD begins with a description of the project’s objectives. This includes the overall vision for the product and high-level goals for the company paired with success metrics, Key Performance Indicators (KPIs), and a timeframe wherever possible. What do you know about the market, user, and your own company’s goals that make this the right product to build? What assumptions are you making about all three of those categories?
- Vision: improved user experience, better fit, improved product design, product customization options
- Goals: Use clearly written complete sentences and specify physical quantities wherever possible. It is best practice to make use of the SMART principle; goals have to be specific, measurable, achievable, relevant, and time-bound. Where possible, show how the different product features will contribute to the success metrics of your business. This way of formulating requirements also helps to make product managers aware of irrelevant goals or constraints that may not be grounded in the territory of the design problem, for example out of habit, misunderstanding, or conformity. units sales target, market share, expand the user base, match competitors.
- Product Positioning: market segments including luxury
- Stakeholders
- Users: Think about your ideal user(s) and how they’re going to interact with your product. Name them if possible and write a brief description. for example high-income upper-class professionals, age group, main benefits
- Purchasers
- Manufacturers
- Customer Service: Eay to repair, recyclable product, easy to fix complaints
- Marketing & Sales: unique selling points and user experience
- External Partners
- Regulatory Instances
- Retailers: prefer products that can withstand a wide range of storage conditions including variation in temperature, humidity, and atmospheric pressure; strong, theft, and vandalism-proof packaging.
- Regulatory instances
- Use Cases
- User Story #1
- User Story #2
- Etc…
- Aspects
-
- Hardware
- Software
- Design
- User Experience: How easy and effective do the core functions need to be? How important are UX and design at this stage?
- Interactivity
- Customization
- Manufacturing
- Reliability: How consistent should the product be? What level of failure is acceptable?
- Supportability: What levels of ongoing maintenance and support will be possible (or are realistic)?
- Regulations
- Open Questions / Future Work: The PRD also includes topics that need further research in order to be able to complete the document. These are the unknown factors not yet decided upon that may drive product development in new directions at the time they are answered. A company may, for example, want to perform research into new materials like high-performance resins that open up new markets and design opportunities, such as 3D printed insoles for shoes.
- Timelines:
- What’s your ideal launch date? When do you want to go to market or start beta testing? Is this flexible? By how much? What are your other constraints? Are other teams dependent on your release?
- Milestones: Concept preparation, Design presentation, design freeze
- Resources: What other resources are you short on? Do you have budget issues to consider?
- Appendices: competitive analysis
- Glossary / Explanation of Terms
References and Resources also include:
https://formlabs.com/blog/product-requirements-document-prd-with-template/