10 tips for writing good product handover documentation

April 13, 2023

9 min read

Share on

Abigail Lloyd

Abigail Lloyd has worked in product development for over a decade, supporting a range of organisations in highly regulated sectors to conceptualise and deliver products and services that solve complex problems. Abigail is a keen advocate for women in tech and passionate about building products that have a positive impact on the world.

Good handover documentation starts with good product documentation

Without intending to sound like I’m stating the obvious, this is important. Rule number one is you’re going to struggle to deliver a valuable handover if you don’t already have robust, well ordered product documentation.

I’m going to assume that you already have a catalogue of product documents, however before you start your handover take some time to review them and order them in a sensible structure. As an example, start with an overview, product strategy, technical documentation, screenshots and videos (you cannot underestimate how useful it is to have these when you need to build presentation slides), presentation decks, designs, discovery and observations, metrics, and guides and playbooks. There are a myriad of tools and apps available to manage things like discovery notes and metrics, but having a document explaining the context and linking to the relevant place is helpful.

Once you’re existing house is in order, you can start to create your handover document, which will act as a cover sheet for more granular detail.

Start with the basics

When it comes to the handover document itself start with an assumption that the reader knows nothing whatsoever about the product. Provide a clear and concise overview about what the product/domain does and why. I have found it helpful to try and answer the following questions as a starting point:

What problem does the product solve?
Who does it solve the problem for?
How does it solve the problem?
What are the most important/common actions the user needs to perform and why?
What are the known limitations?
What are the key performance indicators and how do we know if we’re being successful?
How does this product/domain contribute to the overall strategic goals of the business?

TL; DL – Provide ‘the short’ and ‘the long’ update

The devil is in the detail when it comes to good product management, however there is a time and a place for ‘the long’ as well as ‘the short’. Borrowing from internet parlance, I often create a TL; DR (Too long; Didn’t read) introduction to product documents and handovers to enable the reader to get a quick overview and summary prior to delving into the detail. This helps get people up to speed with a product/domain quickly and provides easily digestible, contextual understanding.

This approach is also useful when you consider the different audiences for your product handover notes; a Head of Product will want the highlights, while a PM will likely be more interested in the detail. Save yourself a lot of time and effort and create a one-size-fits-all handover that people can consume as they see fit.

Get creative with format

Just as I’d encourage you to consider different audiences when it comes to content, I’d do the same with format. While some people would prefer to read a summary, others will digest the information much more effectively if they can view a diagram or watch a recording/GIF.

Regardless of preference, visual aids are often a valuable tool for explaining complex problems and providing the reader with something tangible. Some of my favourite platforms for creating visuals are Miro and Excalidraw; I’m also a fan of using screen recording software to create short videos – there are plenty of tools available to help you.

Transfer knowledge about discovery findings and opportunities

When creating handover documentation, it’s easy to focus on what’s been delivered but don’t forget to transfer knowledge about any discovery that’s been conducted and a summary of potential opportunities no matter how formed they are. A great starting point to share this information is via an opportunity solution tree. If you’re unfamiliar with how to create an opportunity solution tree, I would advise reading anything by Teresa Torres around the subject.

For more mature opportunities be sure to pull out additional information including why this is something you believe is worth pursuing, what problem this is likely to solve, the rationale for prioritising it over other opportunities, whether this is an iterative improvement or new feature, the user cohorts it’s aimed at, and how you’d measure success. Make sure you share links to your research and discovery such as workshops, user interviews, desk research and more, and include any design work such as wireframes.

While it’s important to ensure all the discovery and research is accessible, I’m sure I’m not alone when I say I’ve received thousands of links in place of a ‘handover’ which is incredibly hard to navigate. Providing context to each link (including time stamps for valuable parts in recordings or annotations in decks) will ensure your handover is valuable and the incoming product manager will review the detail rather than discard it.

Capture known incidents, defects, and things to watch out for

Just as it’s important to share opportunities I would also encourage you to share information about known incidents, defects, or interim solutions that may be problematic in the short term and need resolving in the future.

Product managers are often required to make trade off decisions to get features over the line and this can result in tech debt or known issues. Make sure you share things to keep an eye on as part of your handover documentation.

It’s not just what you know, but who you know

There is nothing worse than owning a product without knowing who you need to speak to about what, and when. As part of you handover documentation outline your stakeholders including a summary about their interest in the product. Consider sharing the following as part of your overview:

Are they internal or external stakeholders?
Do you have any regular meetings with them that should be continued?
Do they have a particular area of interest?
Where do they sit within the business matrix?
What department do they work in and who do they report to?
Are they a decision maker?

Focus on current and future product updates

One of the greatest challenges with creating any type of product documentation is knowing when to discard out of date information. There is a temptation to keep a running record of every iteration of the product however this makes documentation long, unwieldy, and impossible to understand.

My advice is to ensure all documentation, including handover documentation is current and future facing. Rather than keep endless time stamped updates, simply update the overview when changes are implemented and maintain a decision log so you have a record of why those changes were made. When you need to look back you can refer to more time sensitive documents such as business plans, strategy documents, sprint reviews and other presentation decks.

Include technical input

Just as feature development requires collaboration between product and engineering, so does good handover documentation. Be sure to include technical teams in the creation of handover documentation and link to repositories such as GitHub to share access to code. If you rely on other teams/organisations for access to APIs and other applications, be sure to share information about that too. The incoming PM will thank you and appreciate having access to technical documentation; even if it means they are quickly able to pass it on to necessary interested parties in the future.

You may also find it useful to ask engineers to provide you with t-shirt estimates for upcoming work, giving the incoming PM a high level view of the size of opportunities which will enable them to make better road mapping decisions from day one.

Don’t forget ways of working that work for your team

Last but by no means least, provide a breakdown of team meetings and ceremonies, including a summary of what is discussed, the preferred format, rotas, and access to previous meeting notes and presentations.

Do you work in sprints or take a Kanban approach? Do you prefer to run retrospectives in person? Do you assign epic leads or take a more collaborative approach? All these ways of working develop over time to support the needs and preferences of your team and while they’re always open to revision it’s important to share them as a starting point, not least to provide some initial continuity during the handover period.

In summary

Capture context and don’t assume that your audience has prior knowledge of the product; focus on answering questions that will develop understanding; share ‘the good’ such as new opportunities, but don’t shy away from also sharing ‘the bad’ and ‘the ugly’ such as defects and known workarounds; link to other apps where relevant, but provide an introduction about what those links tell the reader; and lastly, share ways of working to provide all-important continuity while the new product manager gets up to speed. I hope you have found these tips helpful and best of luck writing your own product handovers.