Product Requirements Document is one of the main documents a product manager is supposed to deliver. Lack of proper documentation leads to terrible communication between stakeholders and more importantly terrible products. While team structure and product type influences the detailing and coverage of the Product Requirements Document, but I believe that covering a baseline set of points is important to keep the entire team on the same page.
A great Product Requirements Document is an independent document, which can set the entire context for anyone who reads it. Poorly written Product Requirements Document needs a lot of appendages and crutches to convey the requirements. It should almost read like a story, convincing the developer, designer or business stakeholder that “yes, this is the problem and this approach is just the right approach given the data and reasoning”.
If you are planning a dev effort of a month or more, I believe that an involved Product Requirements Document should be created. To aid in memory, I propose this mnemonic P.R.O.D.U.C.T. R.E.Q.U.I.R.E.M.E.N.T.S. D.O.C.U.M.E.N.T. with the expansion given below, as a means to remember the sections that an ideal Product Requirement Document should contain.
When I was starting up, I found it baffling that there is no standard Product Requirements Document template to refer to. There are numerous sample templates floating around on the internet, causing all the more confusion. Hence, I propose the following template to write a comprehensive Product Requirements Document. In a future article, I will share a sample Product Requirements Document written using this template.
|P||Purpose||In this section, set the context for the product. Why are we building it, what are we building and so on. On reading this section, reader should be able to get a very clear sense of why the product is being conceived, what will be the impact and who will benefit.|
|R||Reason||Describe in detail, the reason why this document came into existence. Give the background, the sequence of events which led to the need for this product|
|O||Objective||Give qualitative and quantitative goals of this product. It helps to mention the business goals here and show relation of business goals with the product goals|
|D||Decision||Give the business case for building this product. A good business case, explains the decision based on business metrics and ROI in terms of True North metric, so that prioritization can be done against the same impact.|
|U||Use cases||Describe the business use cases and scenarios. Explicitly mention, which of these are included and which are excluded.
Use case is an interaction with the system that leads to an observable and usually meaningful result. The use case documentation in form of diagram and/or text should clearly outline the sequence of steps that take plane during the interaction and should include the different ways in which this interaction can happen.
A scenario is one interaction through a use case—one way that it might play out.
|C||aCtors||An actor is a type of user or an external system that interacts with the system under design.
There are two types of actors:
Business actors – actors outside of the business who can interact with the business
Workers – people internal to the business who interact with the system. You may divide this further into case worker and internal worker. Case worker is a worker who interacts directly with the business actors while internal workers interact with other workers and internal system entities.
|T||Timeline and Team||Describe the timeline of implementation and who will be responsible for the document, tech lead, design lead and so on|
|R||Route||In this section describe the route for the product. Focus is to answer “how” the purpose of the product will be achieved. The analysis can be divided into broad sections:
Structural analysis and Behavioral analysis. In structural analysis, you describe what is the system composed of and in behavioral analysis you describe how the system behaves.
|E||Expectation pre-set||Detail out the assumptions taken to derive the solution|
|Q||Quality||Define constraints and acceptance criteria for UX and engineering.|
|U||User artefacts||This is the crux of the document. Part of behavioral analysis, write detailed user stories, goal of the user in each story along with tasks that user should do in each story to reach the goal.
Usually I end up writing task first and then arrive at the goal by using the 5 whys tactic.Tasks vs goals is well explained here: http://www.jnd.org/dn.mss/activitycentere.html
|I||Interaction requirements||Part of behavioral analysis, describe in detail the user interaction requirements. Important to note here, you should avoid stepping on the shoes of the UX designer, and only mention the direction via references or wire-frames here. Your quality standards should mention the interaction constraints.|
|R||Rules||Golden rules that all product decisions, design decisions and engineering decisions should follow.|
|E||Entity Classes||Part of structural analysis, describe in detail how the system is laid out as. Break down the entire system into its constituent objects, that the business wants to track. For example, invoice, booking etc.
An entity class is a category of business object, tracked by the system.
All objects of the same class must share the same operations, methods, and attributes.
|M||Map Processes||Use business use-case activity diagram to map the processes in the business. To make it clear who performs each activity, add partitions to the activity diagram|
|E||Exception Flows||Describe flows which can lead to exceptions i.e. failure of use case|
|N||Non-functional requirements||List requirements not visible to the user during the use case—security, performance, reliability, and so on|
|T||Technical requirements||Describe technical requirements covering platform, device, network, language and anything else that may be needed|
|S||State-machine||A state machine is a model of the statuses through which an object passes; the model describes the events and conditions that cause it to move from state to state and the activities associated with each state. The model may be depicted as a state-machine diagram.
|D||Data||In this section cover the data that will help to determine whether the product meets the goal or not. If previous sections answered the “why” and “how”, this section covers “what”|
|O||Outcome expectation||In terms of goals. Map the goals to clearly identified and measurable business metrics|
|C||Consumption expectation||In terms of demand metrics.|
|U||Utilization expectation||In terms of supply metrics|
|M||Measurement plan||Answer how will you measure the metrics. A lot of times this step is an after thought, which leads to delayed or all together missed measurement. Really important that this step is planned up ahead.|
|E||Evaluation Plan||How to evaluate. Describe how will the success or failure of this product will be ascertained.|
|N||Nurture plan||Describe how will the product be nurtured and what will be its frequency|
|T||Testing plan||Describe the testing plan of the product, coverage of the tests and test cases.|
Depending on the product, Product Requirements Document may have all or some of the topics from above. A good rule of thumb is to spend at least 10% of the product development time to creating a Product Requirements Document. Saves a lot of man-hours of developers and designers – who typically are the most expensive resources in the organisation.
Did I miss anything or do you think something is redundant? Do share your thoughts in comments.