Great documentation is a sign of great communication. Here's what you'll need to say and why.
In an ideal world, product managers would be the 'CEO of the product' and could be expected to delegate some of the 'admin-type' stuff when it comes to documentation. However, for most companies, product managers sometimes do product owner stuff and even others, project management duties.
This means that as P.M you could be expected to write development tickets on a platform like JIRA, or maintain the document repository. You will be required to also keep track of the design outputs from the UI/UX team.
This could feel like a lot of work if you're joining a new team, or in your first official PM role. However, I'm here to tell you to panic not, no rocket science here. The key is to always make sure your documents are up-to date, properly labelled and stored in a hub that's accessible to whoever it needs to be accessible to.
You can read more about navigating documentation as a new PM here.
Right now, I'd like us to delve deep into some of the specific types of documents you could be expected to either create from scratch, or update as a Product Manager. Let's jump in.
#1 - Product Roadmap
A product roadmap helps you communicate to your stakeholders what to anticipate from the upcoming development cycles. More than a strategy tool, it is a communication medium. The level of detail that goes into the roadmap will depend on your org, the maturity of your product and who is going to be looking at the roadmap. Most orgs have public-facing roadmaps for their users and investors to look at and maintain confidence in their forward-thinking-ness; and then have an internal roadmap that could contain some of the strategic moves the org is thinking of pursuing. As PM, its not on you to sit in a corner solo and come up with wish-lists and then slap some dates on them. Developing a responsive, efficient roadmap usually involves a number of stakeholder meetings across sales, customer success, management, dev team, etc,. You would then collect the data, map out a quarter or two ahead, usually not that further out. Based on the data, level of urgency and competitive or business environment, you would creating a first draft roadmap and share it with the rest of the team.
This is what a sample roadmap looks like:
#2 - Product Requirement Documents (PRDs)
A Product Requirement Doc, sometimes simply known as 'requirements doc' or 'PRD' is often a one-pager that PMs use to communicate to relevant stakeholders what feature is to be built, the business value-add it's expected to add, success metrics and how it's meant to benefit the user. Requirements don't have technical jargon nor the specifics of the 'how' it will be built by the engineers. Requirements essentially detail the 'what and why' of a specific feature and functionality. The technical 'how's are to be added to development tickets by the dev team/product owner/engineering manager.
Most times, it will include related functionality that is presently out of scope but that could be considered at a later time. If the UI/UX designs that are associated with that feature are ready and available, they are also added onto the requirements doc.
By the time a stakeholder is reading a requirements doc, they should have a detailed perspective of what is to be built, why it is being built, and whom it is being built for.
Here's a sample Product Requirements Document Template from Atlassian (Confluence)
 |
 |
 |
#3 - Product Backlog
Product Backlog is a digital bucket where you will put all the product features you'd like to consider building now, next or later. You fill it up consistently during every meeting someone in management mentions a new feature, someone in customer success mentions something users want, or someone in marketing mentions a feature or product that will make your company or offering competitive.
A lot of things will go into this bucket; most of which you will not build. Why? The competitive landscape could have changed, your org's strategy could get updated, a problem users are facing could have been solved by something else, etc. That is why, after you've put all those random (or intentional) feature requests there, you will conduct multiple consistent backlog grooming sessions to keep it DEEPly clean before they are added to a sprint backlog. DEEP = Detailed appropriately, Estimated, Emergent, and Prioritized. You can read more about backlog grooming here. So, what does a product backlog look like? Anything you want it to look like. You can use a Gantt chart, Asana, JIRA, Trello, etc. All you need to do is add just enough detail that can help you scope out the feature later when it's time to consider building it. Here's what that can look like:
I personally enjoy using the JIRA Kanban board as a product backlog as it works seamlessly when it comes to adding scoped features into a sprint.
Here's what a Kanban board for your backlog could look like:
#4 -Release Notes
Think of release notes like a news bulletin whenever you release a new feature, or update an existing one. You use it to tell your users what's new or what issues/bugs that were previously existing have now been solved. You've got to write it in a language your users understand, so keep the technical jargon to a minimum.
Depending on your type of product, these public release notes are usually distributed on on channels such as: the company’s website, blog, in-app notifications, email, application stores, and social media.
Some apps tend to force release notes down users' throats by making them have to scroll through all the updates of what's new, in a way that is disruptive to the user experience. Don't do this. Add simple coach marks to relevant pages within the app and give users the option to take a tour or nope out so they can keep doing what they came to do.
Here's a different type of release notes that has more detail regarding what has been built, updated or changed.
#5 - Product Strategy
Product strategy is the plan that the company, usually the management/executives outlines regarding what they hope to achieve with their product and the steps they will take to get there. A senior PM is often the one responsible for the product-focused strategic plan that details how you plan to address the needs of your users and how that plan serves the overarching company goals.
Product Strategy doc(s) can be one document, multiple documents in different chapters of the same strategy book or different documents within one folder. Your product strategy will look different depending on the size and stage of your business, the maturity of your product, the nature of your market, and the seniority of the person crafting it.
Product Strategy documentation often includes:
Vision and Mission Statement: Why does your product exist and what change or influence is it hoping to make?
Target Market: Whom are you building it for?
OKRs, KPIs and Metrics: How will you be measuring growth and success?
Competitive Analysis: Who are you competing against and how do you compare?
Go-to-Market strategy: How will your product be introduced into the market?
#6 - Document Repository
This is not a document, but the digital library where all the above documents are stored. A good library tool allows different people different levels of access depending on their role, can be updated real-time, allows for documents to be exported and shared in various file formats and is hopefully, tidy and neat to look at.
Product Document repositories are often hosted in tools that you may have heard of such as Confluence, Google Workspace, Notion and Click-Up. The right tool for you to use will depend on the size of your team, the budget you have and the key functionalities you desire.
Again, here's where you can read more about creating documentation as a new PM.
Consistency does it when it comes to documentation
As a product manager, a big chunk of your role will be in ensuring that the documents in the repository are properly labelled, easily accessible and consistently upto date (or archived). You want to also establish a single source of truth that anyone reading from it knows that whatever they're reading is the latest true version of the document.
Remember, great documentation is a sign of excellent communication skills. The core main skill all Product Managers are required to have.
If you'd like to learn more about thriving and succeeding as a PM, I've created a cheat sheet that will show you the mindset that got me nominated as the Employee of the Month, 4 months into my new role. You can find it here.