The Documents Product Managers Spend the Most Time On

We recently analyzed 51 product manager job postings and found that the number one thing Product Managers own is documentation. I wanted to understand more about Product documents, so last week I emailed thousands of Product Managers and asked: “What are the product documents you create and who do you share them with?”

We learned that there are a LOT of different product documents being created:

There were plenty of other types of documents too, including Go-to-Market plans, backlogs, problem statements, project planning, decision-making docs, customer interviews, postmortems, and meeting notes.

Overall, I was surprised at the inconsistency of document types. There isn’t one consistent set of documents that everyone is making. Based on this analysis, being a PM is still a bit like the Wild West. A lot of us are making it up as we go along, and creating customized solutions to meet the needs of each of our teams.

Specs

Specs were the most common type of documentation, mentioned in 39% of the responses. That’s not surprising since everything that gets built by engineering needs to have a set scope of requirements and a detailed explanation of functionality.

What PMs include in their specs varies by team. Sometimes they include release dates and success metrics, other times the spec is simply a description of features to share with engineering. Regardless of the format, specs consist of writing out the details of ‘what’ to build.

Most specs were created for engineering, some for design, and a few folks co-created these specs alongside engineering.

Product strategy & vision

Whereas specs outline ‘what’ to build, product vision documents address the ‘why’ behind decisions and the business case for planned work.

These documents are primarily shared with stakeholders for feedback and to help drive alignment so that a product team feels confident everyone is moving in the right direction.

Internal guides & FAQs

Internal guides are all about documenting how things work.

This type of documentation serves two functions:

1. It ensures that information is recorded for easy hand-off between team members.
2. It acts as a reference for external-facing roles to support customers (such as Sales, Customer Support, and Marketing).

Customer-facing guides

These include FAQs and training to help customers fully understand how to use a product.

I was quite surprised to learn that so many PMs are writing publicly facing content, but it makes sense. Product Managers are the designated experts of the product and are expected to know the ins and outs of every detail.

Who else would be better at describing what’s been built?

Product Requirements Documents (PRDs)

The PRDs mentioned were used as an all-encompassing resource to have everything about a feature or product for everyone in one place.

These documents outline research, problem statements, success metrics, and much more. Here’s how one respondent described them:

“PRD – describes the problem we are solving, the goal, Target users/customers, Use Cases, Success criteria, MVP feature list, Designs, Implementation. I try to maintain one single running Google doc from describing the feature/product which will have product details as well as engineering implementation details.”

Roadmaps

We expected to see roadmaps as one of the most commonly created documents, but only 27% of respondents mentioned them. Based on our analysis of PM roles, roadmaps were the top documentation artifact companies expect a PM to own.

What was most surprising about the responses, however, was the range of formats people use to build roadmaps. Roadmaps are created as Word docs, decks, and even on whiteboards. No two roadmaps are exactly alike, as teams will adjust their roadmap to fit their company’s unique needs.

Why documentation is so important

A few people who responded shared why Product documents are considered so important. We saw two trends in the responses. The first, that documents record key decisions made and help retain product knowledge.

“Documenting how things should work on a wiki is critical for knowledge retainment and transfer between team members.”

“Memorializing Product Decisions – when you’re working on something for a couple of years, no matter how much you love the product, you forget how certain things work OR how certain things should work OR why you made things work a certain way. It’s all buried in tickets closed off long ago (or in an old Product Management tool you migrated off a few months ago). Team turnover can also be an issue.”

The second reason documentation is helpful, is that it creates a process for collaborating and sourcing feedback from team members in a structured format.

“What I primarily love about these tools is that they are collaborative in nature so no one feels forced to ‘complete’ things in order for them to be valuable and shareworthy.”

“I’ve found this one approach allows all team members to buy into a singular product plan and can pitch in respective to the priorities of that project.”

“It ensures all parts of the business come together… It encourages collaboration, accountability and a real sense of buy-in from the organization.”

A tip to make documentation work

A few people also shared some suggestions for what makes documentation work well.

There are tons of tools and styles for documenting Product information, and all of them can work.

What’s important is getting your team to stick to one process in order to keep information consistent and organized, and to keep the information up to date.

“I’ve since implemented a central online home for everything and started to own the process, making sure everyone sticks to the agreed format.”

“The key with documentation is committing to it and pointing people to it to find their answers. If it’s not accurate or up to date it is worthless.”

PMs aren’t just expected to talk to customers. They’re expected to document everything they learn from customers. And then translate those learnings into even more documents that get team alignment and help features and products get built. Without documents, PMs couldn’t do their jobs. It’s an added responsibility that can make an already challenging position feel even more challenging.

Do you make and share a lot of documents? Find your documents in 3 clicks or less with FYI.