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

1. OKR (or KPI) document
2. Product roadmap
3. Product proposal / product one pager / business case
4. Product requirements document (PRD) / Product specifications document (spec)
5. User stories
6. Project pages
7. Progress updates
8. Release notes
9. Training material / Go-to-market plan / FAQ / Internal guides
10. Results and measurement of goals

OKR (or KPI) document

Objective & Key Results (OKRs) is a methodology for setting objectives and measuring progress on those objectives.

On the other hand, a key performance indicator (KPI) is a measurement tool to help quantify the progress (and success) of ongoing tasks.

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.

Tactically, both documents 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

• Goal: increase revenue in 2022
• KPI1: increase new sales by 15% in 2022
• KPI2: increase upsell by 10% in 2022
• KPI3: increase retention from 80% to 87% in 2022

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 on new (product) ideas.

Typically, this document includes:

1. The business problem to solve
2. Size of the business problem
3. Potential impact of solving the problem
4. Details of the problem

This document does not mention the solution or the product itself. It focuses only on the problem space.

The typical audience for this document is the person(s) or team which provides the required go-ahead for investing.

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.

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>> (Example below)

Typically, PMs write user stories.

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:

1. Removing ambiguity from the user stories (and requirements)
2. Creating precise testing (go/no-go) conditions for the specific feature
3. Preventing 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:

Scenario: 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:

1. the updated status should reflect in member A’s view.
2. 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:

1. details of the team and people who are working on the project
2. links to relevant documents, details, JIRA tickets, analysis
3. 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:

1. Project details and progress
2. Milestones
3. Supporting links and docs

 

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:

1. Project status: on track/delayed/live
2. Launch date
3. Current focus: what is the team working on right now
4. Next milestone: what will the team work on next
5. More information: links to resources

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:

1. 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.
2. 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.
3. 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:

1. What is it
2. What are the results: metrics and definition
3. What are the next steps
4. Links to raw data and other details

I also like to maintain a log of these updates in a single document for easy reference.