Product Documentation – A Product Manager’s Take

Few companies treat their product documentation as a product itself, while for others it is just documentation which is an essential checkbox to be ticked for their product to ship. This approach towards documentation may create a big difference between the perceived vs the delivered value of the product. I believe good product documentation alone may never be enough to make the product successful but a bad one can surely contribute a lot to its failure.

While we understand the importance of documentation, in this blog I will give the product management perspective of it and how a product manager is the key stakeholder of product documentation.

Responsibility vs Ownership

While an established organization will normally have a tech writer who will be responsible for documenting the product, not just the tech writer the entire team is responsible for the documentation, while it is the product manager who should own the documentation for the product. This is to ensure that the content and quality of the product documentation deliver value to the customer and enriches the product usage experience for the end user. The below stakeholder contribution chart will give a clear picture of each of the stakeholder’s contributions:

Good documentation that delivers the right value and experience for the end user requires the engineering team, documentation team, user experience team, and product management to come together.

• While the engineering team is the one to provide the technical content which forms the base of the documentation, it must work with the documentation team but it is the product manager who should be owning the responsibility to ensure the right content is delivered at the end. He can do this by facilitating the discussion between the engineering and the documentation team, setting the expectation around the product/feature documentation content, and reviewing the content along with both the engineering and the doc teams.
• The engineering must work with the user experience team to make sure the right understanding of the workflow and designed experience gets captured in the documentation and to ensure the user experience team is on board with the technical content they are sharing with the documentation team. Here the product manager must act both as a facilitator of the collaboration between the two teams and as the owner of the right understanding of the flow and experience of the getting delivered as part of the technical content shared by the engineering.
• The product manager should also ensure that documentation and the user experience team of the product collaborate, and he/she ensures that the end documentation delivered by the doc team is in line with the workflow envisioned by the design team.

In the end, the Product Manager should own the value that gets delivered by the product documentation as he/she would own it for the product/feature.

Product Documentation is delivered – Now what next?

Whether it is the product, or its documentation will always have scope for improvement around the content, the type of content, the personas addressed, the experience the flow, etc. So, it is very important to get some early feedback on the documentation either from the early adopters/beta customers, your presales/sales, or the support team. This will go a long way in improving product adoption and usage.

Along with this having metrics to measure how the documentation is perceived by the end users/customers will help in deciding and prioritizing the future course of action, either for course correction or for any improvement. Without being able to quantify and measure something, it becomes difficult to understand and prioritize its improvement. I believe the two key metrics we can track to quantify the product documentation quality are:

• Metric 1 – Number of support cases per month about documentation.
• Metric 2 – Number of support cases per month that had a resolution by pointing to the right section/part of the documentation.
• Metric 3 – Number of support cases per month that had steps/procedure which was not documented.

• Metric 1 – This will help you understand the overall quality of the documentation and the areas for improvement. And the rising number of such support cases indicates that as a product manager you will have to improve upon collaboration and process to get the right content.
• Metric 2 – This helps to understand the magnitude of the problem with the documentation flow, its discovery, navigation, and personas covered. A rising number of such support cases indicates that as a product manager you need to work more on the area of ownership to ensure the right flow.
• Metric 3 – Rising number of such support cases, helps us to understand that the user experience, the engineering, and the product manager need to work better together to ensure that there is the right understanding in place and that all the three stakeholders here are in sync.

What is the ROI?

The question is, spending so much time and effort around documentation is it worth it. The straight one-word answer to the question is yes. But we product managers are not happy with just that. We should know what’s the ROI and how to measure it. So below are the key benefits and the metrics to measure the impact:

1. The end-user experience is improved – Metric to look out for is, a better net promoter score.
2. Reduced support cost and effort – Reduced support cases due to documentation issues.
3. Reduced dependency of pre-sales/sales on engineering and product teams for demos, customer sessions/training – Reduced average sales cycle time.

To conclude, taking care of the documentation and getting it right is essential and often low-hanging fruit for product managers to ensure the success of the product.

Cheers!