A significant portion of a Product Manager’s time is dedicated to constructing and managing Product Requirements Documents (PRDs). This involves brainstorming with teams to determine the needs of the product and its stakeholders, gathering detailed requirements, constructing new PRDs from scratch, and then regularly updating existing PRDs to ensure their accuracy. This is a fundamental part of the product manager’s job and is key to the success of any product. It is often a time-consuming process, but it is essential to ensure the product meets the needs of the stakeholders and customers.
What is a Product Requirement document?
The Product Requirements Document (PRD) is a comprehensive document outlining the specific requirements and functionality needed to create a successful product. It serves as a crucial starting point for design and engineering teams to plan the product development process, including outlining the timeline, scope, and resources necessary to complete the project. Additionally, the PRD details the development order, dependencies, and goals for tracking the progress of the product. It is also a valuable tool for product managers to adjust the timeline and resources based on the development process results. By having a well-crafted PRD, product teams can ensure that the product meets the desired goals and specifications while staying on track.
The Product Manager should own the Product Requirements Document (PRD). However, it is essential to involve other teams in the requirement-gathering stage to brainstorm and discuss flows, features, and, most importantly, to understand design, engineering, and process limitations.
What does a PRD consist of?
Objectives This section should explain the rationale for developing the product. It should clearly articulate the purpose of the product, the problems it seeks to solve, and the features that need to be implemented to achieve those objectives.
Note: Objectives should be measurable and achievable. Avoid high-level objectives like “Increase number of transactions”; instead, use a quantifiable objective such as “increase number of transactions by 5%”. This can then be used as a metric to measure the success of a feature or product.
If writing a PRD for a complete product, features and objectives can be broken down into high-level epics. These can then be iterated on post product development by adding metrics and quantifiable expectations from the product.
Stakeholders and Users
The PRD will clearly need to state the stakeholder for which the feature is being built. If internal teams like customer success, support, or external users of the product.
User personas should be included in the product to help other teams understand the product from the users’ perspective and who they are building it for. This also allows the marketing and sales teams to create better distribution strategies for their target users.
User Stories and flows:
User stories are narratives that explain how and why a product is used from a user’s perspective. They should outline the main features and functionalities that users intend to use or can use.
A well-crafted user story follows this template:
As a <type of user>, I want to <perform a particular task>, so that I can <achieve a particular goal>.
- User stories need to be short, precise and to the point.
- They need to be illustrated from the user’s point of view.
- They need to have a specific goal/ objective to be accomplished by the user and the reason behind it.
It is also helpful for teams if user flows are clearly defined. A user flow is a visual map of the path the user takes through a product to take action and achieve the goal mentioned in the user story. It is a visual step-by-step path the user takes through the product from entry to the outcome. This helps add another layer of details for engineering and design teams to define the outcome.
Wireframes
Wireframes are designed layouts of your product screens consisting of the elements essential for the feature. (buttons, dropdowns, menus etc.) It is constructive to brainstorm with design and engineering teams to understand possibilities and limitations. Wireframes are quick and easy to implement, so the teams can iterate on them before coming up with high-fidelity mockups.
The PRD can also contain finalized high-fidelity mockups based on the team’s internal processes and responsibilities.
They serve the purpose of providing visual cues for development and also providing designers with a base requirement for them to begin work on. The more detailed it is, the lesser the ambiguity on features and development, saving time and resources for the business.
Dependencies
There are broadly two types of dependencies that product managers need to be concerned about;
System Dependencies: Identifying and remedying system dependencies are essential so that the released features do not break any other features in the live product or create a roadblock from users accessing a particular section of the product or taking a specific action. In case of any dependency, product managers will need to mention the dependency or conflict with the current system and provide steps to remedy it.
Stakeholder dependencies: Stakeholder dependencies are more at the requirement-gathering stage, where there is a dependency on a particular stakeholder to provide insight or share knowledge specific to their domain to help product managers define features and functionality better.
It is an essential part of product management to manage and address dependencies.
Metrics, Reports and Tracking
Metrics: Metrics are essential to monitoring the progress of a product. How can product teams establish a product’s or feature’s success or failure? Are the features released even being used? and if yes, with what frequency? How are they contributing to business outcomes?
Product managers need clearly define the metrics that need to be tracked, what frequency and the reports that need to be generated to analyze. This informs the engineering and analytics teams to create, modify and add attributes and create dashboards or information for product teams to track specific metrics.
Release Criteria
Release criteria are a list of milestones that need to be met by various teams before determining the feature or product is ready for release. They help define the meaning of “done” and ensure an error-free product is released to the users. They usually comprise the following:
- A set of must-have functionality in a feature that is defined by the product team. It can be a certain percentage of the overall feature as well.
- Testing coverage: Complete testing coverage for the feature in the test and production environment. An assessment of the number of test cases run and the ratio of successful vs failed test cases. Bugs that exist and priority. (Usually, minor/ minimal priority bugs can be passed through with all the major and medium impacting ones resolved.) Several test cycles run and progress from cycle to cycle.
- Sign off: Demos of the features to relevant internal teams and a sign-off from them to release the feature to users.
- Internal support and Knowledge Transfer: Before a feature is released, the customer-facing teams must be educated and trained on the feature so that they will be in a position to engage with customers and answer any queries they might have regarding the newly released features. (Usually sales, customer support and marketing teams).
Scaling Up: Not a mandatory item but nice to have is to share a future version of the feature currently being built. This helps engineering and design teams build out architecture and designs that allow for the inclusion of future versions so that there isn’t any major rework of the feature. This increases efficiency and helps in saving time during future development.
Here is an excellent example of a good Product Requirements Document.
Once a feature is released, product managers must seek out and understand feedback and usage of the features. From speaking directly with customers and keeping a close eye on the use and success metrics, valuable insight can be determined for the future of the product. It will help us understand what worked for the users and did not. It is critical for product management to keep a tab on this set of insights. New feature ideas and more might stem from this.
In the end, PMs cannot sit on their laurels long. They need to keep pushing the needle forward, building out new requirements for future versions of the product, brainstorming with stakeholders and pushing out new releases, it is the continuous loop of product management.