How to develop high-performing PMs, a no BS practical guide
A product leader's guide to build strong product managers through basic practices.
Your PMs are building products, but as a product leader, you can't “just” worry about the product (yes, you absolutely should, too). You need to build a great product management team. As
said: "It is the single most important responsibility of every people manager to develop the skills of their people.” I like to translate this into the mindset of:A product leader should be measured by their weakest PM.
— Not sure who said this, maybe it was Cagan?
A strong PM team can translate vision into reality, navigate the choppy waters of uncertainty, and launch products that users love and deliver on business goals. But how do you, as a product leader, cultivate greatness in your PMs?
Fortunately, it's not rocket science. Just focus on the basics:
Basics #1: Get the feedback loop right
Building a high-quality feedback loop—frequent, balanced, and clear—is the most important tool for helping your PMs grow.
Feedback frequency
It's common sense for product teams to optimize for the speed and frequency of feedback. This way, they iterate more and get to successful products faster. Funnily enough, product leaders don't realize that it's the same with people: the faster the feedback loop, the faster that person can iterate through their behavior, which results in more developed skills and, thus, better products.
Unfortunately, most leaders are already messing up here by not offering enough feedback frequently. It's not uncommon for (bad) managers to only think about feedback during the performance assessment cycles, which most commonly happen yearly or bi-yearly. This is not nearly enough.
It's understandable, though: you have plenty on your plate as a product leader. That's why I think about each direct report and the feedback I would give to them in my weekly Watchtower Reflection exercise. I usually don't have feedback for every direct report every week, but by making a habit of thinking about it weekly, I make sure I always have some feedback for some of them.
Feedback balance
Some leaders are uncomfortable giving praise, and some avoid talking about what they want you to change or improve. To build a high-quality feedback loop, you can't do either. Feedback must be balanced between positive things (to reinforce behavior) and negative things (to change behavior).
ATTENTION: I AM NOT TALKING ABOUT THE FEEDBACK SHIT SANDWICH.
I am not saying that you must bring positive and constructive feedback every time you give feedback. What I am saying is not to forget or avoid either one. Not to focus on only one side of the feedback.
You will only shoot yourself in the foot if you avoid constructive feedback. The bad behavior does not go away if the person is unaware — just like they won't remove a lettuce piece from their teeth if no one tells them it's there. If the bad behavior goes on for long enough, you might even have to fire this person, which will feel extremely unfair to do if you didn't clearly say that the behavior was bad.
In the opposite corner is the leader who ignores giving out positive feedback and praise. “They certainly know they did a good job” might be the logic behind this. I speak from experience to say that this is not true. Often, PMs are unaware of when they did a good job. Early in my career, I had a leader who gave me much praise in our 1:1s, and I was completely surprised because 1) I thought I was doing the obvious/basics, 2) I was super critical and demanding with myself, and 3) I had a huge impostor's syndrome.
Feedback clarity
The third and final high-quality feedback loop characteristic is that it is crystal clear.
Especially for constructive feedback, I like to write it down beforehand to clarify what I want to say. Spoken or written clarity starts with mental clarity. I use a small framework to structure the feedback content beforehand:
Behavior: what actually was observed, the facts, without judgment. E.g.:
“I saw that your analysis of problem X document didn't have the main conclusions at the top or anywhere in the document.”
Impact: what the result of the behavior was. E.g.:
“This meant that after I finished reading the document, I did not understand the conclusions, learnings, and next steps.”
Request: what you hope the person will do. E.g.:
“I would like you to start any such document with a top section of ‘conclusions’ or ‘TL;DR’.”
When delivering feedback, I use the Captain leadership style because I want to be clear. Then, I use the Coach style to understand the person's reaction to the feedback and work out how we can move forward from there.
PS: notice that bad/unclear feedback is often given in the Diplomat style.
PS2: One good mindset when giving feedback is to “assume good reasons, instead of just reasons” for the displayed behavior. People rarely do things with malicious intent.
Basics #2: Performance assessment as a development roadmap, not a report card
Performance assessments shouldn't be an annual anxiety-inducing exercise. If you are doing the basics #1 and giving frequent high-quality feedback, nothing appearing in the performance assessment should be new to the PM.
If something is new, you have failed as their leader.
It doesn't mean you don't need to repeat it on the performance assessment just because you said it before.
As with the feedback, I like to write down my performance assessment. I also like to deliver the written assessment before the performance talk so the person can process the feedback before the meeting.
But the most interesting part of the performance assessment is arguably not the part where you look back at what happened but the forward-looking bit. The most important part of the performance conversation is the leader and the direct report coming to a shared understanding of the good and the bad and what is expected to be improved and delivered on the next performance cycle. Building a development plan with the direct report is the roadmap for that PM's growth.
Very helpful: a PM competence framework with levels
People expect a lot from PMs. So much so that what is expected (mandatory) and what is nice to have can be confusing. In my experience, performance conversations can get really hard for the direct report to grasp without a good competence framework that outlines the behaviors expected from each PM level (APM, PM1, Senior PM, etc). This is because the competencies required are so broad (e.g., “get better at strategy”) that it is hard to understand what behaviors need to be developed, not to mention how.
If your company doesn't have one, you can begin creating or adopting one with your direct reports. I really like Intercom's PM competencies.
Basics #3: development plan follow-up and support
An unused plan in the drawer (or Google Drive) is as good as no plan. The product leader must follow up on the development plan and support the direct report in achieving it. This is also in the leader's interest: better PMs deliver better results.
For the development plan follow-up, there are 2 basic tools:
1:1 meetings; and
Mid-cycle reviews.
I already spoke plenty about 1:1 meetings that don't suck, so I will concentrate on the mid-cycle reviews:
I like to run informal performance reviews in the middle of the formal performance cycle. This is another tool to avoid surprising the PM during the formal performance cycle. It is also a milestone for the direct report to understand what is on track and what needs correcting. I use the exact same format as the formal performance review.
But remember, it's not only about following up with your direct reports. You also have to support them. This can mean several things, like working on something together, giving more frequent feedback about a certain development area, giving stretch assignments… you have to keep an eye on opportunities to support their growth.
Go and get those PMs to the next level
Remember, developing PMs is an ongoing process, not a one-time event. By implementing these simple basics, you'll cultivate a team of confident, skilled PMs who are not just building products but remarkable careers—and that's a legacy worth leaving.
If you found this article useful, please smash the “like” button. If you know anyone who could benefit from it, share it with them or on your social media of choice. This is a big help!