Disclaimer time! I've never managed product managers but I have been managed by a manager of product managers and I've spent probably too much of my time over-analyzing the way I'm managed so I certainly have some opinions on it despite my lack of experience.

I'm excellently managed and I think I have a shining example to learn from (Hi Derek!)

I found this excellent post about managing product managers by Brandon Chu and it compelled me to write down my own thoughts as I read through the article.

The mental model for managing PMs

It’s your job as the investor to identify great PMs that want to build something in an area you think is a great opportunity.

Mostly agree with this. I spent a decent bit of time in the startup world before I joined the enterprise and I've always thought that startup founders would make excellent PMs.

The number one thing I think you need in a PM is that self-starter attitude. They should be constantly looking for problems to be solved, be they in their products or in themselves. Once you have that you have a foundation to build on in order to help them pick the right problems and find the right solutions. That's all just optimization though, without that initial hunger you have little to work with.

Anyway, I love Brandon's investment model and honestly, it's what I want as a PM under management.

One thing I would take slight issue with is his concern about people no longer perceiving the PM as a person who can make decisions. I prefer to think of myself as a decision facilitator rather than a decision maker. Anytime I have to make a categorical decision I consider it a minor failure. It indicates that I wasn't able to convince the other party of some value that I see or find the right person with the right expertise to make the decision for me. Of course, this is tangential to the point Brandon is trying to make and he is right that disempowerment is a risk.

He's completely right about not wanting to be over-managed though. I like to be left hanging out in the wind and to figure it out for myself. I'm sure there are many times my manager saw me heading down the wrong path on a problem and could have just don't it for me but chose not to in order to give me space to figure it out.

They should have more to gain in success than you do

He's completely right when he says

PMs are super ambitious and they will not wait for you to provide them the opportunities they’ve earned. If you’re too slow, they will leave — I promise you that.

I read something (can't remember where, probably some unreliable source) which basically said that many founders are people who have excellent skills which are undervalued by the market. Think of a person who when faced with a repetitive task, automates it in a way which saves the company thousands of dollars but then just gets moved onto another repetitive task.

In order to realize their true market value, they must strike it alone and often bring the market with them through sheer force of will.

They should have more to lose in failure

Yeah, I guess. The only thing I'd add is that the initial conditions of the team the PM is product managing will matter a lot. I've interacted with teams which were so good that I could level up very quickly and others where I had to fight like hell just to keep anything moving.

The key area this difference is felt is in the amount of rework that has to be done. When you have excellent engineers you find that once you plan a feature and they implement it you don't have to go back to it again until something changes in the market. With less skilled engineering talent you end up stuck in this two-steps-forward-one-step-back cycle where you can't move on to the next customer value add because you're fixing previous mistakes.

Good managers should know this in advance and set expectations accordingly.

The true value of a PM is in the multiplying effect they have on the value of the team they work with. I guess that applies on the flip side too.

PMs develop best when shipping Whole Customer Experiences

I think about PM skills as things more like conflict resolution, leadership, data analysis, motivating developers etc. These are things which can be practiced on most products and projects so I'm not super concerned about where I'm deployed.

I agree that it's possible to pigeonhole PMs. The person who knows about UIs will become the UI PM, the person who knows about infrastructure will become the infrastructure PM and so on but I feel the way to combat this is by having frank conversations with your manager where you describe what you want. If your company can't provide you with that then it's time to think about a change.

It's each person's responsibility to ensure they are not pigeonholed. To become simply an expert in a narrow vertical is to risk becoming obsolete.

Finding the right scope for a PM

I have definitely been subjected to the results of a mistake in this area. It's not easy to get right at all. I got moved to a second product because it seemed I could handle it, numerous products grew a little and before I knew it I was trying to stay afloat PMing 28 developers split across 5 different teams.

I really like the dimensions along which Brandon recommends assessing each product area but I have a word of caution around "Strategic importance". It's easy to give a developing PM a product which is not of huge strategic importance with the assumption that even if it doesn't go well, the impact to the company can't be too great. However, a good PM will pour their heart and soul into making the most of this unimportant project and its success or failure will become a big deal to them even if it's small stakes for you as a manager. Don't forget their perspective isn't as broad as yours.

Managing PMs that manage other PMs

if your senior PMs need to scale, help them figure out how to divide up their current product areas into the whole customer experiences that an incoming PM could own autonomously.

Definitely, agree with this. It's like the MVP of scaling PMs. If your product vision is a "mode of transport" then your MVP is a fully functioning but slow scooter. The wheel of a Ferrari is also part of the implementing of an MVP but it's not a value-adding mode of transport. The scooter can provide value to some small cohort of customers who want to get somewhere nearby, the Ferrari wheel proves nothing of value.

Assessing PMs for Performance

The theoretically perfect way to assess a PMs is through the performance of the products they manage

I could do a stellar job for 10 months on a product and then have it shut down by the exec branch of the company for some resource allocation reason completely unrelated to my personal performance. Similarly, some teams are so good that I could do practically nothing for 10 months and the team could still succeed in all their goals.

Brandon is completely right that while product performance is an important dimension for assessing PMs, it can't be the full story.

His most important indicator of PM ability is how trusted they are by other people in the company. He's completely right that the PMs ability to do their job is a function of the trust that others have in them.

Note that trust is different than likability. People appreciate likability but it's not the end-game when it comes to being a leader. When people trust you they will be willing to go your direction because they can be confident that it is the right direction. It comes from building up a cachet of many small experiences where people put their faith in you and didn't get burned. As Brandon says, that's your firepower, and it's worth a lot.

If you haven't already, subscribe to the productmanagerhq.com newsletter. It's a goldmine of good ideas each week and it's where I came across this article.