Thursday, June 20, 2019

The Anatomy of an Effective Product Definition Document

A product definition document is a product management artifact that serves two purposes. First, it helps to gather and organize a team’s thoughts. Second, it serves as an artifact for collaboration and debate. I ask every product manager I work with to write a product definition document. If they are new and don't know how to write one, I give them this framework and help them think through what they want to do and think about how they want to communicate their thoughts to others. When I review the product definition documents written by product managers every quarter for potential implementation, these are the things I look for. I have shared some sample content where possible.

Every product manager I work with receives these inputs from me. This is my framework to make product managers develop empathy for the user, to make them collaborate with the technical architects, make them realize that they are a custodian of the solution rather than the inventor of the solution, make them develop a point of view and defend it, and help them come across as credible when they propose a solution.
1. A meaningful title that everyone in the organization can understand. Product managers who can write a meaningful title demonstrate that they have thought about the nature and scope of the problem.
2. Date
Sometimes a document is read months after it is written. The date provides valuable context. If the document is edited months after the creation date, it is useful to add a last updated date. 3. Names of authors, and contributors.
This tells me who wrote the document and who gave inputs for defining the problem and the proposed solution. I look for inputs from end users, architects and engineers. No co-authors or contributors is a red flag. Lack of collaborators could be an indication of limited experience, selfish behavior, not acknowledging the value others bring or insecurity. 4. Purpose of the document
Sometimes the document is written as an artifact for collaboration. Sometimes it is complete enough for development. Sometimes it needs legal or clinical review. This section tells me if the product manager thought about the purpose and audience of the document. 5. Explanation of key words
Explanation of the key words used in the document is to ensure that the product manager understands all the keywords and can explain them in simple words. This is hard to do. A document with key words explained leads to clear concise conversations and work sessions. It is usually best to build the keywords as you expand the document. Here are a few samples. Note that there are no use of abbreviations or jargons. 
  • Sweepstakes: A promotional drawing in which prizes are given away. Participants enter sweepstakes or are automatically entered in sweepstakes. There is no certainty of reward
  • Program is the framework used by our products to enable users navigate their health benefits.
  • Activities refer to trackable steps within a program. These are used to monitor and encourage participation.

6. Executive Summary that clearly conveys what we plan to accomplish.
Executive summary is not just for executives. It is for everyone. It describes the user persona, the job they want to get done, the pain they will go through if the job is not done and the gains they get with the solution proposed. In some cases, the author can outline the proposed solution and the top 5 steps to execute the assignment. Usually it is best to write the executive summary after writing the full document. Writing this well is hard. In general, the more experienced the product manager, the better the executive summary is. Here is an example executive summary:
Executive Summary:  The user growth team at the customer organization is tasked with converting retail banking clients into digital wealth management clients. While on-boarding into the digital wealth management platform, if they drop off, the email marketing team wants to (The Job) reengage such users via email or phone. To do this they need to have data about users who dropped off and the stage at which they dropped off. If they do not have such data (The Pain) they wont be able to execute user re-engagement campaigns. We (the software service provider) will provide this data as an API to the customer's marketing team so that they can (The Gain) see this data in real time in their customer relationship management system and re-engage user who dropped off. To accomplish this we will do five things. First, we will understand the exact data elements required by the customer. Second, we will validate that such data is captured and stored in the product database in a reliable and sustainable manner. Third we will build an API to make such data available to customers in a secure manner. Fourth, we will test the API in an internal product to ensure that the APIs are functioning as required. Fifth, we will document the APIs and conduct a training session for the customers technology team so that they can consume the data and visualize the same in their customer relationship management system.

7. A diagram explaining how the user will consume the product or feature.
A simple diagram, usually abstract, that explains the core solution is arguable the most effective part of the product definition document. This is done before the user interface mocks or prototypes are created. I look for annotations and user personas to determine if the product manager understands who they are building the feature or product for. This diagram is not hard to do but few product managers take the time to draw such diagrams. The ones who do are way more successful in delivering a useful solution on time compared to those who don't.

Figure: Sometime all it takes is the photo of a hand drawn diagram

8. Details of the feature explained in sentence format with diagrams
This section is usually short when I review the document. it gets built with every work session. The content of this section depends on the nature of the feature or assignment. It may have diagrams, screen shots, tables and descriptions of the feature. 9. Outline of risks, assumptions and limitations
A product or feature will always have limitations. An effective product manager always points out the limitations and boundaries of the product clearly. When I discuss the scope of a feature with a product manager, discuss what we do not plan to do as much as what we plan to do. 10. Acceptance criteria used to verify completion of work.
This is to tell the engineering team what the product manager will look to verify completion. The best product definition documents start off as a 2 page document and may go up to 5 pages. Anything more could be built in a prototype or can be broken up into multiple assignments or phases.
Related Posts Plugin for WordPress, Blogger...