Product managers create a lot of documents. Some important, and some even more important. (There is nothing that PMs do that is not important 😜)
Today, I’ll talk about ten documents we, as product managers, create and their importance.
This edition has the first 5 of the 10 documents. Stay tuned for next week’s edition with the remaining 5.
10 documents that every product manager creates
- OKR (or KPI) document
- Product roadmap
- Product proposal / product one pager / business case
- Product requirements document (PRD) / Product specifications document (spec)
- User stories
- Project pages
- Progress updates
- Release notes
- Training material / Go-to-market plan / FAQ / Internal guides
- Results and measurement of goals
OKR (or KPI) document
OKRs
Objective & Key Results (OKRs) is a methodology for setting objectives and measuring progress on those objectives.
Objectives be meaningful, concrete, and clearly defined. They should be be inspirational.
Key results (KRs) should be objective and measurable. KRs should help the team measure the extent to which they are successful in achieving the objectives. A KR should be very concrete and clear. There should be no opportunity for "grey area" or different interpretations.
KPIs
On the other hand, a key performance indicator (KPI) is a measurement tool to help quantify the progress (and success) of different tasks. KPIs are those metrics that measure progress and success of the tasks that are most critical to the business goals.
There can be many metrics, but not all of them are KPIs.
Different companies and teams use these two methodologies differently. Some teams create OKRs and follow them throughout the year. Other teams have broad goals and have KPIs to measure progress.
You should do what feels natural and easy to follow for you and your team.
As a first step, both documents (OKRs and KPI doc) are created collectively by the PM and the EM. Then, OKRs (or KPIs) are reviewed and approved by someone senior in the hierarchy. The approval is mainly to ensure that the team’s objectives aligns with the company’s larger goals and vision.
Example for OKRs:
- Objective: Increase reporting reliability
- KR1: Ensure report generation time is less than 60 seconds for at least 80% of requests
- KR2: Ensure that report generation batch failures are less than 5%
Example for KPIs
- Business Goal: increase revenue in 2022
- KPI1: revenue from new sales
- KPI2: revenue from upsells
- KPI3: revenue from retention
Why are OKRs and KPIs important?
Help you set ambitious goals
OKRs and KPIs provide a structured framework for setting ambitious yet achievable goals. By defining clear objectives and key results, you can challenge your team to strive for excellence and push beyond their comfort zones.
Help you track progress
One of the key benefits of OKRs and KPIs is their ability to track progress effectively. By regularly monitoring key metrics and milestones, you can gauge how well your team is performing and identify areas that may need improvement.
Steer you in the right direction
OKRs and KPIs act as a compass for your product strategy, guiding you towards your desired outcomes. By aligning your goals with your overarching vision and mission, you can ensure that every decision and action moves you closer to success.
Provide clarity and direction
In a fast-paced environment, clarity is crucial. OKRs and KPIs help provide clarity by clearly defining what needs to be achieved and how success will be measured. This clarity enables everyone on the team to understand their roles and responsibilities, fostering alignment and collaboration.
Ensure everyone is aligned
OKRs and KPIs serve as a unifying force, aligning individual and team efforts with the broader goals of the organization. By ensuring that everyone is working towards the same objectives, you can harness the collective power of your team and maximize efficiency and effectiveness.
Give you real-time feedback on success
Finally, OKRs and KPIs provide real-time feedback on your product's success. By tracking key metrics and performance indicators, you can quickly identify what's working well and what's not, allowing you to make informed decisions and course corrections as needed.
Product roadmap
A roadmap is a very critical document that product managers create and maintain throughout their time managing a product. The primary goal of a roadmap is to help all the stakeholders understand what features get built in what sequence and when.
The sequence helps everyone understand the relative priority of the items on the roadmap. The when highlights the tentative dates when said features will be available to the users.
Finally, a roadmap also contains a backlog of all the features that are important but not important enough to build soon. These features might have a priority associated with them but probably will not have a release timeline.
Product proposal / one pager / business case / etc.
The primary purpose of this document is to get alignment either on on new (product) ideas or on ideas that need significant amount of resources.
Typically, this document includes:
Business problem
This section should underline the “why” are we doing or recommending to do something. It should include specifics about the problem - quantitative research, data analysis, etc. This section should give the readers all the information needed to buy-in (or not) to the idea.
I also include some type of sizing the problem. It is always useful to know if the problem at hand is a $10K vs. $10Mn
User problem
In this section, highlight the pain, need, or the problem that the users are facing.
- This section should primarily focus on the user’s problem, which means this might be different from the previous (business problem) section.
- This section should include ALL the user personas that exist for the product, and it should highlight why we’re focusing on a specific persona
- This section should include data and the user research
- It should include all the evidence that we have collected around the problem
- Evidence should be concrete and not be ambiguous at all
It is important to remember that all of the content that goes in this section is validated and verified by stakeholder and partner teams. This helps ensure that we're not misrepresenting any evidence.
Hypothesis
Every one pager should have a clearly defined hypothesis.
A typical hypothesis follows the format of: “by doing X, Y will happen.”
For example: “by ingesting additional consumer events into our analytics platform, we will reduce the time to analysis for consumer teams by xx%.”
Make the hypothesis as objective and quantifiable as possible. Think of this section as answering the question - “what are we gaining from investing into the idea that we're recommending through the one pager"
Opportunity sizing
This section should clearly help understand the quantifiable and measurable impact of solving the above stated problem.
It is best if the impact is measured from the perspective of the business.
For example: “Reducing the time to analysis by xx% will save us XXX hours of analysis time across PM, Engineering, and DS teams. This saving translates to a cost saving of $XXX,000 per year”
Description/details
This section should explain the problem in more detail. Think of adding screenshots, detailed user flows, diagrams, etc.
The goal of this section is to help the readers understand the actual problem. So feel free to get down and dirty and share as much information you need. Feel free to make it technical. But maintain a good balance, as the doc will also be read by a non-technical audience.
This section should also include some sense of the cost of development (aka investment required) to create the proposed solution.
Typically, one pagers are written early in the life cycle, and you might not have accurate timelines or effort estimates at this time. That is OK.
In that case, discuss with engineers to get a ball-park estimation of the investment required.
Experiment details (optional)
There are times where the one pager is only recommending an experiment.
Or there are times where the proposal has some assumptions built in, and the best way to validate those assumptions is to run an experiment.
In such case, use this section to share details of the experiment setup, primary, secondary metrics, etc.
Success criteria
This section should answer the question - “how do we know this is successful”
This section should include the metrics we intend to use to measure the success
This should also include goals for the metrics. For example:
- Primary metric: time to analysis
- Goal: reduce by 13%
I also like to include secondary metrics and guardrail metrics in this section.
If there is already a dashboard or report that you use to monitor the above mentioned metrics, please add links in this section for the same.
Open questions / out of scope / things to do later (optional)
This section should include ant questions that were unanswered at the time of writing the one pager.
It could also include items that were left out of scope on purpose.
This goal of this section is to document the conscious decisions you took and/or tradeoffs you made while creating the one pager.
Liking this post? Get the next one in your inbox!
Product requirements document (PRD) / Product specifications document (spec)
A product requirements document is an agreement between the product manager and the engineers on the scope they decide to develop as part of the next release cycle.
Typically, the PM (product manager) creates this document, but it goes through multiple iterations based on feedback, comments and questions from the engineers.
Read this article for more details on PRD - what it is and how to create a comprehensive one.
User stories
User stories are usually a replacement for PRDs and are more commonly used by teams following agile software development methodologies.
A user story is an easy-to-understand description of the product feature written from the users’ point of view. It focuses on explaining what the user can do with the product feature and the value that they should get from the product or feature.
A typical user story follows the format of "As a user, I should be able to do <<insert action here>> so that I can <<insert value here>>"
Like PRDs, user stories are an agreement of what the team will be developing as part of the release cycle.
PMs should also include acceptance criteria for each user story to ensure comprehensiveness.
Acceptance criteria are conditions the feature must satisfy before the team makes it available to real users.
Acceptance criteria also help in:
- Removing ambiguity from the user stories (and requirements)
- Creating precise testing (go/no-go) conditions for the specific featurePreventing scope creep
Example
User story
As a manager, I want to change my team member’s task status so that I can keep the status sheet accurate at all times.
Acceptance criteria:
- The manager should be able to change the status of her team members’ tasks.
- Given that the manager has changed the status of member A’s project:the updated status should reflect in member A’s view.
- A new entry in the change log with the user ID of the manager, project ID, original value, changed value, and the timestamp should be stored
Project pages
Project pages are simple documents that do three main things. For each project, it includes:
- details of the team and people who are working on the project
- links to relevant documents, details, JIRA tickets, analysis
- most updated status on the overall project
PM, EM, and engineers collectively own creating and updating this page.
Project pages make it very simple for execs, people managers and non-technical stakeholders to track the progress of the projects of interest.
There is no set format for this page, but I like having Wiki pages with 3 different sections:
- Project details and progress
- Milestones
- Supporting links and docs
(Screenshots below, full sample doc here)
Progress updates
I like to do most progress updates via email and very few via face-to-face meetings.
Generally, the channel you use depends on the kind of project, audience, and a few other factors – simple, regular, standard updates via email, urgent, major, complex updates via face-to-face meetings.
It is important to remember that “progress updates” are “updates” and not a detailed explanation of the project.
Hence, I keep my updates simple, brief and to the point:
- Project status: on track/delayed/live
- Launch dateCurrent focus: what is the team working on right now
- Next milestone: what will the team work on next
- More information: links to resources(Sample screenshot below)
Release notes
Release notes include a list of new features, minor changes, enhancements, and bug fixes launched with their respective launch dates.
More often than not, release notes are technical and created by the engineering team working on the launch.
The primary audience of this document is a mix of EMs, engineers, and PMs.
Most teams maintain a repository of their release notes, which acts as an easy reference to all past product launch details.
Training material / Go-to-market plan / FAQ / Internal guides
These documents are typically created only for medium or large product launches.
In my experience, I have created such documents when I’ve needed to do one or more of the following:
- Train internal teams on new products/features. Customer facing teams (ex: customer support) must know how the product works. They must have the required information to help users use the product and resolve issues. So, it is critical to create detailed training modules, FAQs, and product guides every time there is a major launch.
- Enable launch teams to drive awareness and adoption. I’ve been part of launches that required a lot of PR and marketing to create hype and awareness of specific launches. Such activities need multiple teams (product, engineering, marketing, design, etc.) to work together. And having a detailed GTM (go-to-market) plan makes it easier to collaborate and deliver.
- Enable teams to deliver on time successfully. I’ve had launches with multiple complex dependencies across various teams. Delay from a single team flows to all down stream teams, leading to a delay in the final launch. In these cases, a detailed launch plan helps to define the deliverables, owners, ETAs, and to ensure every person is speaking the same language.
Most of these documents do not have a set format. But, since these documents’ audiences are diverse, it is critical to use a format that all persons understand easily.The best way to start – understand from other PMs what’s worked in the past. If that’s not an option, work directly with the internal stakeholders (or internal customers) to co-create templates for each case.
Results and measurement of goals
Product managers create these documents/emails when they have meaningful results from a recent launch or an experiment.The document’s goal is to inform senior leaders and other stakeholders of the results and the appropriate next steps (where relevant.)As always, I keep this super simple:
- What is it
- What are the results: metrics and definition
- What are the next steps
- Links to raw data and other details(Screenshot below)
I also like to maintain a log of these updates in a single document for easy reference.
That is it for now. If there are other documents that you create in your day-to-day, please let me know by commenting below.
More from
Fundamentals of Product Management
