🗺️

A guide to centralized product documentation

Introduction

This is a first of a few articles committed to helping product managers at companies large and small get a handle on their documentation.

💡
Product managers with clear, transparent, and centralized documentation for their decisions align the company, allowing them to release with the weight of the entire organization behind them.

In this article, I'll devote my time to the key tactical elements of product documentation that worked for my team at Cheetah. This guide is most useful for:

  • Nascent/emerging product organizations who liaise with many teams
  • Dispersed product "pods" (squads, PDE, whatever your company calls them)
  • Product leaders who believe their current documentation processes need an overhaul
⚠️
This guide is definitely not a "one size fits all". If you're a seed stage company seeking product-market fit, a lot of this is overkill and not necessary.

If you’d like to see the full set of PM resources, check them out here.

Foundational elements

The three foundational elements to product documentation are the following:

  • Product Requirement Documents (PRD)
  • Product Roadmap
  • Product Calendar

These three components are evergreen and should be the source of truth for everything the product organization is planning/doing. Depending on the company, there may some sub-components, like quarterly product roadmap memos.

🙂
By focusing on this set of documents, the product team can keep their auxiliary workflows as light as possible and prevent duplicative documentation.

Relationships

image

The PRD is the source of truth and reference for all functionality that a feature has. A member of the organization can go to it so they understand what has been built, de-prioritized, or postponed for a future version.

📌
PRDs have a one to many relationship with the product roadmap because they encompass all past, present, and future scope that has and will be done.

Each product roadmap item is a transactional representation of the scope as determined by the product development process. A member of the organization can go to the product roadmap and see the status, prioritization, and relevant information to a feature they are following. As each product roadmap item is processed by the development cycle, it is released on the Product Calendar.

📌
Product roadmap items have a one to one relationship with a Product Calendar item because they reflect the transactional production of the scope determined by the PRD.

Each Product Calendar item is a distilled list of functionality, screenshots, tutorials, links to analysis, and anything a post-release support team would need to create their own documentation for sales processes, CS macros, operations SOPs, etc.

Product Requirement Documents

Each PRD should have the following properties:

  • Status: This indicates what part of the workflow the PRD is in. Each PRD needs to be peer-reviewed and approved before the product development lifecycle starts.
  • Product Manager: The individual product manager that is responsible for the PRD
  • Product Roadmap Item(s): A relational link to the product roadmap that shows which product roadmap items are associated with the PRD
A snapshot of some PRDs in the Cheetah's Notion wiki
A snapshot of some PRDs in the Cheetah's Notion wiki

Notion Templates

Standalone PRD database

If you'd like to duplicate the standalone PRD database template, this will allow you to create a database of PRDs without the link to the product roadmap.

Standalone PRD Database Template

Standalone PRD document

This document is just the template of a PRD. It has no association with a database.

Product Requirement Document Template

Full Product documentation suite

This is a link to a template that has all three components, with links to a Product Roadmap and to a Product Calendar.

Product Dashboard Template

Product Roadmap

Each Product Roadmap item should have the following properties:

  • Status: Where in the product development workflow the task is in
  • Product Manager: The product manager responsible for its release
  • Engineering Manager: The engineering manager responsible for technical development, architecture, etc.
  • Squad: The team responsible for development of the feature
  • Platform Component(s): The various components that will have an internal/external-facing change to functionality
  • PRD: A relational link back to the PRD that outlines the scope of the feature
  • Epic Link: An external link to the development tracking platform of choice. At Cheetah, we linked the JIRA epic here.
  • Design Link: An external link to the UI/UX specifications for the feature. This can be to Zeplin, Miro, Figma or whatever design platform being used by the design team.
  • Start Date: Date when the epic is planned to be kicked off or started.
  • End Date: Rollup to the date property on the Product Calendar item, or simply just the date that the feature is intended to be released.
  • Product Calendar Item: A relational link to the Product Calendar item
Cheetah's Product Roadmap
Cheetah's Product Roadmap

Notion Templates

Standalone Product Roadmap

If you'd like to duplicate the standalone Product Roadmap template, this will allow you to create a database of PRDs without the links to PRDs and Product Calendar items.

Standalone Product Roadmap Template

Full Product documentation suite

This is a link to a template that has all three components, including links to a PRD database and to a Product Calendar.

Product Dashboard Template

Product Calendar

Each Product Calendar item should have the following properties:

  • Release Date: The date the feature is first available to users. If there is a partial/slow release this should be indicated in the release notes (including A/B variation documentation if applicable)
  • Product Roadmap Item: A relational link to the Product Roadmap item that it is associated with
  • Web Version: The applicable release version for the web platform
  • iOS Version: The applicable release version for the iOS app
  • Android Version The applicable release version for the Android app
☝
Note: I include versions as properties to make it easier to search/filter. If a feature applies to all versions, just leave the version blank.
List view of the Cheetah Product Calendar – there is also a configured Calendar view that is default in the template below.
List view of the Cheetah Product Calendar – there is also a configured Calendar view that is default in the template below.
👉
Included in each product calendar item is a template for an "incident" in which we summarize the impact to the organization and develop a post mortem with action items.

Notion Templates

Standalone Product Calendar

If you'd like to duplicate the standalone Product Calendar template, this will allow you to create a database of Product Calendar items without the links to PRDs and Product Roadmap items.

Standalone Product Calendar Template

Full Product documentation suite

This is a link to a template that has all three components, including links to a PRD database and to a Product Calendar.

Product Dashboard Template

Feedback/Questions?

Shoot me a DM on twitter or email me if you have any feedback, questions, or more Notion template requests!