A successful product definition and development efforts require much more than just the user’s needs. A product Requirements Document (PRD) is a document that provides a comprehensive road map and guidelines representing all the dimensions of developing a successful product.
This article will explore what a PRD is and how to write one. We’ll also look at the components that should be included and the pros and cons of using one.
The Model For Product Requirements
In 1960, in his book Marketing Management, Philip Kotler put forward the concept of five levels of a product. While the model had a predominantly marketing angle, it is relevant for every product manager to understand its core concepts and see how you can utilize them while defining product requirements and product development.
Core Product
The core product represents the most fundamental need that the product aims to solve. For example, mobile phones aim to solve the connectivity problem on the go. Cars facilitate faster and more flexible transport.
Generic Product
A generic product is a set that provides the bare minimum functionality for the customers to satisfy their core needs. For example, before the advent of smartphones, feature phones provided connectivity through voice calls and text messages (SMS). The core needs for connectivity, and mobility were satisfied.
Expected Product
Customer will expect, without implicitly saying so, certain features when they buy any product, even if it provide the bare minimum functionality. For example, in the case of a basic mobile phone, you would still expect the facility to reply to or delete a message or view a missed call and the ability to call back the same number.
Augmented Product
The augmented product covers a range of options, from additional features to service and overall experience. Our example may refer to warranty, post-sale service, and accessories like earphones and chargers.
Potential Product
The potential product refers to the evolution of the product and how it can continue to delight customers. This dimension will include the overall user experience throughout their journey, including purchase, delivery, and even unboxing of the product.
A Simplified Version
Many product managers use a simplified version of this model, where only three levels are considered instead of five: core, actual, and augmented products.
💡 When thinking about the product, using Kotler's model will ensure that you have considered all dimensions of product success over the lifecycle.
Why do you need a Product Requirement Document?
Throughout the product development lifecycle, you will generate many artifacts and documents that may contain valuable information and insights. A Product Requirement Document (PRD) serves as a comprehensive guide by including every such information in a single place.
- PRD serves as a single source of truth for all product-related decisions.
- It outlines the goals and objectives and ensures stakeholder alignment toward those objectives.
- It provides a reference to cross-functional product teams.
- Provides a coherent guideline for execution to keep the entire product team on the right track.
- A PRD enables clarity about the product path ahead.
Are Product Requirements Documents Still Relevant?
In the past, PRD used to be static documents with information overload. Those were the days when product development followed a predictive lifecycle approach. However, sustaining businesses using such methods is even more difficult with today’s dynamic landscape and complex products.
Given these changes, many people ask whether the PRDs are still relevant.
The Evolving Nature of PRDs
As we just discussed, the PRDs can still be a valuable source of alignment and information. However, the nature of the PRDs has changed. Instead of large, static documents, they have started taking a leaner shape. They also evolve as the business and product landscape changes. The evolution is in sync with the product roadmap (we will discuss those later).
Components of A Good PRD
While there are many templates and formats available for PRDs, and they vary significantly at times, a good PRD would answer the following questions;
- What problem are we solving? What is the target audience? What are our product goals?
- Why are we focussing on this problem over others? What is the outcome expected? What is the market opportunity?
- What are the different dimensions of that problem that we must address? What are the critical components of the problem that we will address? You can represent these aspects through user stories, Jobs-to-be-done or any other format describing product features that enable the team to execute on those requirements.
- How should we prioritize the requirements?
- What will be our go-to-market strategy? How are we going to handle product release cycles? What is going to be our release criteria?
- What end-to-end experience do we want the users to have?
- How will we drive product design decisions?
- What are possible risks that we foresee? How will we address and mitigate those risks if they come true?
- What are technical considerations? What is going to be the product development process?
- What metrics will we use to ascertain whether the outcome is what we expected and wanted? What does our success metric look like?
Of course, the context will determine if there are any additional questions that the PRD should answer. A great PRD would address Kotler’s product levels as they are required to develop, launch and sustain a successful product.
Approaches To PRD Development?
As such, the PRD must balance being the single source of truth and remaining lean for the product development team. There are a few approaches that can help you do that.
- Separate static and dynamic information and maintain a link between those.
Some product information, like product vision and overall strategy, will remain relatively static throughout the product lifecycle. Even if it changes, such changes will be less frequent.
The feature documentation will continue to be added dynamically, along with any high-level changes in strategy, technology or any other area.
The dynamic documents will be linked with the static information so that there is still accessibility across all the information.
In one sense, it will be a set of Product Requirements Documents rather than a single document.
- Separate high-level and detailed information gradually.
Another approach is to move gradually from high-level to detailed documentation. Initially, you can prepare a product brief with high-level product information/requirements.
Once the requirements and directions start becoming clearer, another document, a product specification, just sufficiently detailed, is created. This document contains the requirements and possible roadmap.
You can then create the full-blown PRD as the development is about to start, which includes detailed information that provides clarity and direction to the product teams, including design, marketing, and engineering teams.
Both these approaches ensure that a PRD remains a guide for achieving the product goals through the life cycle by becoming a living document. It also ensures alignment between key stakeholders by clarifying product strategy. It guides product designers and developers throughout the product life cycle, from the product launch to all subsequent releases and phases.
A product requirements document is a critical tool for product development. Discover what makes a great one and how to create it with this comprehensive guide.
