How to Write a Product Requirement Document?
This is part 5 of a long-form series of setting up your Product Documentation.
You can read part 4 here, where I discuss how to draw a Data Flow Diagram to illustrate your Product Flow, and part 3 here, where I discuss how to write a Product One-Pager.
If you already understand how to write a Product Requirement Document and have a process set by your organization, feel free to skip over to the next part where I discuss how to write a Product Events Document for documenting all the user behavior events to be tracked for a Feature or Product Flow.
Product Requirement Document
A Product Requirement Document is a detailed document written for building a Feature or a collection of Features across multiple Products meant to bring together your Product, Design, and Engineering team in sync with a defined Product and Business Objective.
Product Requirement Documents define the ‘Why’ and the ‘How’ of the problem statements. The ‘What’ is briefly described by the Product One-Pager document as we’ve discussed in part 3 and is expanded upon by the Product Requirement Document.
The Product Requirement Document is usually written after the Design part of your Product Development process is completed and you’ve to begin the implementation of code. In this case, your PRD should bring together your Design, and your Engineering team on the same page about the exact number of screens, interaction design, and the backend code that needs to be written to support the frontend designs.
In case a Product Requirement Document is written straight away without writing the Product One-Pager document, it should also contain more context of the ‘Why’ of the Business Objective and the problem selected to be solved.
In the case of EasyRide, the process of a user placing a booking request to a driver for availing a cab online on demand and the drivers responding to the request is enabled by ensuring that there are enough drivers in the user’s vicinity to pick up and service the request. To ensure enough drivers, the ‘Supply’ program managers would be responsible for bringing drivers into the system strategically across different locations and geographies.
Let’s take the same example as taken in part 2 of EasyRide wanting to increase the average revenue per user. For increasing their ARPU, let’s assume that they decide to come up with an initiative of offering Value Added Services for its customers by offering ‘Food’ and ‘Beverages’ on rides. The users would place orders and based on the inventory available with a particular driver, would be offered these food items while on their way to their destination.
We have come up with the following Product Plan from the Program Document discussed in part 2 —
Let’s discuss the structure of a Product Requirement Document by taking the example of the Food Order Flow for the EasyRide Consumer App.
Recapping the flow of the Food Order feature as mentioned in part 3 below —
- If there’s any inventory available with the driver with whom a consumer has booked a cab ride, it’d be displayed to the consumer on the app available for ordering
- If the consumer adds any food item to the cart, checks out, and ends up making the payment successfully, the same order will be sent to the EasyRide Inventory Management system for processing
- The EasyRide Inventory Management would block the food items placed in order by the customer to prevent any overbooking
- This notification will be sent to the driver to request fulfillment of the order to the customer
- After the driver hands over the food order item, the same will be updated to the Inventory System to delist the inventory, and record the order completion, and the same update will be sent to the customer on the Consumer App
Based on the above user flow, let’s assume that your Design team has come up with the following designs to facilitate the user flow for the EasyRide Consumer App —
Objective
The objective should be a simple one-liner explanation of the Product or Feature being built. Following would be a one-liner objective for the EasyRide Consumer App Food Order feature -
Implement the first version of the Food Order Feature for the EasyRide Consumer App
Benefit
The benefits section should describe the potential benefits to the customer or the user of the Product as well as to the organization from the launch of the Feature or Product.
- Provide the customers the option to avail of on-the-go lunch and evening snacks by taking a cab
- Increase the average income earnings per driver per month by offering an extra commission percentage
- Increase the average revenue per active user
Target Customer Segment
The target customer segment should describe your target user for this Product or Feature that you’re ideating upon at this time.
In the current scenario, we’ve already mentioned the target audience for this feature -
- Morning office goers
- Afternoon sales pitch travelers
Success Metric
Success Metric of a Product and a Product Feature may vary. You can consult this article I’ve written about identifying the right Product Metrics to track and this post by Amplitude here which describes how to analyze the efficacy of a specific feature in your product.
Based on the articles, the following could be the success metric for the feature to be built —
Data Flow Diagram
Usually, data flow diagrams are required when you’re building multiple product features together by connecting them or if you want to show the flow of information between various interacting digital entities in the flow.
We’ll have the following data flow diagram for our use case here —
Hypotheses
Your hypotheses should be statements that you’d want to validate as either true or false through the launch of this feature and upon which your future enhancement decisions might depend.
Following could be hypotheses for this feature -
- We hypothesize that there’d be a minimum daily demand of at least 15–20% of ride-completed users at the top of the funnel for food orders
- We hypothesize that there’d be a 5% completion rate for the food ordering funnel from users who completed booking
Please note how we’ve worded the hypotheses above and for both statements, we’d be able to adjudicate to be true or not.
Detailed Requirements
The detailed requirement section should contain the Product Specification of the exact Feature or the Product to be built by your Engineering Team. We had already discussed that at the time of writing a Product Requirement Document, your Design team should have delivered the exact Design Specifications along with all the necessary Assets and Copies to your Engineering team to start coding.
Optionally, you could make the Detailed Requirements section completely exhaustive by writing the specifications of each screen that’s a part of your Product or Feature flow.
I recommend that everyone document each and every screen since this gives your Engineering team exact clarity on the number of screens to be built, the filters to be included on each screen, the fields to be included for searching, and all the possible scenarios for each screen (including data and user flow actions).
The following should be the documentation of the Food Order Flow for the EasyRide Consumer App —
EasyRide Consumer App Food Order
Food Item List Screen
The Food Item List Screen would display the list of the food items in the Driver’s Inventory and the user would be able to add items up to the Inventory levels. The user would interact with the following fields —
Filter Requirements
A user may have the requirement to filter by ‘Food Item Type’ or by ‘Item Price’. You may choose to have filters on the type of item as well as a price slider. Here’s how you can document the Filter Requirement for this screen —
Search Requirements
A user may have the need to search a Menu by either the cuisine or by the Item’s name. Here’s how you can document the Search Requirement for this screen —
Data Scenarios
A user may not see any gateway to order food if no inventory is live with the driver selected for his ride. Here’s how you can document the Data Scenarios for this screen —
User Flow Scenarios
A user may interact with this screen by adding and removing Food Items and proceeding to the next section. Here’s how you can document the User Flow Scenarios for this screen —
Food Item Detail Screen
The Food Item Detail Screen would display the food item’s details on clicking on any specific food item. The user would interact with the following fields —
Please note that there wouldn't be any ‘Filter’, ‘Search’, or ‘User Flow’ Scenario Requirements for this screen.
Data Scenarios
There might not be images available for a few Food Menu Items. Here’s how you can document the data scenarios for this screen —
Food Order Checkout Screen
The Food Order Checkout Screen would list all the items added to the card along with the charges or taxes applied to an order. The user would interact with the following fields —
Please note that there wouldn’t be any ‘Filter’, ‘Search’, or ‘Data’ Scenarios for this screen.
User Flow Scenarios
A user may interact with this screen by adding and removing Food Items and proceeding to the next section. Here’s how you can document the User Flow Scenarios for this screen —
Food Order Payment Screen
Food Order Payment Screen would display the possible payment options and would accept the payment details from the consumer to proceed to order completion. The user would interact with the following fields —
Please note that there wouldn’t be any ‘Filter’, ‘Search’, or ‘Data’ Scenarios for this screen.
User Flow Scenarios
A user may interact with the screen by changing the choice of the payment method and by changing the exact form factor or the payment instrument to be used. Finally, the user would proceed to make the actual payment. Here’s how you can document the User Flow Scenarios for this screen —
Food Order Confirmation Screen
Food Order Confirmation Screen would display the state of the Food Order post payment from the Consumer. The user would interact with the following fields —
Please note that there wouldn’t be any ‘Filter’, or ‘Search’ requirements for this screen.
Data Scenarios
While processing through the gateway, the payment may be successful, fail, or continue to be pending. Here’s how you can document the Data Scenarios for this screen —
User Flow Scenarios
Based on the status of the payment and the order, the user may want to retry the payment. Here’s how you can document the User Flow Scenarios for this screen —
What we’ve observed is that in almost all consumer Products that have a purchase flow such as E-Commerce, Food Delivery, Online Ride Sharing, etc. there are common types of screens across these Products and there are common requirements
Here’s a summary of the flow taken above which applies to a lot of generic consumer applications that have a purchase flow —
Summary
A Product Requirement Document is the bread and butter for any Product Manager and if there’s any skill that you should continue to hone or sharpen, it’s your ability to write detailed Product Specifications in as much as readable form as possible for your Engineering Team to understand and code the entire Feature or Product from scratch.
You may not be required to write a detailed Product Requirement Document for enhancing the user experience design or interaction design of an existing feature.
However, in case of building a new Feature or a Product for a Product Initiative to achieve a Business Objective, I always recommend writing a detailed Product Requirement Document detailing all specifications.
Your Product Requirement Document should contain easy-to-understand Data Flow Diagrams and tabulated summaries for your Engineering team to comprehend the document easily and use the same as a ready reckoner over time.
In the next section, we’ll discuss how to instrument all the user behavior events of a Product Feature to draw useful insights from the Product Analytics.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
Also, shout out to Vivek Singh for helping me out with the designs for this PRD. Do give him a follow.
