Learn how you can Unlock Limitless Customer Lifetime Value with CleverTap’s All-in-One Customer Engagement Platform.
Failure to plan your product requirements is a plan to flop your product launch.
It’s impossible for a product manager to measure success if there are no initial benchmarks to measure against. It’s difficult to achieve success if the goals in various departments (or even the same department) are not aligned.
This is why product managers must establish their goals, plans, and benchmarks in one document. This single source of truth is where the product requirements document comes in.
In this article, we discuss product requirements, their importance in the lives of product managers, and the lifecycle of their development.
Download our product requirements document template to get everyone aligned with the goals and mission of your product and company.
A product requirements document, or PRD, is a description of the problem, a proposed solution, timeline, and key indicators of success. This form of documentation seeks to answer two fundamental questions product managers must ask: why build it (purpose) and what problem does it seek to solve (value)?
The PRD is similar to the planning stages of a science experiment. Using the scientific method, a scientist will explain the fundamental problem, their hypothesis for solving, an overview of the experimentation process, and any expected variables.
This basic structure is also applicable to product management. PMs use their discussions with customers and observations from the market to identify their customer’s biggest problem, how they believe they can best solve this problem, any variables that could stand in their way, and what success could look like.
Before creating a PRD, you first need to understand your market requirements. What is your Total Addressable Market (TAM) with this product, and even more specifically, what is the Serviceable Addressable Market (SAM) and Serviceable Obtainable Market (SOM)?
All these fancy acronyms help you better analyze your customers. If you believe your total addressable market for a food delivery app is everyone who owns a smartphone, you would be greatly overstating your market opportunity.
Your serviceable addressable market, for example, could be better described as smartphone owners that reside within a certain radius of the restaurant where the order is prepared, and the serviceable obtainable market is those people who do not have dietary restrictions, and so on.
Once you understand the market you are targeting, your product requirements document should clearly state how you plan to solve for that market.
The requirements in your PRD are not set in stone and plans can and do change. This is why your PRD is subject to change as the development process evolves.
The team at Basecamp call this process shaping the pitch. A project’s scope at Basecamp is determined by the team’s “appetite,” or how much can be accomplished in the time they are willing to allocate, or budget, for this product or feature.
In his book Shape Up, Ryan Singer, Head of Strategy for Basecamp, discusses an example. After launching a new version of the product, customers requested a calendar feature.* The team didn’t feel the complexity of a traditional calendar would add enough value to users to justify the investment. In fact, only 10% of customers used the previous calendar features.
Instead, the team determined the minimum requirements for a calendar view that would solve the customer’s pain points and created a viable grid view calendar that allowed people to see at a glance what was on their calendar. This strategy is known as the minimum viable product.
You should always question whether there is an easier way to acceptably solve a customer’s problem and only if the feature is frequently requested or used should you consider building more complexity into the product.
This planning process centers around the vision of the project or product.
As the product manager, you must sell ideas to your team and inspire them towards the end-goal. In this light, your PRD is basically an internal sales document.
We will cover each section of the PRD in detail, but here is an overview of the document:
As an example, we’ll build a requirements document for a CleverTap feature: Custom Dashboards. An in-app dashboard of the most important metrics our customer’s track.
This first section of requirements outlines the problem, vision, goals, and introduces the user persona. As a product manager, it’s important that everyone on your team is clear on who the feature is for, its benefits, what the end result looks like, and how success will be measured.
In our example, the problem is that for customers to understand the changing metrics that matter to their success, they must compile the data from different sources. This process can be time-consuming and slow down decision making.
We also discuss our greater vision for this new feature and how we will measure success. We also discuss who our target user persona is, which in this example is the C-level executive and their direct reports. 
In this section, the details of the project and plan to achieve success comes into focus.
This is where your product management team outlines the who, what, when, and how. Or in the case of a product requirements document, the scope, features, launch date, milestones, and dependencies.
The scope is the allocation of team members that will work on this project, both the individual contributors, like designers and developers, and managers.
This is also where you establish a firm date for the completion of the project and the key milestones to reach the target launch date. You also should look to include a high-level overview of features and the dependencies they rely on.
In our example, we outline the roles for the team that will be held accountable for the outcomes, a target launch date, an overview of the features, loose milestones for building each feature, and any dependencies that must be completed for this project to be successful.
The feature-set is one of the most important sections for product managers to get right, especially what not to scope into the project. It can be easy to mistake nice-to-haves as need-to-haves and want to build the extra functionality that would make the product successful.
The added time and complexity of developing all the bells and whistles push the project out of scope and may not even be used by customers. This is why the features section includes a discussion about the user’s problem. Problem-solving is a key component of product management.
This section includes a name for the feature (project codenames are welcomed, think Apollo from NASA, Operation Crush from Intel, The Manhattan Project, etc.) and a clear description. It’s also a place for your team to pose a value proposition for users, list any assumptions that are tied to that value prop, and the minimum viable product that would enable users to extract value.
In our example, we discuss the customer’s time constraint with analytics and reporting, our planned solution of an automated report with key metrics, our assumptions regarding customer demand and technical capabilities, what will not be included in this feature, and a baseline for success. 
This section is where you can add a helpful visual outline of what the user journey will look like when the product or feature is complete.
These are not intended to be the exact wireframes for developers to implement pixel for pixel. The app’s flow and screens will likely evolve and change during the development process. The Basecamp team suggests using fat marker mockups to illustrate the general idea, but give designers and developers the freedom to create the final version.
In our example, when the user opens the CleverTap app for the first time each day, a daily view dashboard is presented with the most up-to-date metrics and an email recap is delivered, which can also be shared with the senior leadership team or other stakeholders. 
For a product to be deemed successful, there must be a goal to measure against.
A KPI, or key performance indicator, is the outcome that will reflect upon whether the project or product is successful. The baseline, or the minimum starting point, is either where the metric is currently being measured by your team or a general industry standard.
The benchmark is the point of reference to be measured against if successful. The benchmark is the numerical representation of the KPI. Although benchmarks are estimations, they must be reasonably achievable within the allotted time frame. 
If your team is looking for a clear and concise method for documenting the requirements of a project, product, or otherwise, download and print the free template below.
If your mobile marketing team struggles to gain insight from your mobile analytics, sign up for a demo to learn how CleverTap’s intelligent mobile marketing platform can help.
See how today’s top brands use CleverTap to drive long-term growth and retention
