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.
I learned the importance of developing your own professional toolbox early in my career. While in engineering school, I did an internship for an A&E (Architectural and Engineering) firm that designed semiconductor fabrication plants. In observing some of the grizzled, very senior engineers work, I was wowed by the accuracy of their rule-of-thumb calculations. They could do things like determine the size and number of air handlers that would be needed with only the square footage of the cleanrooms that they’d be servicing. They could be <90% accurate with a 2 minute calculation. Alternatively, applying methods I had learned in engineering school to do the same calculation, I required hundreds of ‘knowns’ that would take me weeks to identify (along with needing to make many assumptions to get them), and I’d arrive at a answer that would be lucky to be 50% accurate. The value of these engineering pros to the organization went well beyond the experience they brought; these engineers were both smarter and faster than their much younger counterparts because of the breadth of efficient tools they had at their disposal.
For a product manager, many of our tools are not nicely packaged rules-of-thumb equations. Additionally, like any good tools, they should (and need to be) modified to fit the specific dynamics of your product and organization. But they can add the same type of value to what you bring to the table.
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.
There are two fundamental reasons that I’ve found the End-to-End Guide tool to be effective. The first reason is due to Ward Cunningham’s Law (the father of the wiki): “the best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.” In this case, the product managers don’t intentionally write the wrong answers in this guide, they simply provide their best (often naive) guess at how the various aspects of the new product/feature will be enabled for any given customer once it’s available. After doing their best, the Product Manager then gives ownership to those responsible for building specific aspects of the product/feature to correct any misinformation in this End-to-End Guide. This provides the second reason why this tool is effective; Editing is generally much easier than writing. This is especially true when the editor is also the subject matter expert on the information.
Qualifiers for use
Keys to an effective End-to-End Guide comes with the following qualifiers:
- Internal Target Audience: The intended audience of this document is internal only, but broad. Information will be very relevant from UI/UX, QA, Dev, Training, Docs, Technical Support, etc. However, since the audience is internal, any and all internal reference material is fair game as contributing information.
- 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:
- Introduction (purpose statements typically copied over from project documentation such as Epic summaries, PRD, etc.
- 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 document is ideally written by a Product Manager who has the highest vested interest in the product or feature having a successful outcome. This person will hopefully also have the broadest understanding of how it all needs to work at the end of the day. However, if you want to divvy up sections with other product managers to cover, that can work as well. However, I do not recommend recruiting writers outside of the Product area for building the document initially.
Actually writing the document should be a 0.5–2 man-day effort, depending on how comfortable you are with free-writing this type of content. Don’t get hung up doing research beyond getting some basic technical foundations where necessary; simply write how it should work that makes sense to you. For example:
Before a customer account can be enabled with this feature, they must have a ‘premium’ tier account subscription, and specifically request the feature added either through the marketing blast opt-in, their CSM, or via Technical Support. These will either manually or automatically trigger a database flag of ‘feature_x_enabled’.
All of the above are details of the project that are likely nowhere close to being finalized when this content is written. The flag name may be the wrong name, it may not even be stored in a database, it may not even use a flag, etc. However, any developer reading this sections knows what you are trying to explain, and can easily convert it to being technically accurate. Additionally, it quickly identifies to customer-facing entities of need-to-know information about parameters and controls they have related to the feature. And if the team responsible for developing the feature hadn’t even planned on the feature having enable/disable capability, you’ve uncovered a story gap for them.
- Assigning Editors
Once you have the various sections of the End-to-End Guide drafted the best you can, go through and highlight sections with comments and assign them to the person you see as best fit to correct the information you have written for each area. This will often be the technical lead for that aspect of the project; another product owner is another good option. Ultimately, they may re-assign it to the best person to answer. Additionally, the assigned person may not be able to fully correct the document at this stage, but it plants the question for them as needing answered during the build-out.
- Measuring Effectiveness
For this tool to be effective, it’s critical that it actually is reviewed and edited by those assigned to do so. Therefore, the comment assignment serves as the indicators of the content’s review status. These may need bumped late in the project to ensure review when final knowledge is known by the subject matter expert. Additionally, anybody with access to the document needs to understand the state of the content; unreviewed/unedited sections need to be understood that the information is likely inaccurate. You may use some key to indicate this (e.g. red font text). Additionally, they may add whole sections that they deem necessary due to their unique insights to the project.
Both PMs and PMOs can now leverage the document as one way to measure the go-to-market readiness and gaps of the product/feature. That is, if a particular aspect can’t be described by the subject matter expert on how it’s supposed to work, this then serves as a major red flag that the project isn’t where it should be (i.e. stories are likely missing or not yet prioritized). Additionally, if the development team (doing internal demonstrations) or QE (doing end-to-end feature testing in a staged environment) cannot leverage the document to fill in any knowledge gaps they have to make it work, things aren’t ready.
Once the content has been edited (or completely rewritten in some cases), you now have accurate information that can be disseminated across all teams needing to know this information. It becomes extremely useful to groups like QE, Sales Engineering, Documentation, Technical Support, Customer Success, Training and Onboarding, as they now have early, direct access to comprehensive information on the functional go-to-market aspects of a new product or feature — all written by the people identified as knowing the most on that particular aspect. They can then add their own questions and comments to the doc to flesh out anything needing further clarity.
- Outputs towards Deliverables
Once this End-To-End Guide document is fully edited, the document itself serves as a project archive, deserving a place such as your corporate wiki. It can also now be leveraged to populate content that will be required as part of getting the product/feature to market as well — with everybody working with the same baseline. These include documents such as:
- End-user facing guides, wizards, in-product informational pop-ups, etc
- External Facing Technical Documentation
- Internal and External Training Resources
- Technical and Customer Success Product Support Reference Material
- Product Marketing Data Sheets
- Community Forum Content
In essence, you’ve just short-circuited getting high-quality information to the various resource types that can now leverage their functional expertise to complete their specific go-to-market activities that you need for a successful launch.
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.
And of course, it’s critical that the content you drafted originally does not get carried forward as accurate without review and edit by your subject matter experts, as that will certainly create headaches. You can use various techniques to ensure this, such as copying the doc used for broader distribution that has only edited sections copied over.
I hope I’ve inspired fellow Product folks to take inventory of their own personal PM toolboxes, and that the End-to-End Guide in one you will consider adding (and adapting) to your own toolbox.
- Steve Paddon