A ‘don’t panic, you’ve got this’ strategy for new Product Managers
My first official PM gig came after a 5-year stint running an EdTech startup that ran out of funds. While I was the de-facto Product Lead and was a master generalist, one of the key tasks that I had never gotten around to actively engaging myself with was creating product documentation on Confluence (or whatever other tools) and linking it to Jira.
So, I am writing this for the version of myself who felt overwhelmed by all the new terms and tools, who had to learn fast and created the most beautiful repository of ‘main source of truth’ for the product we were building.
So, this article is meant for the PM who’s been tasked with creating and/or managing documentation, with or without the help of a Product Owner.
It all begins with the Product Owner’s mindset.
1. Are you creating a product documentation repository from scratch or are you working with an existing documentation repository?
More likely than not, when you take on your new role, unless it’s a brand new startup, there’s documentation somewhere. It’s likely spread between obscurely-named spreadsheets and google docs, some rough notes in a book, and some lo-fi/hi-fi designs on Figma. If you’re lucky, your predecessor did a great job of organizing the information in a useful, easy-to-follow way and you can use that as ‘inspiration’ to prepare yours; no need to reinvent a perfect wheel.
Most of us are not that lucky. We’ll inherit a mountain akin to a pseudo-abandoned, dusty library that hides a lot of useful books.
Here’s how you’ll build a Product Documentation Monument out of a documentation ruin:
Great documentation is a sign of organization, competence, and good taste.
a. Collect all the documentation that’s been shared with you and go through it one by one. This may sound boring, but it will help you in two main ways: you get to understand where your product came from and what it’s transitioning into. You also get to see the vision your company is looking to achieve and how you should be thinking about the place of your product in achieving that vision. A PM needs to be as close to a human manifestation of a ‘source of truth’ as possible.
b. If the documents are not properly labeled in a way that’s easy to identify and follow, create your own naming convention and save them in a private folder for now. If your company is a stickler for ‘this is how we’ve done naming before’ and it’s not (yet) understandable for you, duplicate the docs and save them with your preferred names in your own folder.
c. Determine which documents are ‘outdated’ which ones you’re not too certain are relevant and which ones are obviously recent and up to date. One way to establish this is to check the last date it was edited/published. Another way is to check how relevant the content is to what you know is currently being built. You can then save them in three different folders. If they’re all in a Confluence or Notion Space or different spaces, you can create your own single space, add pages and subpages and separate them that way. You will confirm later with your manager whether your categorization is accurate.
d. Meet with different stakeholders within your company and outside of it. Prepare any list of questions you had after reading through the documents. Clarify things like context, competitive landscape, and current sprint and roadmap. Take copious amounts of notes; you’ll need these when creating or updating the documentation you already have. This step is important even if you were an internal transfer or hire; this time, you’ll be thinking like the world-class PM you’re becoming.
2. Who are you targeting with your product documentation?
How you’ll write for investors and partners will be different from how you’ll write for developers or end users. A great PM knows their audience. For instance, main pages can contain a summary with links to pages that have more granular information. Dev tracking tools like Jira tend to go even deeper and more technical. Depending on whether or not you’re a technical PM, you’ll be focusing on ensuring your devs understand ‘what’ to build, and the techies will take care of breaking down the ‘how’. Regardless of who you’re writing to, a rule of thumb is this: write to express NOT to impress. Fancy language is good for the ego but bad for building understanding. Make your writing simple, crisp and targeted.
Filter out the language and granularity of your writing against two main factors:
a. Who is most likely to read it (influenced by where you’ll share it or store it) b. What key message you’d like to pass (influenced by what the specific product documentation it is)
For instance, a general roadmap meant to be shared with management will be high-level and highlight key milestone markers, while acceptance criteria to be shared with devs will have granular details on what the expected dev outcomes will be.
3. Do you have an internal source of truth for your product documentation?
A Source of Truth is a digital location that contains the most updated, most relevant information regarding a project. It’s the one place anyone can go and be confident that what's there is an accurate representation of what is current.
Most companies will have a place where a majority of their documentation lives. This could be a shared Google drive, DropBox, Notion or Confluence. For most organizations, you’ll trace even more documents distributed in other spaces like Slack, Asana, Miro, etc.
Your main first task as a potential world-class PM is ensuring that there’s reliable, updated information in a reliable location where anyone interested can find what they’re looking for, clearly labeled.
If there already is a ‘Source of Truth’, use your advantage as a new PM to test how easy to navigate and search for info is. If YOU find it hard or confusing to trace what you need or understand what a specific document is, it’s likely even more challenging for someone with less technical chops to do the same. Notice this and make improvement plans.
Find a way to have all documents feed into the Source of Truth through links, screenshots, and embeds. Everyone should know that if they find something in the Source of Truth, then it is the most updated, most relevant piece of information on that specific subject.
If there is none, work with your team to find out what is the most friction-free location that will suit the team’s needs regarding a document or information repository and get to work creating the most useful wiki that could ever be created by man.
Great documentation is a manifestation of incredible communication skills. A great PM treats whatever they’re in charge of as a product; this includes the documentation repository. Incremental improvements, over perfection is the goal here.
Great documentation is a manifestation of incredible communication skills.
Next, we’ll talk about how to create and populate info in one of the most popular documentation software: Confluence.
So, what are some of the things you wish you knew when handling documentation as a first-time PM?