A beginners guide to Product Requirement Document
A topic of ambiguity that has been observed in the Product field commonly is the Product Requirement Documents (PRDs). There are various ways a PRD can be written, PRD for every feature and every product offering differs. Every other Product Manager has his own take on the structure of PRD. So here is my take on it, yes you guessed it right, I am a Product Manager.
Product Requirement Document, as the name, suggests clarifies the requirements of a particular product or a feature in the product, including the purpose of the product, features, functionality, and behaviour. The main purpose of the PRD is to be a guide or easy-to-understand document for the business team and the technical team and make them understand the product or feature to its minutest details. It helps the team to build, launch or market the product to end-users.
Following are the pointers to be kept in mind while writing a PRD
1. TL,DR Summarize the complete requirement of the product/feature in one easy-to-understand statement. Keep it short and make sure that the statement revolves around the WHAT, WHY & WHO of the product/feature. 2. DARCI for product initiative This defines the various stakeholders of the product/feature. Assign a person for each of the following to make sure all the blockers are solved in time so that the development and release of the features does not delays, - Decision Maker - Accountable - Responsible - Consulted - Informed 3. Problem Statement Describe what the problem statement is, why we are trying to solve it, what are the customer or market insights which are the driving force behind the development of the product/feature, or if the requirement is from a certain team(marketing, management, customer support, etc) then add it. 4. Goal There is a reason for every product/feature, nothing is built on gut feeling or just for fun, mention the goals that this product/feature is trying to achieve and metrics that will define the success of the product. Also, mention the North Star Metric or any other metric of the product/feature. 5. Key Hypothesis/ Features & Flows There are multiple hypotheses we derive just to solve one single problem. One of those hypotheses suits best to solve the problem of the users fulfilling the product/feature requirements to their best. Mention the hypothesis here which will solve the problem. Define the statement that how you will be solving the problem. Attach the UX mockups and designs here. If you have multiple mini-features assigned to the main feature mention each feature here. 6. Open topics & key decisions Are there open topics around this feature that we have not aligned on which at the earlier stage were left for development and can be taken into this feature? 7. Out of scope There are certain things that are needed to be removed/avoided during development, which then can be taken into consideration in future releases. Mention those here. 8. Rollout Approach and GTM? How to roll out the product/feature? Small pilot or release to all? Is A/B testing required? How many phases the product/feature should be delivered in? Distribution channel? What platforms & why? 9. Target dates:- Mentioning the dates of the following helps to speed up the process, sit with the concerned team and block the deadlines so every team is on the same page and delivers on time, - Code-complete - UI/UX complete - Test complete 10. Decision log For every Product/Feature release, there are multiple meetings to solve developer queries and some additional features or requirements from the marketing or other teams. It is required from you to add those as MOM in this section, so nothing goes unnoticed.
Do let me know your views on the topic and if this blog helped you in writing your PRDs. Please share your thoughts on the topic in the comments. I am always open to having a healthy conversation over a cup of coffee. Connect on LinkedIn here, Twitter here
Comments