We know how to train Devs, Designers, Marketing and DevOps but how do you train someone to be a good Product Manager? It’s something everyone “kinda” knows, but let’s be honest: There is no “formal” and “structured” way to train someone in the product discipline. Afterall, to the best of my knowledge, there are no bachelor’s degrees for Product Management. Usually people jump on it from other disciplines and learn along the way, with varying degrees of success 😛.
Why is it important to train Product People properly?
Product people may not be the direct managers of people, but they are managing them as resources. Afterall, they decide what features the team will build. An average product person with 10 people with 50k average salary means that even a junior product owner can find themselves being responsible for half a million dollars budget in man-hours. That’s quite a lot of money, to let these people learn on the job!
In this blogpost I will try to give a structured answer on how to train your next product manager. You may agree or disagree with what I will propose, afterall everyone comes with their own experiences, what I am advocating here is that any kind of structure and conscious decision in their training is better than nothing.
The two main axes of training
In this example picture, I am training Pylo: An aspiring product manager, who is very eager but, alas, with zero experience in the field. Fear not, we are here to transform Pylo to an aspiring battle hardened Product Manager!
For me there are two main axes where a product is trained: What will the team build and when and stakeholder management. This is not an exhaustive list of what a product person does but you can easily build something around those two premises.
What will the team build and when
Broadly speaking, this is the gist of what product people do: We decide what the team will build and in what priority. Something along those lines:
So, what will Pylo do out of these in the beginning? None of the above! 😝Pylo will be told by his seniors on what he will build and in what order. Don’t forget Pylo has zero experience. The first thing he needs to do is learn the process.
But I used to be a dev/designer/qa I know the process!
Nope you have seen and experienced the process, doesn’t mean you know how to run the process. Put this another way: I have been working with devs for quite some time, I know programming doesn’t mean I know how to code properly. Simple as that! 🙂
Then, you slowly remove the training wheels. You let them run the process without oversight, break down their own small tickets and slowly but steadily you remove yourself from their daily lives. You gradually begin to directly intervene by exception rather than necessity. The end goal is for them to get to a point where they make their own budgeted roadmaps and approve/reject/iterate after hearing their pitch.
Here is a small roadmap (pun intended) on how that growth path could go:
Of course you have to treat this as milestones rather than fixed steps. There could be many steps in between each milestone. Some people may be able to learn some stuff, faster than others.
It’s important for you to decide together with the trainee the roadmap of their growth and have multiple meetings with them during the process. Not everything can be covered in 3 boxes with Bob Squarepants 😂.
Stakeholder management
The other important pillar of a product person is that while they are deciding what to build they need to communicate and manage expectations.
So, how does this work? Well, this is a bit simpler. I break it down into three main categories. Team, Internal and External.
Let me elaborate a bit on the order. Naturally, what a product person needs to do is know how to work with their team. Gain their trust and their confidence. Have nice chemistry with them and build a process with them.
Afterwards you slowly start expanding them to internal stakeholders. For example customer success, sales or maybe even an executive who needs an internal tool. You can even tell the executive before-hand that they will be part of a training process (in fact I recommend it). It’s important to check the following: Can they work with a stakeholder without friction? Can they stand their ground or do they always say yes? Do they know when to escalate?
Now, it’s pretty obvious why you want to training ground to be internal stakeholders: Mistakes are cheap. Even if something goes wrong worst case scenario it will cost you a couple of meetings to amend requirements and scope. Furthermore internal stakeholders are generally more available, rather than that CEO from that important customer!
Finally, you gradually introduce them to external stakeholders. You can start with something simple such as a feedback session, then slowly move to eliciting requirements. You should also probably start with someone lower on the food chain, such as users. You probably don’t want to book a 1-1 meeting with the decision maker of that big customer with your junior Product Owner!
Again, you can slowly remove the training wheel.
1. Take them with you to a meeting with a customer and tell them to just listen.
2. Have them lead the meeting with a customer and you being there as a fly on the wall.
3. Allow them to have meetings with customers independently.
Again, these are milestones rather than fixed steps. Take this as a guideline rather than a recipe. After All each person is different. I will also repeat: It’s important for you to decide together with the trainee the roadmap of their growth and have multiple meetings with them during the process.
Specialization
There are specializations in the product discipline. You can be Technical, Growth, Marketing Product you name it. The above framework that I provided works pretty much independently of the specialization, but when you are training someone it’s worth having a conversation of what type of product they would like to become and make amends accordingly.
Conclusion
Even though we don’t have bachelor’s degrees and formal training on what we do, it doesn’t mean that we can’t find a systematic way to disseminate our knowledge and train new people. It’s my belief that people are too much of a central part of the team to be left to learn “on the job”. So, whether you agree or not with what I have written, I think it’s important to have the conversation. At the end of the day just like we build together with our teams the processes they we will use to build the product, we can work together with other product people to figure out the best ways to train ourselves 😀.