The ultimate guide on how to manage young PMs in your team. Includes Dos and Don’ts, examples and modus operandi using which I wish I was led/managed early on when I started as a PM. Also, young PMs could takeaway lessons from here on what to expect and ask from your managers.
With that being said, the article mostly revolves around the Indian context where we don’t have an Associate Product Manager (APM) program like the ones at Google, Uber, Twitter or Rotational PM programs like at Facebook, Dropbox but one can always mine out what is relevant to them. Most of the young PMs in India either become a PM after their MBA (majority of the population) or after being a software engineer for a couple of years (seen often) or straight out of undergrad (path less traveled) or post-entrepreneurship (even less traveled). I belonged to the third category, I wanted to pursue product management straight out of undergrad. And so I did.
Without further ado, here goes:
A young PM might have a very basic and minimal idea on what the product and the business is about. For example, they might know “it is a marketplace model, there are buyers and sellers on the platform”, great! Though, as we all know there is always something more to this.
They don’t know the business and product as a whole. How different moving parts work together. Why am I focusing on the word “business” here is because the PMs need to absolutely understand how the business works and how the Product (the experience, the tech behind it) is facilitating business growth? The earlier the young PMs understand and know about the business side of things, they will easily pick up the rest of the moving parts.
When I say show them the bigger picture, Senior PMs should also talk about the long term vision and goals of the company. Where the company is heading and in what direction should the young PM think. It is quintessential. Always and always ask the young PM to think long term and look at the bigger picture. This will be a stepping stone for grooming them into becoming a great product leader later in their career. Ask them to think strategically.
Part of a Product Manager’s living comes from problem-solving. It often happens that a young PM is brought in the team to assist a senior PM. Since the senior PM does not have much bandwidth to work on all of the stuff, some part of it is handed over the newly hired PM.
Here is where the problem starts. The senior PM has a glorified idea on how they will solve a particular problem and how they will change the world 🙃. They won’t hesitate and will quickly ask the young PM to execute a solution. Additionally, they will also be judged on how quickly they ship the senior PM’s glorified idea. That’s a very poor approach.
Bring them in as problem solvers and get out of their way.
Often, a product leader will have biases, presumptions and will be so in love with their solution that they will try to fixate that into people’s mind including the young PM, stakeholders, etc. It reminds me of a particular scenario where I was working with a senior PM who would go in and change the UX copies, email copies written by a content person because it didn’t match their version of the solution. It is a classic example of a senior PM not able to clearly communicate their version of the solution, let alone the problem statement. An efficient way for product leaders to go about this is to effectively communicate a problem statement to their younger counterparts. If need be, refine the problem statements again and again up until everyone is aligned on what problem is to being solved. Let them figure out the solution. Closely watch what approach they are following to arrive at a solution. If need be, do a quick course correction and push them in the right direction.
A Tip for young PMs 💡: If during interviews, the interviewer is too much stuck to a solution as opposed to discussing the approach you took to solve a problem, umm… I have some news for you. However, thou should be able to judge the situation thyself.
This tip revolves mostly around the Indian context. There’s a boom of tech startups in India and having a Product Manager is cool nowadays. But, the majority of the people in this booming startup ecosystem don’t have any clue on why they need a product manager. More often than not, an amalgamation of too many job roles or a jack of all trades is hired as a Product Manager. Which sometimes is true, a PM should be able to get their hands dirty and get uncomfortable as and when required. But, it does not entirely do justice to the role of a product manager if you bring in young PMs to just do that.
A product leaders job is to be absolutely clear with them (young PMs) on the job role and responsibilities. A lot of aspiring PMs come in with great expectations to learn the art of product management, the best a leader can do is to not give them a false idea on what product management is.
A few common NOT-TO-DOs are listed below:
A great essay has been written by Sachin Rekhi on The Art of Being a Compelling Product Manager, where he talks about the style of product management which includes things like your communication style, on how effectively are you able to influence people without being authoritative, stakeholder management, etc.
Every product manager has their own style. It is something that they have developed over the years, how they have grown up, the people they meet with, talk with, events in life. Something that is deeply rooted within them. Try to change it and it will affect their day to day work and performance.
Do not try to make them like you.
I was working with a Product leader who had recently joined our organization and he came from an environment that was too aggressive, the product team there would try to influence the stakeholders by force and aggression and vice-versa. It came to a point where I was asked to be aggressive at least once a week with the stakeholders and was added as one of my KPIs 😶. It didn’t fit well with me.
All you can do as a Product Leader is to mine out the advantages of a Product Manager’s style and ask them to make little tweaks that align with their taste and push them in the right direction to use it to their benefit. A style should remain unique.
Here, I am going to talk about how you can make the lives of young PMs in your team easy and which will in turn help in improving the team’s performance and morale.
1) Make them a part of your meetings and email chains with the stakeholders and executives when you’re discussing something that they’re going to potentially work on.
Loop them in from the start to avoid any context loss.
I was working with a product leader who would add me to an email chain (+aahan) after they had reached a conclusion and I had to basically read the long ass thread and go to him if I did not get something from within the thread. I’ve also worked with senior PMs who would add me to an email chain and ask me “Aahan, by when can you give me the PRD for the same?” 🤯. Without a hint of what problem I am solving!!
A great technique to avoid doing is to loop them in from the start and make them feel valued. Additionally, it gives the young PM an idea on what problem they’re trying to solve, what impact will it have on the business and how they are going to change their users’ lives. It will bring absolute joy to a young PM if they know what they’re doing and why.
By now, if you’ve started to connect the dots and if you have got tip #2 right, you can ignore this point because if a product leader has hired young PMs in their team to solve problems. The approach to this would in itself be different.
2) Teach them to prioritize ruthlessly. It is absolutely important for a PM to be good at prioritization. Be it a product roadmap or their day-to-day tasks. It is important for a young PM to learn on how to prioritize a product roadmap but there are plenty of frameworks which they can refer to like the MoSCOw method or the Kano model or the Effort X Impact matrix. What is equally important is how they prioritize their daily tasks and it is often a hard-learned skill.
Arguably, I feel that efficiently prioritizing your daily tasks is harder than prioritizing a product roadmap.
The way you prioritize your daily tasks will affect a lot of people within your 1st inner circle of reach namely, the engineering, the design and the business teams you directly work with.
A product leader should teach their younger counterparts on how to manage their daily tasks in a way that it does not create a blocker for anyone with whom they’re directly working with (mostly engineering and design) at the same time managing expectations from stakeholders and the executive team.
3) A senior PM or a product leader should be of help to their team during the start of the day. Do not make them wait (unless you can’t really do anything about it) till the end of the day.
As a senior leader, you should know the cost of a delayed or missed opportunity.
Be it signing off on designs or any other decision. Please prioritize your day in a way that it does not block your team’s time because they’re the ones who will be getting things (read, features) out.
When we say ‘empathy’, it is a way of understanding someone’s underlying needs and motivations. While one should be empathetic towards their users, we will also talk to being empathetic towards your team. So, how can the product leaders teach empathy to their team?
1) Be absolutely clear on what success means for the user/customer: A lesson that every product leader can teach their team is to know and understand what a successful human outcome (for your users) looks like and how they’re using the product to accomplish it. You should give complete freedom to your product team to ask the right questions to anyone involved the process, be it to users during the user interviews or to stakeholders during the stakeholder meetings. It is absolutely necessary for them to be clear about what the users expect from the product.
A good product manager is a truth seeker. Without knowing the absolute truth (or swallowing the red pill 😉 ), one can’t build anything valuable for their users.
A young PM will sometimes have biases about particular things/people. Especially, when PMs are talking to the business stakeholders, they have biases towards a certain set of stakeholders. It is a product leader’s job to help them remove any biases they have in their head. Biases are harmful. Teach them on how to empathize with their stakeholders and understand what POV they’re coming from, on what success means for the user from the stakeholder’s POV. Often, teams are not aligned on what success means for the user. A PM should align (read, repeatedly align — just because you said it once, doesn’t make it so) everyone involved in the process by being empathetic to them and hence collectively being empathetic towards the user/customer.
2) Find out the underlying motivations: Teach your product team on how to actively listen to your users and stakeholders to find out the underlying motivation. Listening as a skill is quintessential for a leader. Do mind, listening is different from hearing. Listen to understand and seek the true motivators for your external (users) and internal stakeholders. Use the right set of questions and use the “why” ladder to seek the absolute truth.
A few things to keep in mind during the first 30–45 days after hiring a young PM:
1) Introduce them to the key stakeholders. It will be overwhelming for any new employee who has joined an organization. Especially for a Product Manager, who will spend much of his time talking to a wide variety of cross-functional teams. Explain them the team structure. Processes the product team usually follows while working with the stakeholders. Which stakeholders have the most knowledge about the market, users, etc.
2) Take them to meetings. In the early days, take them to every meeting that you have scheduled for yourself for the first 2–3 weeks. By doing this, they will start getting a hold of things, get to meet people, connect the dots. Let them ask questions during the meetings.
3) Give them access to tools. When a PM joins a team, they’re usually hungry for knowledge and they’re at their peak curiosity level. While they’re going through your products, getting onboard, tools act as catalysts and they will be able to quickly pick up things around your product, business, processes. Here, I am talking about tools like your JIRA boards, analytics tools, internal wikis, testing/staging environments, etc.
This does not mean they can do whatever they like and make any decision they think is right. Autonomy here means give them their freedom to think about the things that they think is right for the product as if they own the product.
Autonomy to think does not cost a single penny.
Product leaders should try to create an environment, a culture within the product team where no PM has any preconceived notion of how they’re supposed to think or they should not feel restricted to think about things. As a product leader what you can do is to help them structure and filter their thoughts and opinions about somethings (like UX design principles, markets). Do not try to influence their thought process.
Todd Jackson in his talk at First Round has beautifully pointed out the reward centers in the PM brain, with Autonomy being one of the most important ones.
This usually applies to any manager who has an individual contributor reporting to them. But, in the product management context where the young PM is taking care of so many moving parts (and in their early stages of the career), it is certain that they will make mistakes. A few common mistakes which one should allow their younger counterparts to make are:
When mistakes and failures are allowed, PMs will eventually start to think and work like responsible leaders. What product leaders can do here is to give them frameworks to course correct the mistakes, to help them think of a wider impact before making decisions, the importance of owning up to the mistake.
Thank you, readers. I would love to hear your product management stories and lessons so far. Do share them in the comment section or hit me up on LinkedIn or Twitter. If you liked the above writeup, share it with your peers, try to implement a few of them. Feedbacks are always appreciated!