7 ms·

I've led product teams at early stage and through growth into unicorn valuations. The unfortunate truth is that communication challenges are often not the resul

I've led product teams at early stage and through growth into unicorn valuations. The unfortunate truth is that communication challenges are often not the result of any one single PM. A couple of larger "failure modes" drive bad communication in the broader system: - Executive leadership pushing down poor decisions through Product - The "middle-man" problem. - Product teams who are judged by output vs. outcomes - The "SHIP IT" problem - Hiring Product Managers who got into the position to be "CEO of the product" - The egotistical asshole problem. - Engineers who prioritize clocking-in/clocking-out over building a quality product - The "jaded but I get paid well" problem. Being a PM is an incredibly challenging role, often made more difficult by the environment - If you find yourself in a position where you want to do good work, but are constrained by the above (or similar) issues, fix them. Influence up, take ownership of explaining why the processes aren't delivering the outcomes leadership wants, and find ways to prove a better way to do things. Motivate your team - Help them understand why the work matters, and chart a path for them to do something awesome together. Advocate for better, and help it happen. If your response to that advice is "ugh, yeah right - that'll never happen here", you're either right (and need to leave), or you're the problem PM that is accepting failure as a given. If you want to be great, make sure everyone on the team can do their job well, and that the product team is set up to make a meaningful impact on your customers.

freedomben 5y ago
There's one thing I think you left out: A great PM will defend their team from management. When management wants to do things like pivot from X to Y, or focus on Z to the neglect of W, a great PM will point out that engineers are not fungible, and that such things can hinder motivation, increase frustration, and lead to lower output. When management decides to do it anyway, and get frustrated with the team's lack of progress (especially on product W which management expected would magically stay up and stable), a great PM (in a professional way) reminds them of the history and that decisions have consequences. Unfortunately a "great PM" will sooner or later have to choose between doing the right thing for their team or the right thing for their career (management does not like to be told no or blamed for any failure). The great PM usually doesn't climb the management chain, so if you are a software engineer with a great PM, please tell them, it may be the only thanks they get.
- sophrocyne 5y ago
  I agree with you largely, except for one thing - Doing the right thing for their team is the right thing for their career, whether current management sees it or not. There are hundreds of companies who will happily have you be a great PM or leader at their company if your current leadership team is more concerned with promoting sycophants.
- hydrakai 5y ago
  I would say that the PM needs to do the best for the company, which sometimes is defending their team, but others is making their team understand a recent company pivot/shift. A PM without the support of his team is dead. But if he doesn't get along with management, he and his team are also dead.
  - freedomben 5y ago
    Yes I totally agree with you. For clarity when I said "defending their team" I didn't necessarily mean act as a representative to argue their views to management. I've seen many times when what a team wanted would have been really bad for business, which in the end serves nobody. In one case I actually saw a great engineer destroy his company by basically doing what he wanted to do rather than what management wanted. He was so irreplaceable that they had little choice but to allow it. In the end he turned the codebase into a nightmare of half-baked untested crap that not even he wanted to work on it. That has stuck in my mind for years as something I want to avoid.

freedomben 5y ago

There's one thing I think you left out: A great PM will defend their team from management. When management wants to do things like pivot from X to Y, or focus on Z to the neglect of W, a great PM will point out that engineers are not fungible, and that such things can hinder motivation, increase frustration, and lead to lower output. When management decides to do it anyway, and get frustrated with the team's lack of progress (especially on product W which management expected would magically stay up and stable), a great PM (in a professional way) reminds them of the history and that decisions have consequences. Unfortunately a "great PM" will sooner or later have to choose between doing the right thing for their team or the right thing for their career (management does not like to be told no or blamed for any failure). The great PM usually doesn't climb the management chain, so if you are a software engineer with a great PM, please tell them, it may be the only thanks they get.

sophrocyne 5y ago
I agree with you largely, except for one thing - Doing the right thing for their team is the right thing for their career, whether current management sees it or not. There are hundreds of companies who will happily have you be a great PM or leader at their company if your current leadership team is more concerned with promoting sycophants.
hydrakai 5y ago
I would say that the PM needs to do the best for the company, which sometimes is defending their team, but others is making their team understand a recent company pivot/shift. A PM without the support of his team is dead. But if he doesn't get along with management, he and his team are also dead.
- freedomben 5y ago
  Yes I totally agree with you. For clarity when I said "defending their team" I didn't necessarily mean act as a representative to argue their views to management. I've seen many times when what a team wanted would have been really bad for business, which in the end serves nobody. In one case I actually saw a great engineer destroy his company by basically doing what he wanted to do rather than what management wanted. He was so irreplaceable that they had little choice but to allow it. In the end he turned the codebase into a nightmare of half-baked untested crap that not even he wanted to work on it. That has stuck in my mind for years as something I want to avoid.