A Product Manager’s shortcut to go-to-market deliverables

A guide that drives early project collaboration for a successful product launch.

I heard a CPO recently point out that good Product Managers carry with them a set of tools that they’ve developed over their careers. These aren’t tools that your organization dictates that you utilize, but rather those that are leveraged in addition to them. It caused me to take inventory of my personal Product Management toolbox, and to write about one that has served me well in recent years: the End-To-End Guide.

A Go-To-Market Hack: The End-To-End Guide

One of the recent favorites in my own toolbox is the End-to-End Guide. It’s exactly what the name describes; it’s a document that describes specifically how to use a product or feature. However, this guide is written long before the product or feature exists. So how is this a PM tool exactly? The title sounds like something that would be included in the late stages of the go-to-market, and only for a product or feature that is (unfortunately) complex enough to require one. However, this is not that type of guide. This guide is an internal document that describes what you expect will need done to enable a customer to use the new product or feature. Think of it as the UI Design equivalent for your company’s internal process related to the product/feature. At first blush, you might wonder why a Product Manager would volunteer to take on this type of effort, and may not seem to even be something you see as part of your role. However, I promise you it’s well worth the effort, as it has the ability to reveal organizational collaboration gaps, uncover ongoing life-cycle management pain-points, and greatly simplify your go-to-market tasks later in the project.

Tool Application (When to use)

Particularly in larger organizations, Product Managers often have products or features being built by multiple development teams across multiple geographies. These efforts often also involve multiple product managers, not to mention all the other various functional areas involved (PMO, UI/UX, QE, Tech Docs, etc). These projects often lean heavily on the Program Management (PMO) organization to make them run smoothly. However, Product Managers have a huge amount of influence on setting the project towards an on-time, successful outcome. Using this tool, PMs can help prevent the situation where you believe the project is in the last 10% of the project phase, then slowly uncover that there is still 30–50% more time needed to get to market. This End-to-End Guide is a tool that I’ve found immensely helpful for this type of situation. Even if your particular organization haves extensive process in place to manage such projects effectively, they are unlikely to cover the depth of what this simple tool provides.

Tool in Brief and Why it Works

This early-stage End-to-End Guide is initially a free-form document that the lead Product Manager creates that describes how the product or feature is supposed to work, from the perspective of a internal educator of the product/feature. Generally, Product Managers think of their role as defining the “What” and “Why”, and let the engineers define the “How”. That holds true here as well when it comes to the ‘how it will get built’, but PMs should retain ownership of ‘how it is to be enabled and maintained’. This helps avoid the types of outcomes like car manufacturers requiring removing the bumper to change the headlamps. Ultimately, usability isn’t just a term for good user interfaces, it should encompass all aspects of getting a product or feature into the end-user’s hands once complete, including overall life-cycle management aspects.

Qualifiers for use

Keys to an effective End-to-End Guide comes with the following qualifiers:

  • Created early in Development: This document should be developed early in the project (ideally shortly after the user stories are created across the various functional areas)
  • Expected to be initially Inaccurate: The document is written based on gross assumptions that will often be incorrect — this is ok, and expected.

End-to-End Guide Outline Example

The end-to-end guide should roughly provide sections that fit the following high-level descriptors:

  • Resources: Links to wikis, design docs, wireframes, etc.
  • FAQs: A first cut at common questions that you’ve already had to answer for yourself
  • Where it will and won’t work: Supported environments, ecosystems, etc. Since this document will most likely get its first cut at the minimum viable product (MVP) phase, these things are likely already in the acceptance criteria of your user stories; aggregate them here. Also add what’s not going to be supported to minimize gaps created by assumptions across the teams.
  • Defaults: The do-nothing scenario for your customers with respect to the new product/feature.
  • How it will be enabled (Administrative aspects)
  • How it will be configured (Setup aspects)
  • How it will be established (Deployment/rollout aspects)
  • How it will be maintained (Life-cycle management aspects)
  • How the impact will be understood (Analytics and measurement considerations)

The Process

  • Free-writing
  • External Facing Technical Documentation
  • Internal and External Training Resources
  • Technical and Customer Success Product Support Reference Material
  • Product Marketing Data Sheets
  • Community Forum Content

Additional Thoughts and Caveats

As is often the case for Product Managers, this tool’s success requires that those you’ve tasked with creating the accurate information. So it’s success requires that you have honed another skill that is fundamentally critical for any successful product manager; getting help from key contributors to the project without having direct authority over them. So you may need to sell them that it’s also in their best interest to assist, as it will likely reduce their workload later in the project, as well as help limit finding gaps late in the project.

Creator of Products and Art