top of page
  • Writer's pictureDan G

User Facing Product Documentation for Enterprise PM's

Updated: Sep 16, 2022

This guide is specific to PM's that work on enterprise (i.e. B2B) products.

Problem Statement

When working on my first major enterprise product that we had built and launched from scratch, I found myself spending a considerable amount of time fielding documentation requests.

As new and existing client interest grew, I was continuously receiving requests from my sales, implementation, and account management partners to create a seemingly endless pile of slightly modified versions of an existing product one pager or slides for a client meeting.

Everyone wanted to bring the "perfect" set of materials to their client, but given how new the product was, no one felt comfortable making these documentation edits on their own. In addition (and as is often the case with new product launches) the full apparatus of product support had not been funded yet (no Product Marketing, Technical Writers, etc.).

This led all roads back to the PM team to make sure the most accurate and up to date product info was being shared across our client community.

The Solution

Realizing that I would never be able to focus on moving our product forward by spending so much time on documentation, I tried to identify why it was that the basic product documentation I had created at the outset of our launch was always never quite good enough.

What I learned was that generic product documentation is woefully ineffective in a B2B setting, given the diverse array of stakeholders and constituents that will be involved in the products delivery to the end user.

To combat this, we shifted our mindset to aligning our product documentation to the lifecycle of a product through an enterprise, and took the time to understand the unique questions being asked by each of the key client personas involved in the process, and then built fit for purpose documentation to address those specific questions.

How To Implement

While the up front investment of time to get this library up and running is considerable, you will return 10x on your investment through the time you save yourself and the team down the stretch through having a single repository you can point stakeholders to that covers every possible documentation use case and requirement.

When it comes to getting started with your revamped product documentation library, the most important consideration is to understand the key questions that will be asked by each Client Persona.

The Buyer Persona

  • Who

  • Typically from the C-Suite of an enterprise. COO, CEO, CIO, etc.

  • Questions They'll Have

  • What is buying this product going to do for my organization?

  • Ex: Increase efficiency by X%, grow revenue by Y%

  • What will it cost me?

  • In both dollars and organizational costs to adopt

  • How can I trust that you will deliver?

  • Demo's and case studies

  • How do I know you will be around for long enough to make it worth my while

  • Highlight of key upcoming features on the roadmap to demonstrate continued investment in the product

  • Organizational Partner

  • Pre-Sales and Marketing

  • Why the PM Should Get Involved Here

  • An argument can be made that Sales should cover the creation of these materials, and the PM shouldn't be involved. In my experience this can lead to seriously misaligned sales pitches (especially on a new product) that leave clients frustrated when the product they get is not necessarily in line with what they were sold.

  • My recommendation here is to publish a core set of vetted slides that answer all of the key questions the Buyer Persona will ask. The Sales team can then have the discretion to add new slides or make tweaks to your content as they see fit.

  • By publishing a vetted set of materials, if (and when) situations arise where Sales "over-sells" the product, you will be able to fall back to your published documentation library and challenge why and/or where they chose to misrepresent the stated goals of the product.

The Project Manager / Administrator Persona

  • Who

  • Typically from the Program Management office or the "Head of..." a particular team

  • Questions They'll Have

  • What will it take to implement the product?

  • Initial resourcing requirements, timeline estimates, project plan

  • What does the product actually do?

  • End to end demo covering all of the major user journeys supported by the product

  • What will it take to support the product on an ongoing basis?

  • What ongoing account administration, maintenance, and / or upgrades will be required?

  • How do we communicate product feedback?

  • Pathways for sharing product enhancement requests, bugs, and related feedback

  • Organizational Partner

  • Professional Services, Customer Success

  • Why the PM Should Get Involved Here

  • What a product can do and what it actually does for a client ultimately comes down to how it is implemented. Nothing will key your CSAT or post launch adoption metrics faster than a poorly implemented product.

  • My recommendation here is to publish a core set of slides that speak to the key questions asked of the Project Manager persona that the Professional Services / Customer Success team can and should draw from when leading engagements with new customers.

  • While you can't control how the actual implementation goes, you can (and should) use this as an opportunity to set clear expectations with your newest customer up front on what it will take to get up and running on your product.

The End User Persona

  • Who

  • Anyone that uses the product on a regular basis

  • Examples include a field sales rep, operations analyst, software engineer, etc. depending on the nature of the product

  • Questions They'll Have

  • Why should I use this product?

  • Just because an organization decided to purchase your product, it does not necessarily mean everyone at the company is excited to begin using it. Legacy processes that may have been around for years and designed by the very people being asked to adopt your product will need to be deprecated.

  • This means you need to really lean into how this product will make the users life better through detailed tutorials that highlight how they will save time / work more efficiently / etc.

  • How can I use this product?

  • Your product should be designed intuitively enough so that a step by step guide is not required to get started, but that still doesn't mean you shouldn't have one handy.

  • As an enterprise employee, the worst feeling you can experience is helplessness -- that feeling you get when something is standing in between you and your ability to effectively do your job. When that "thing" in their way is your product, expect some seriously negative feedback.

  • Users should know they always have a resource to turn to that can unblock them when they get stuck.

  • How are other people using this product?

  • Keep an FAQ guide handy that sources all of the top questions received from across the user community

  • What's going to help me do my job better going forward?

  • Release notes need to be shared in a way that will help users stay engaged and see a reason to keep using the product going forward

  • Organizational Partner

  • Account Management, Customer Success

  • Why the PM Should Get Involved Here

  • The end user is where the rubber hits the road. If you want to keep product churn low, it is essential that your end users have an ecosystem of product resources to call on whenever they have a question or get stuck in a workflow.

  • My recommendation here is to published the key user tutorials, FAQ guide, and release notes both internally and externally via links to these support materials directly from your product.

Wrap Up

There is no debate that when executed effectively, a product documentation library that is tailored to the requirements of each persona involved in the products journey through an organization will save you time while ultimately increasing the success of your product.

Where there is some debate is with who should write and maintain this library. Different organizations will employ different tactics to create these documents (technical writers, product marketing, sales, digital marketing, product owners, etc.).

If you have folks that are available to write these materials on your behalf, let them do it, but always keep the most up to date and vetted materials in a centralized location within your company's intranet.

If you don't have team members to do it, there is no choice. You as a PM have to create these materials yourself!

34 views0 comments

Recent Posts

See All
bottom of page