The PRD is used to define’s the product’s purpose, features, functionality and behavior. The specifics within the PRD can vary by the organization. Some companies can call it Product Design Document and more emphasis may be on the product design element. However, evrey product is accompanied by a PRD.
Use Case: The product team will use the Product Requirements to build and test the product.
Analyze the customers and Market – Understand your customers, study your competitors, team’s capabilities and the available technologies.
Define the Product’s Purpose – Every product needs to solve a customer need/ add delight to the customer experience (which also solves the need for a good customer experience). Thus, a very clear value proposition for the product needs to be defined. Also, the objectives of the product are the user needs the product aims to solve.
- The problems you want to solve, not the solution
- Describe the scenarios
- Who is the target user?
Objectives could be:
- Ease of Use
- Increase in session time by ~10%
Objectives need to be measured to ensure that once the product is released, the objectives are met. The details of measurement of objective needs to be explained. As an example, the ease of use can be measured by the time spent by user on each task, % of successful completion of a certain task, the user engagement etc.
Thus the product’s purpose, defines the user needs solved by the product and define the success state for the product.
Define the User profiles, goals, tasks & principles –
User Profiles: Once the customer needs are defined, the user profiles i.e. personas needs to be defined. Defining the persona and the context of the product in view of the specific persona, helps tailor the product. User persona could be user journey or a detailed description that helps set the customer context. The target user base needs to be precise and well-defined.
User goals: Each user persona may use the product to meet certain goals. Thus, the goals as it related to each persona needs to be clearly defined.
Tasks: The tasks that can help people accomplish the goals needs to be defined.
Each team can identify a list of product principle that will help guide the team throughout the product life-cycle. The principles should be specific to the project and the domain on hand.
Product Features –
The requirements, need to be clear, unambiguious and state the need. Each feature should be defined at the level of the interaction deisgn and use cases. The user exeperince and what each feature is should be described while leving the implementation/ other flexibility to the engineering team.
Requirements Traceability: Each requirement needs to be traced to objective(s). This helps deduce the impact if a certain requirement is taken off and ensure that all the requirements are adding value towards the overall objectives.
Release Criteria –
The release criteria mentions important non-functional requirements such as Performance, scalability etc. which are very critical specifically in software products.
The schedule should describe the timeframe for the project, the context behind the timeframe and the motivation for the timeframe. This can hehlp motivate the team.
Feature Prioritization –
The features listed in the product can be categorized as “must-have”, “high-want” and “nice-to-have”. Within each category, the features can be ranked 1 through n. This will help implement the important features and ensure that the high priority features are completed and tested before the product hits the market. Further, if additional requirements are to be discovered and added during the design/ implementation phase, this ranking will help cut the existing features to accomodate new ones.
The PRD can be tested for completeness and refined continiously.