One of the topics that I’m teaching in the CPO Bootcamp is the effective management of product teams. Managing product managers is tricky because it is more similar to managing managers than to managing individual contributors, and often this is a big leap in your management philosophy.

One of the things that makes it so tricky, is the question of ownership. Generally, as a manager, you want to find the right balance between giving your employees the proper degree of freedom and independence, while maintaining your ability to remain in control and guide the team. This is hard enough to do with your existing team members, but when onboarding a new product manager this is even harder.

Oftentimes a new product manager takes over someone else’s domain. It can be something that you have done yourself up until now and realized you need another hand on deck (this is very typical for startups, where the product leader is usually the first and only product manager until they hire their first employee). It can also be that you decided to reshuffle the responsibilities among your team because everyone was so busy. In any case, unless this is a new domain that just waited for the new product manager, you are onboarding them while things are already in action. How do you transfer the ownership without letting the ball drop?

Here is a three-phase process to make this a smooth transition, both for you and for them.

Phase I: Shadowing

When a new product manager lands in a company, they need to learn many things. They need to get to know the people, to learn about the domain, to understand how things are done in this specific company, to understand the product and its strategy, and so on and so forth. Even if the new product manager is transitioning from within the company, there are many things to learn. Specifically, these are usually the things that are harder to learn in theory.

Understanding how things work is not something that can be done through reading. To truly understand you need to be involved, you need to see it for yourself. So in parallel to the theoretical learning (read everything they can about the domain, the market, the strategy), the proper introductions (meet 1:1 with all the important people to get to know them and hear their perspectives), and dogfooding (using the product to learn its capabilities firsthand), the new product manager should be shadowing the person they would be taking over from. 

Shadowing means that they walk with them into all relevant meetings, just to listen, even if they don’t understand half of everything said. It means understanding what the current product manager is doing, and why.

The new product manager will have tons of questions at this point – and that’s how it should be. They should carry a notebook to write all of them, and you should be setting time at least once a week (but preferably every other day or so) to sit together and get all of their questions answered.

The nice thing about this method is that it touches everything the new product manager has to learn anyway – they get to meet the relevant people, understand the processes, and learn about the product and the domain as they go. Their questions would be very relevant, and it already sets the ground for them to start doing it themselves.

Phase II: Front Switch

When the time comes, the new product manager should take over. But this is never easy. On one hand, you want them to start taking over as soon as possible since you are probably eager to get their contribution (and honestly, take some of the load off of yourself). On the other hand, you might be afraid to let go too soon, especially if the area they are taking over is a major one.

To bridge this gap, there is a middle ground that will allow you to walk safely on the ground while letting the new product manager take the lead. You make the switch – the new product manager now becomes the owner of the area you want them to own. You should send a formal email letting everyone know, and whenever someone asks you a question about this area you send them to the new person.

However, this switch is made only at the front. At the back, you are still accompanying them in everything they do. For example, when you go to meetings with them, you let them answer first if they feel they can, and you complement their answer after they are done to make sure nothing is missing in the discussion. It is perfectly fine if at this point they don’t make any decision or answer any question without consulting with you first. I used to sit with my new product managers and draft the emails they would send together with them. 

This method allows you to handhold them for as long as they (and you) need and is often the only way to get someone to start walking on a ground that they don’t yet know well enough. It allowed my product managers to be willing to jump right in because they knew I had their back.

Since it allows them to take over sooner than they would otherwise, it serves them well on another front – the company starts seeing results from them sooner rather than later. It doesn’t matter that all of these results are mastered by you in the background. They start owning people’s respect and build the proper relationships. They start walking in the shoes that they need to make their own.

Phase III: Back Switch

At some point, you need to take a step back and let them take over completely. The beauty about this method is that since they already are leading on the front, this no longer has to be a singular point in time, and can happen gradually and naturally.

Here is how it works: as you accompany the new product manager behind the scenes in everything they do, you can start reviewing their work instead of doing it together with them. For example, when they need to answer a certain question, you can discuss how to approach this, and ask them to prepare a draft that you would be reviewing together. In the review, you give additional guidance as needed (explain to them how you see things and why you want to make certain changes), and they come back with another draft until you feel it’s ready.

This takes them deeper into working independently but still lets you control any external communication. Gradually, you will see that you have fewer comments to make, and they would start doing the right thing themselves without needing guidance from you. This is when you know that you can take a step back and let them run independently.

Note that since there is no longer a need for a big announcement, you have flexibility in where and when you let go. For example, you might feel comfortable with letting them work with R&D and create user stories, but you still want to be involved in planning and prioritization. You might even get more granular, and let them run themselves on certain user stories while you still work with them on others. In some cases, you will let them go by themselves and realize later that they still need help, and you can get back involved as soon as you see this.

Most managers will be happy to let go when they feel their contribution is marginal, and since you already made the formal switch, this decision can happen without too much analysis or fuss. In fact, it’s no longer a big decision, but rather many small independent decisions. For any specific task or topic, ask your product manager if they need your help in this or they feel they can manage alone. Let them know that you are available if they need anything, and let them lead.

You have done all the hard work already, so now it’s time to lean backward and enjoy the view. Or, as is probably the case for you – get back to do the many other things you need to. Who knows, you might even have time to think about strategy 😉