How to offboard as a Product Manager

So what do you do when you leave the company?

I decided to approach it like a PM should — do it for your customer. In my case it was a new PM, whom I didn’t know as he/she wasn’t hired yet and was yet to be found.

But even though I didn’t know anything about this person it was probably one of those “customer” personas that I can really deeply relate to and understand their needs more than anyone else in the company.

First off, I read through the onboarding tips, as my offboarding should’ve addressed them.

In short the new PM would need to

• Build up context and business understanding of the product. Learn to “sell” the product.
• Understand how the product is built, bond with engineering team.
• Get as much as possible in front of the users.
• Ask other POs how he can help them.
• Work closely with sales and marketing teams — they are the primary channels for feedback.
• Clearly understand what’s expected from him and the product, get alignment with CEO and key stakeholders

Boundaries of the offboarding

At the same time I had to consider restrictions that I had

• I won’t be there to walk through the new PM — the whole thing would have been much easier if we could just meet and spend a week working together.
• I don’t know the background of a newly hired person.
• Product managers’ favorite questions start with “why…” and “why on earth…”, so I’d better have some answers for them.

Eventually, I came up with a wiki page. But it is not the format of offboarding that’s important, you can do it verbally, in video or whatever you are good at.

Here’s my suggested offboarding checklist.

Offboarding checklist

1. Product context. What’s the situation on the market, where you are, and why you are there with the product? Provide basic set of artifacts: competitors research, business/lean canvases and personas, feedback you have from customers. Outline important events in your product’s life with more attention. Changed a business model? Explain why, which metrics and data you used to prove the need for it. Carved out a feature? Again, tell them why you did it. No one was using it? Did you plan to incorporate it in another part of the product. Or was it just the wrong feature which drained your team’s effort and didn’t create enough value for the customer?
2. Existing [problem] roadmap. I try to avoid features in roadmaps as much as possible. If your roadmap is full of features, I would suggest creating a separate one with problems to solve and results to achieve. Put it next to your “feature-roadmap”. This piece of information should give answers to questions like “why did we planned to do this feature?”, “is this the right order of problems to solve?” and “how will we measure success of our initiatives?”. This approach doesn’t just tell what to do, but rather makes sure the whole concept is open for discussion, the next person might have better ideas or might validate/invalidate yours during his time, and it is better for him to know your assumptions rather than struggle to get rid of features in the backlog. This article and this one give good insights on roadmaps.
3. Process of working with the team. Again, state where you are. Have you recently changed the process from Scrum to Kanban? Tell him why. How do you solve bugs on production and why you do it like that? How did you work with support and what did you want to change? These types of answers are important for a new PM to avoid going for instant changes.
4. Process of working with stakeholders. Who are they? Your CEO, investors, other product managers? How do you work with them? What are the good and bad experiences you had with them? —The point is to make sure the new PM avoids your mistakes with this important lot of people.
5. Current way of setting priorities. Describe how you prioritize feature requests, bugs, your stakeholders’ ideas. Prioritization is the most heated topic PMs discuss with devs, stakeholders, marketing, support and account management teams. If you experience difficulty in prioritization —say it, so that a new guy knows that this is a topic where he should find a solution. If you already have a framework which works for you — describe it, but don’t forget to state the results you achieved with it. And I mean business results rather than features being built. A new PM should understand what was perceived as success or failure and compare it with his own standards.
6. Tools that you use. I put it in the end as in my experience they are the least important things as the problems to solve should come first. Analytics —what, how and why you measure. CRM —how you manage your customers. Backlog —when and who adds items there, what is the workflow. Your deployment strategy —just give a brief understanding of a release cycle for a feature and waiting time for a feedback.

Before you feel accomplished and ready to leave

• Remind your boss what was wrong during your stay and what helped you. He should know it all and take into account when working with the new PM.
• Talk to the team on what you feel did and didn’t work, but also outline that a new PM might have a different style and ask them to be open to his views and ideas. Also mention where their role really helped you to make better decisions.

As you can see the general tone of this offboarding exercise is all about describing your thinking and working process. You never know who’ll come after you and with what kind of background. For such kind of “customer” it is more important to understand the rules and principles you’ve followed rather than to see a list of features to build. The new PM is hired to make a difference and help the team, so make sure they have answers to typical questions.