5 ms·

Notably absent from this list is empathy for your team. I've been a PM for 15 years. I've watched the rise and fall of the "ceo of your product" mentality. Men

Notably absent from this list is empathy for your team. I've been a PM for 15 years. I've watched the rise and fall of the "ceo of your product" mentality. Mentored dozens of PMs, interviewed hundreds. The one common thread I've noticed across a wide range of successful PMs (and absent from unsuccessful ones) is caring deeply about their team, what motivates them and what they love doing. If you can't apply the same empathy you have towards customers to your own people, you burn them out.

skeeter2020 6y ago
Not just PMs. As a Dev Manager who's been relatively successful the killer tool in my toolbox is genuinely giving a sh!t about the people on my teams. It's pretty crazy (and a little sad) how far this gets you; the bar is incredibly low IME.
- deleted 6y ago
  [deleted]
egonschiele 6y ago
100% agreed. As I read this I thought "great for whom?" The PM on my team is not truly on my team ... he's on our stakeholders team, and says yes to anything they want. This is a basic PM skill not mentioned here. Another one I don't see is communication skills. The PM is the face of the team in so many ways, and if your PM has shoddy communication skills, that ends up feeling like your whole team has shoddy communication skills.
- bedobi 6y ago
  Couldn't agree more. I'm a programmer and I'm not delusional enough to think I'd make a great product manager BUT to me it would seem as the no 1 skill for a product manager is learning how to say "no" to stakeholders. I don't mean in a non-productive way, I mean more like actually challenge poorly thought out requirements, deadlines etc etc etc. PMs only add value when they serve as an interface between the business, challenging and parsing requirements into actionable tasks with a clear definition of done, aligning with other teams to eliminate blockages etc etc. Unfortunately, many (most?) PMs do none of this, but instead see themselves as some kind of overbearing slavedriver who cracks the whip on behalf of stakeholders and their every whim without question, demands 100% insight into what everyone on the team is doing at all times, creating stress and throwing people under the bus when the shitty requirements and deadlines aren't met. It a ubiquitous and fundamental misunderstanding of the role that make them not just useless but positively harmful.
taphangum 6y ago
Very important point. Having been on the wrong end of a low empathy pm (who on the outside seemed to look like they had empathy), I can say that there is probably nothing more important than this wrt developer productivity. I don't actually even think that the lack of empathy was intentional, I think that it had more to do with a basic lack of understanding in many areas, that lead to unrealistic expectations.
PragmaticPulp 6y ago
> caring deeply about their team, what motivates them and what they love doing. If you can't apply the same empathy you have towards customers to your own people, you burn them out. Strongly agree that empathy for the team is important, but I will also say that I'm increasingly seeing junior managers (product or otherwise) become so focused on pleasing their team that they lose track of shipping product that customers will pay for. The problem is compounded in over-funded startups or cash-rich companies where the financial pressure to ship and sell product has become so abstracted away that people forget what the real goal is (sell product, generate revenue). It's a balance. Managers obviously need to work with, not against, their team. However, managers also need to be able to make the tough decisions and understand how to motivate their teams to do the work that needs to be done, even if it's not exactly the work that people most want to do. For example, I've had to talk multiple people out of writing complex React-based SPAs for simple features that could be shipped more quickly as basic static sites. I've also worked at companies that suffered greatly because they chose to rewrite otherwise functional core software in new, fun languages because it's what the developers loved doing. A large part of being a manager is focusing people on developing the right things, even if it's not the most fun and intrinsically motivating thing that the engineers want to do.
- hypervisorxxx 6y ago
  I worked for an overfunded startup but it was over funded and used the funds to hire people to give the impression of exponential growth to engineer the company for a successful ipo or sale. The people hired were sales people and they just increased the faucet of requests to the product managers who treated everyone like slaves anyways. Despite having the funds to slow down just a tad and do things the right way, you'll find the overfunded startups use their funds to put into hiring salespeople marketing and people on the business side who have been successful selling companies or preparing then for an IPO, and the number of engineers hired during this time is logarithmic in proportion to the exponential growth elsewhere. A recipe for disaster when the PMs are slave drivers all the same but everyone is asking for more all of the time. I've personally never worked under a PM who cared about the team, and I'm my opinion who cared about the product. I think they cared about their ego and seeming important and the idea of taking input from someone they perceived should be providing then requested output perhaps subconsciously threatened their idea of how everyone else might perceive them as being critical to the team. They were critical to the team. They just screwed it up by being so caught up in their egos about maintaining being in control and being right they lost sight of very objectively how their behavior could be putting the technical development and business development of the product at risk. For whatever reason people with massive egos who can control people is often valued more than the value of whatever output is produced by that. It must be deeply psychological, and for me of course as a woman, I could never be successful as a PM because if I acted the way the men I've worked for did I would be called a raging bitch, because that's exactly what they were in my opinion. For whatever reason in makes this behavior is rewarded. Very bizarre indeed.
hypervisorxxx 6y ago
Yup. Or actually acknowledging the software engineers or engineers implementing your product might be able to make you aware of some design challenges, engineering tradeoffs that will impact product or offer a more innovative solution if the PM is willing to listen. This usually requires believing the engineers have any level of intelligence besides being a code monkey and can really level with you on system design at is related to the overall outcome of a product or feature. Multiple PMs I have worked under have simply demanded an outstanding feature of product without: a) asking if it's ever been done before anywhere including say a team of 1000 google engineers much less your 11 person startup. B) input or a guesstimate of an engineers timeline on how long this would take before respectfully working towards a compromise to meet a company goal For both points having any level of reality internalized about if what they are asking is realistic. In these cases the engineers not only get burnt out but produce the feature request knowing without additional consideration whether it be addressing tech debt supporting the feature which may finally catastrophically fail under that new load or what have you, and then getting stuck putting out fires to maintain the system only to have the PM come in and finally say ok how are we going to solve this problem but under an even more agressive timeline because it's failing in production because they insisted on pushing it even though they are the only ones who were convinced it was ready. The only thing worse than pulling all nighters for a PM who thinks engineers just need to be told what to do and given a deadline and don't have any valuable seat at the table when it comes to implementing the design and a desire to help the PM be successful by highlighting challenges that could put the goal at risk to find a cool way to overcome those, is being told to shove out a crappy solution you're not proud of in a fraction of the time and then be yelled at and asked to pull more all nighters fixing it slowly and painfully the right way, with the pressure of failing customers in real time or humiliating the company by rolling back a feature, all the while knowing the root cause of the problem: The PM, is not being solved. I have crazy one liners I've been given from PMs including but not limited to: "don't talk during meetings. You don't know what you're talking about and this meeting will move along alot faster if I'm the only one speaking." In 2018 I had a PM chastise engineers on a company public slack channel that on Christmas Eve that he was dissapointed to see people actually using their vacation instead of a chance to get ahead. I've seen that same guy ask a 55yr old woman going through cancer chemotherapy to pull an all nighter on a plane during the weekend for a company trip to meet no critical deadline whatsoever externally or internally except to meet his own he had set that day and not think twice about it. I now work for a much more successful company and have been promoted beyond a senior engineer level and don't have to deal with PMs directly as such anymore but wow, it's amazing how abusive people can be in this position. On the contrary, a really good PM can take a company to orders of magnitudes of success beyond what was previously imagined. Tldr: mutual respect on a personal and technical and product level between PM and Engineers.
pySSK 6y ago
Thank you for saying this and reaffirming my belief. I haven't seen this said anywhere else and I'm constantly made to feel bad for this at my company.
- calciphus 6y ago
  Be happy that a chorus of voices seems to agree!
ulfw 6y ago
It's actually very hard to generalize these statements. I wholeheartedly agree that a great PM is a great advocate for the team, bringing team issues forward and freeing the way to get stuff done. On the other hand it's often a tight rope to walk. I've seen situations often enough where a dev team would like to change frameworks/backends/dev environments/codebases, whatever it might be. And this has to be weighed between short- and long-term success. This is where a more technical product manager shines. On the other end of the scale I've seen dev teams walk all over their (non-technical) PM because they knew they could do so. It's a give- and take between team happiness and advocacy as well as end-user satisfaction and what the company needs at any given point in time. Being a great PM is actually much harder than it seems at first.

skeeter2020 6y ago

Not just PMs. As a Dev Manager who's been relatively successful the killer tool in my toolbox is genuinely giving a sh!t about the people on my teams. It's pretty crazy (and a little sad) how far this gets you; the bar is incredibly low IME.

deleted 6y ago
[deleted]

egonschiele 6y ago

100% agreed. As I read this I thought "great for whom?" The PM on my team is not truly on my team ... he's on our stakeholders team, and says yes to anything they want. This is a basic PM skill not mentioned here. Another one I don't see is communication skills. The PM is the face of the team in so many ways, and if your PM has shoddy communication skills, that ends up feeling like your whole team has shoddy communication skills.

bedobi 6y ago
Couldn't agree more. I'm a programmer and I'm not delusional enough to think I'd make a great product manager BUT to me it would seem as the no 1 skill for a product manager is learning how to say "no" to stakeholders. I don't mean in a non-productive way, I mean more like actually challenge poorly thought out requirements, deadlines etc etc etc. PMs only add value when they serve as an interface between the business, challenging and parsing requirements into actionable tasks with a clear definition of done, aligning with other teams to eliminate blockages etc etc. Unfortunately, many (most?) PMs do none of this, but instead see themselves as some kind of overbearing slavedriver who cracks the whip on behalf of stakeholders and their every whim without question, demands 100% insight into what everyone on the team is doing at all times, creating stress and throwing people under the bus when the shitty requirements and deadlines aren't met. It a ubiquitous and fundamental misunderstanding of the role that make them not just useless but positively harmful.

taphangum 6y ago

Very important point. Having been on the wrong end of a low empathy pm (who on the outside seemed to look like they had empathy), I can say that there is probably nothing more important than this wrt developer productivity. I don't actually even think that the lack of empathy was intentional, I think that it had more to do with a basic lack of understanding in many areas, that lead to unrealistic expectations.

PragmaticPulp 6y ago

> caring deeply about their team, what motivates them and what they love doing. If you can't apply the same empathy you have towards customers to your own people, you burn them out. Strongly agree that empathy for the team is important, but I will also say that I'm increasingly seeing junior managers (product or otherwise) become so focused on pleasing their team that they lose track of shipping product that customers will pay for. The problem is compounded in over-funded startups or cash-rich companies where the financial pressure to ship and sell product has become so abstracted away that people forget what the real goal is (sell product, generate revenue). It's a balance. Managers obviously need to work with, not against, their team. However, managers also need to be able to make the tough decisions and understand how to motivate their teams to do the work that needs to be done, even if it's not exactly the work that people most want to do. For example, I've had to talk multiple people out of writing complex React-based SPAs for simple features that could be shipped more quickly as basic static sites. I've also worked at companies that suffered greatly because they chose to rewrite otherwise functional core software in new, fun languages because it's what the developers loved doing. A large part of being a manager is focusing people on developing the right things, even if it's not the most fun and intrinsically motivating thing that the engineers want to do.

hypervisorxxx 6y ago
I worked for an overfunded startup but it was over funded and used the funds to hire people to give the impression of exponential growth to engineer the company for a successful ipo or sale. The people hired were sales people and they just increased the faucet of requests to the product managers who treated everyone like slaves anyways. Despite having the funds to slow down just a tad and do things the right way, you'll find the overfunded startups use their funds to put into hiring salespeople marketing and people on the business side who have been successful selling companies or preparing then for an IPO, and the number of engineers hired during this time is logarithmic in proportion to the exponential growth elsewhere. A recipe for disaster when the PMs are slave drivers all the same but everyone is asking for more all of the time. I've personally never worked under a PM who cared about the team, and I'm my opinion who cared about the product. I think they cared about their ego and seeming important and the idea of taking input from someone they perceived should be providing then requested output perhaps subconsciously threatened their idea of how everyone else might perceive them as being critical to the team. They were critical to the team. They just screwed it up by being so caught up in their egos about maintaining being in control and being right they lost sight of very objectively how their behavior could be putting the technical development and business development of the product at risk. For whatever reason people with massive egos who can control people is often valued more than the value of whatever output is produced by that. It must be deeply psychological, and for me of course as a woman, I could never be successful as a PM because if I acted the way the men I've worked for did I would be called a raging bitch, because that's exactly what they were in my opinion. For whatever reason in makes this behavior is rewarded. Very bizarre indeed.

hypervisorxxx 6y ago

Yup. Or actually acknowledging the software engineers or engineers implementing your product might be able to make you aware of some design challenges, engineering tradeoffs that will impact product or offer a more innovative solution if the PM is willing to listen. This usually requires believing the engineers have any level of intelligence besides being a code monkey and can really level with you on system design at is related to the overall outcome of a product or feature. Multiple PMs I have worked under have simply demanded an outstanding feature of product without: a) asking if it's ever been done before anywhere including say a team of 1000 google engineers much less your 11 person startup. B) input or a guesstimate of an engineers timeline on how long this would take before respectfully working towards a compromise to meet a company goal For both points having any level of reality internalized about if what they are asking is realistic. In these cases the engineers not only get burnt out but produce the feature request knowing without additional consideration whether it be addressing tech debt supporting the feature which may finally catastrophically fail under that new load or what have you, and then getting stuck putting out fires to maintain the system only to have the PM come in and finally say ok how are we going to solve this problem but under an even more agressive timeline because it's failing in production because they insisted on pushing it even though they are the only ones who were convinced it was ready. The only thing worse than pulling all nighters for a PM who thinks engineers just need to be told what to do and given a deadline and don't have any valuable seat at the table when it comes to implementing the design and a desire to help the PM be successful by highlighting challenges that could put the goal at risk to find a cool way to overcome those, is being told to shove out a crappy solution you're not proud of in a fraction of the time and then be yelled at and asked to pull more all nighters fixing it slowly and painfully the right way, with the pressure of failing customers in real time or humiliating the company by rolling back a feature, all the while knowing the root cause of the problem: The PM, is not being solved. I have crazy one liners I've been given from PMs including but not limited to: "don't talk during meetings. You don't know what you're talking about and this meeting will move along alot faster if I'm the only one speaking." In 2018 I had a PM chastise engineers on a company public slack channel that on Christmas Eve that he was dissapointed to see people actually using their vacation instead of a chance to get ahead. I've seen that same guy ask a 55yr old woman going through cancer chemotherapy to pull an all nighter on a plane during the weekend for a company trip to meet no critical deadline whatsoever externally or internally except to meet his own he had set that day and not think twice about it. I now work for a much more successful company and have been promoted beyond a senior engineer level and don't have to deal with PMs directly as such anymore but wow, it's amazing how abusive people can be in this position. On the contrary, a really good PM can take a company to orders of magnitudes of success beyond what was previously imagined. Tldr: mutual respect on a personal and technical and product level between PM and Engineers.

pySSK 6y ago

Thank you for saying this and reaffirming my belief. I haven't seen this said anywhere else and I'm constantly made to feel bad for this at my company.

calciphus 6y ago
Be happy that a chorus of voices seems to agree!

ulfw 6y ago

It's actually very hard to generalize these statements. I wholeheartedly agree that a great PM is a great advocate for the team, bringing team issues forward and freeing the way to get stuff done. On the other hand it's often a tight rope to walk. I've seen situations often enough where a dev team would like to change frameworks/backends/dev environments/codebases, whatever it might be. And this has to be weighed between short- and long-term success. This is where a more technical product manager shines. On the other end of the scale I've seen dev teams walk all over their (non-technical) PM because they knew they could do so. It's a give- and take between team happiness and advocacy as well as end-user satisfaction and what the company needs at any given point in time. Being a great PM is actually much harder than it seems at first.