Photo by Braden Collum on Unsplash

Handover for Product People

If you ever changed jobs as a product manager, you know the confusion and excitement that comes with the first couple of weeks and months. There are new names to learn, abbreviations you’ve never ever heard of, and a constant influx of information that makes little to no sense.

I know that feeling very well, because over the last couple of years, I worked on six different products. I had new products handed over to me, and I had to leave some products behind. And with every new product and team that came my way, I learned a little more about what it takes to make a handover successful. These things I want to share with you today.

Why should you care?

If you just want to „get the hell outta here”, chances are high that a handover is not the first thing on your mind. But at least for me, I never wanted to abandon my teams or products. I wanted them to keep succeeding, and the best possible way for me was to make it very easy for the new PM to have a good start.

So if you are about to leave your job, the following advice might come in handy. It could also be helpful if you are a new hire, because the outline below gives you an idea of which questions to ask. And even if you are a people manager who has to ensure a smooth handover between two of your employees, you’ve now got a structure to follow. Let’s dive right in!

Don’t wait until it’s too late

You might be familiar with the song “Let it go” from the movie “Frozen”. I certainly am, because I have a four-year-old daughter at home. I still think it’s a great song (even after listening to it approximately 250 times). And it has an important message for everybody who is about to leave a job. You need to let go. Let go of the daily tasks and shift your focus to make sure the handover goes well.

Why is this important? If you identify with your product and your team, chances are high that you have a hard time to let go. You are the expert on your product, you know all the stakeholders, you keep it together. It’s easy to get sucked into the craziness of the last weeks, just trying to finish everything off so you can hand over a clean slate. But let’s be honest here: Do you ever reach that stage as a product manager? Things will come up again and again, and if you don’t make time for a handover, it’s likely to end up as some sort of mess.

So the biggest mistake when leaving your job is to continue to work until the very last minute. It won’t help your team or your product if you figure out all the details that seem to be urgent, but forget to set up the new PM for success in the future. Taking time for your handover will mean that you have to take a step back. But it’s a step in the right direction, because eventually you will need to cut yourself off anyway.

Reduce cognitive load

When you prepare a handover, you have to do it with exactly one user in mind: the new PM. This person will be overloaded with information in the first few days. It might seem easy to schedule a meeting with her or him and drop all your knowledge, assuming that the person will just take some notes and that’s it. But it’s hard to take notes without any context. When I was handed a new job, I usually struggled to take notes while listening and I struggled even harder to make sense of them later (partly also due to my handwriting, my fellow lefties out there will know what I mean).

So if you want to do one thing right for your handover: Write it down. It doesn’t have to be fancy, just an outline with bullet points. You can use this document when meeting in person as a structure to talk through everything. Your successor can make notes and add questions directly in the document which you can tackle later.

Other ways to reduce cognitive load include thinning out the backlog, removing outdated documentation, generally cleaning up after yourself. This will help the new PM to make sense of everything faster. But if you don’t get around to it, don’t worry too much. The one thing to really focus on is the handover document. It will be the guideline to make sense of everything else.

One place for everything

Let’s say you put aside some time and want to work on your handover document. Where to start? There’s so much information you need to bring across, it can seem daunting. I usually feel better when I have one place to put all the stuff that’s on my mind. This could be a Google document or a Confluence page. Ideally it lives where most of the other documentation in your company is kept, because this makes it easier to add links to important resources. Keep a tab open on that page, you will use a lot. How you proceed from here depends on your working style.

Choose your approach

When I wrote my first handover document and didn’t have a structure to follow, I just used it mainly as a brain dump. Whenever I opened a tool or document that was important for my work, I copied the link in there. Whenever I talked to somebody who was important for my job, I wrote down her name and role. Whenever a new project came up that would likely affect the team in the following months, I added it to the list. I later spent an hour or so to sort those things into buckets.

Even if you later sort the notes, this unstructured approach might suit you well, because you don’t waste any time thinking about which category to put things in. You can still spend some time later to make it look pretty. I definitely prefer this style because it means that I can work as I go, adding to the document every single day with a minimal time investment. For the structured approach you reserve some time and try to fill in the categories below.

In both cases, you should start a couple of weeks before the actual handover. Once you are done, frequently revisit the page and check if you forgot something or somebody, based on what you did and who you met during the last couple of days. After sorting everything, don’t forget to add a table of contents. This seems like a silly advice, but again, it’s all about reducing cognitive load.

Photo by Zach Lucero on Unsplash

Document structure

This brings us to the actual document. I’ve tried to write down all the categories your handover document should include. It might look like a lot, but the categories will mostly be filled with bullet points and links to pages that already exist.

This list will help the new PM to imagine how a typical work week looks like for you and which tasks they have to take over. Simply add all tasks that arise during your workday. There might be standards like “refine & prioritize tickets in Jira (daily)” and more role-specific things like “check and answer reviews in Playstore (2 times a week)”. Add links wherever you can. I didn’t mention the meetings here because there is a separate section for this.

In most cases, there comes a new team with a new product, so it makes sense to help the new PM with names and roles as well as a “who is who” of all relevant stakeholders. I also add a list of meetings with a short description for a couple of reasons: Sometimes invites get lost, some meetings miss an agenda or have weird names that are not self-explanatory. The overview should help the next PM to take a more informed decision about which meetings to attend and what to expect.

This is the section that takes most time to write. It is a place to describe the projects and topics that are planned or currently being worked on which affect your team. I usually write one paragraph or sentence per project (depending on the complexity) and then add some links to epics or relevant documentation. There are three big buckets which I use to sort the projects: Team projects (planned or ongoing), Company projects (bigger projects which the PM needs to know about) and Potential Projects (ideas and issues for the PM to think about). I usually had 5 to 10 entries per bucket, but this depends a lot on your company size and organisation.

Finding access to the tools in a new job can be a nightmare. You might have accumulated a number of bookmarks/ shortcuts over the years, but the new PM won’t have those automatically. Make sure you share as many as possible, making their life much easier from the start. They will still struggle enough with setting up new passwords and making sense of everything.

This last section is the place to share all the documentation and resources that you find useful for the future PM. It could include technical documentation, information about where to find research results or links to the product vision. Be aware that you don’t want to link to outdated information here. If in doubt, I included the link with a disclaimer.

What else?

This guideline only applies to the team specific handover. It doesn’t go into details on how to hand in your vacation request or where to find the coffee machine. Your job is to set up the new PM for success, but you don’t have act as some sort of line manager. Ideally your company has a general onboarding document for this purpose which you can link to.

Once you have the document ready, sit down with the new PM and talk it through (if that’s possible). You might want to add information about company politics and anecdotes that you didn’t want to write down. Even though it’s tempting to share some gossip as well, make sure that you are respectful towards your current colleagues. Just because you had trouble with some of your stakeholders, doesn’t mean that they and the new PM can‘t get along fine. If anything, I tried to set an optimistic tone and told the future PM that they will have a great team and vice versa. It’s good to start off with the benefit of the doubt.

Again, the most important thing here is that you want your successor to look good. Because it’s the professional thing to do, but also because this will reflect back on you. The new PM will likely be grateful, and so will be your manager and your team. A good handover will make it easier for you to leave, but it will also help you to stand out, even after you’ve left.

For the German version of this article, please see here:

Product manager who loves interior design, gardening & camping. Based in Hamburg, Germany. Twitter: @alsterfalter