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 states the problem, 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:  Product features such as Programs, Events, Employer Messages, Surveys, Assessments, Challenges, Rewards and Store shall use the segmentation framework  to make instances of such features available to select segments of people. For example a certain employer message may be sent to men in the state of New York.  The professional services team,  will create segments using 15 standard attributes and 5 custom attributes chosen by the customer. The custom attributes will be defined in the eligibility specification by the customer in conversation with the professional services team. Once defined and ingested, these custom attributes will be available for segmentation for the customer.

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.



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...