4 ms·

The thing about PMs. They fulfill a very specific need, and that need is hard to quantify, but I can tell you that without a good PM everything falls apart. He

The thing about PMs. They fulfill a very specific need, and that need is hard to quantify, but I can tell you that without a good PM everything falls apart. Here's a list of what they tend to do: - gather information from users on what is/isn't working for them - gather information from executives about what needs to be done to keep the company working - gather information from industry leaders who may or may not be part of the company about where the industry is going - work with design - take all 4 previous points and distill them into what actually needs to be built for a needed feature - work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take - work with engineers / higher ups to remove features that take time but don't add as much value. - work with engineers to ensure estimation and team velocity is more or less predictable I've probably already described a 1 and 1/2 jobs. Now if you take product away, each of the above gets distributed among the engineering team, and not everyone in that team is good at it. And even if they get to a good homeostasis, one person leaves and now there's a non-obvious gap that we're not interviewing for.

Belopolye 3y ago
Advocating funding for a project budget and trying to involve stakeholders as well.
- Justsignedup 3y ago
  omg yes!!!! this too.
doktrin 3y ago
In recent experience the PMs I have worked with have primarily concerned themselves with the desires of executives. Literally all the other responsibilities you mentioned were handled by others.
- liquidpele 3y ago
  This… and trying to squeeze dates out of everyone to fill boxes in a document.
- Justsignedup 3y ago
  Yes, and this is exactly when you have ineffective PMs, and senior leadership isn't paying attention. With a good product and design team, I have been part of engineering teams that have 5 engineers than can do the work of 20, without working overtime, consistently deliver, and rarely, have to implement anything twice. The difference between effective product and not is absolutely night and day. The best analogy is driving a modern car, vs driving a modern car without vehicle stability, anti-skid, power steering, automatic transmission, or AC. Sure you absolutely can drive it, but after a while you will need way more breaks than those who have all the nice features, and won't roll over in bad situations.
- johhns4 3y ago
  Yes. But this is because we have organizations where people survive by placating the higher-ups instead of producing value to the product and their team. Hence, these people survive. It's human nature to find the best way to survive so we can't really blame these PMs for doing what they need to keep their job. Suck up to the people that will ultimately give them their paycheck. The issue isn't the PM or shitty employees that aren't producing actual value, the issue is with the ego of the higher ups that rather keep people that agree with them on all things than have people who will constantly challenge them. I have seen many CxOs (that aren't founders) who are very good at befriending the founders and thus they are more prone to survive. They are not necessarily doing anything useful to move the needle though, so this gives people the impression that the best thing you can do to survive is just be liked by the higher ups. Telling founders that they are wrong on a day to day basis because you work so closely with users and the engineering team, is not a good way to keep your job. If you are very smart maybe you can navigate this in a way that works, for awhile. If my point is muddled, I'm saying that if you have a shitty PM it's because of the organization that employs people and keeps people based on the wrong criteria. Good leaders aren't threatened by getting challenged or feel the need to constantly get their egos validated. Or maybe I'm wrong there too and it's just human nature to want to keep people that you always get along with.
spamizbad 3y ago
I couldn’t agree more. I absolutely do not want to be without a functional product org. I suspect a lot of teams have gotten burned from dysfunctional product orgs that seem disconnected (or disinterested) on the more customer/industry/organization side and instead burn through tons of meetings iterating on mock-ups, micromanaging designers (causing good ones to quit) and tying up engineers in product meetings they do not need to be in.
Zigurd 3y ago
I take issue with excellent product management being hard to quantify. There is a creative aspect, but one indicator that's easy to examine is whether they understand strategic competitive analysis, not just point-by-point features bingo. Secondly, have they got the stature in the org to communicate about a project to senior management. If they have got both those attributes, you are in good shape.
Nathanba 3y ago
> gather information from users on what is/isn't working for them trivial and part of analytics and bug reporting that anyone can have a look at and it's the same job that the QA team does too which you are in contact with as a programmer anyway > gather information from executives about what needs to be done to keep the company working the boss tells you what to implement whether there is a PM in the middle or not > gather information from industry leaders who may or may not be part of the company about where the industry is going reading the news? I think everyone does it enough, it's not a hard job > work with design programmers are perfectly able to talk to designers, the issue is solely around who gets to make the decision. And I happen to believe that programmers should always be leading which is probably controversial and its own blog post but shortly summarized the reality is that programmers are at the intersection of the actual implementation, the design and all the decisions. They are in the perfect spot to make the call which features to do and which not to do. > take all 4 previous points and distill them into what actually needs to be built for a needed feature that's literally the job of programmers, to figure out how to implement something > work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take once again, engineering is at the core of this and can do it on their own > work with engineers to ensure estimation and team velocity is more or less predictable this usually means that they want steady output on assigned issues and bugs which makes the job of engineers into a soulless daily issue list grind. > Now if you take product away, each of the above gets distributed among the engineering team Precisely, it lands there because it should land there at its natural intersection. The issue is that the engineers aren't given enough rights and decision making authority to make the calls so it becomes an awkward dance where you constantly have to ask for permission to do things because if you ever do something that the leadership doesn't like, you do get bad feedback. As Steve Jobs famously said and I'm paraphrasing: Once the engineers who actually make the products stop being at the center and the salespeople and managers take over it all becomes bad. It really doesn't matter how good a manager is, he will never be better than the guy who actually built the thing. The reality is that a good PM would be advocating for engineers to be able to work on whatever things they want to work on, which is what never happens of course because that wouldn't help them. You can just look around in this thread: The PMs here all wanted to drive product direction, that's why they got into the job. Guess what every engineer went into the job for: They want to drive product direction too and they actually build the product. Who became an electrical engineer or programmer or game developer only to be told by some PM what to build? The PM is often not even really supposed to be his boss and yet it ends up being that way for absurd reasons. For utterly absurd reasons the PMs are given the ability to make product decisions even though they dont build anything and they aren't leadership. I've had PMs that were engaged, cared about making a product that makes sense etc. And yet ultimately the job is mostly around telling the actual implementors what to do while pretending that they aren't the boss of them but really, that's how it is because they talk to the leadership because what else would they be doing, of course half their job is to make sure that leadership does whatever the PM wants and they are generously given an entire job title just to talk to leadership and customers (which every engineer has to do too of course but with less time)
bazmattaz 3y ago
I’m a PM and this is spot on. The PM is not some sort of authoritarian decision maker that tells the team what to build (like this article seems to say), the PM should be a close ally of the team. He/she will work closely with their team to define the roadmap and prioritise work that will have the biggest impact for customers and the business. When The PM is doing a great job, it should be so obvious for the engineers what problems they need to solve next and understand why they need to solve it.

Belopolye 3y ago

Advocating funding for a project budget and trying to involve stakeholders as well.

Justsignedup 3y ago
omg yes!!!! this too.

doktrin 3y ago

In recent experience the PMs I have worked with have primarily concerned themselves with the desires of executives. Literally all the other responsibilities you mentioned were handled by others.

liquidpele 3y ago
This… and trying to squeeze dates out of everyone to fill boxes in a document.
Justsignedup 3y ago
Yes, and this is exactly when you have ineffective PMs, and senior leadership isn't paying attention. With a good product and design team, I have been part of engineering teams that have 5 engineers than can do the work of 20, without working overtime, consistently deliver, and rarely, have to implement anything twice. The difference between effective product and not is absolutely night and day. The best analogy is driving a modern car, vs driving a modern car without vehicle stability, anti-skid, power steering, automatic transmission, or AC. Sure you absolutely can drive it, but after a while you will need way more breaks than those who have all the nice features, and won't roll over in bad situations.
johhns4 3y ago
Yes. But this is because we have organizations where people survive by placating the higher-ups instead of producing value to the product and their team. Hence, these people survive. It's human nature to find the best way to survive so we can't really blame these PMs for doing what they need to keep their job. Suck up to the people that will ultimately give them their paycheck. The issue isn't the PM or shitty employees that aren't producing actual value, the issue is with the ego of the higher ups that rather keep people that agree with them on all things than have people who will constantly challenge them. I have seen many CxOs (that aren't founders) who are very good at befriending the founders and thus they are more prone to survive. They are not necessarily doing anything useful to move the needle though, so this gives people the impression that the best thing you can do to survive is just be liked by the higher ups. Telling founders that they are wrong on a day to day basis because you work so closely with users and the engineering team, is not a good way to keep your job. If you are very smart maybe you can navigate this in a way that works, for awhile. If my point is muddled, I'm saying that if you have a shitty PM it's because of the organization that employs people and keeps people based on the wrong criteria. Good leaders aren't threatened by getting challenged or feel the need to constantly get their egos validated. Or maybe I'm wrong there too and it's just human nature to want to keep people that you always get along with.

spamizbad 3y ago

I couldn’t agree more. I absolutely do not want to be without a functional product org. I suspect a lot of teams have gotten burned from dysfunctional product orgs that seem disconnected (or disinterested) on the more customer/industry/organization side and instead burn through tons of meetings iterating on mock-ups, micromanaging designers (causing good ones to quit) and tying up engineers in product meetings they do not need to be in.

Zigurd 3y ago

I take issue with excellent product management being hard to quantify. There is a creative aspect, but one indicator that's easy to examine is whether they understand strategic competitive analysis, not just point-by-point features bingo. Secondly, have they got the stature in the org to communicate about a project to senior management. If they have got both those attributes, you are in good shape.

Nathanba 3y ago

> gather information from users on what is/isn't working for them trivial and part of analytics and bug reporting that anyone can have a look at and it's the same job that the QA team does too which you are in contact with as a programmer anyway > gather information from executives about what needs to be done to keep the company working the boss tells you what to implement whether there is a PM in the middle or not > gather information from industry leaders who may or may not be part of the company about where the industry is going reading the news? I think everyone does it enough, it's not a hard job > work with design programmers are perfectly able to talk to designers, the issue is solely around who gets to make the decision. And I happen to believe that programmers should always be leading which is probably controversial and its own blog post but shortly summarized the reality is that programmers are at the intersection of the actual implementation, the design and all the decisions. They are in the perfect spot to make the call which features to do and which not to do. > take all 4 previous points and distill them into what actually needs to be built for a needed feature that's literally the job of programmers, to figure out how to implement something > work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take once again, engineering is at the core of this and can do it on their own > work with engineers to ensure estimation and team velocity is more or less predictable this usually means that they want steady output on assigned issues and bugs which makes the job of engineers into a soulless daily issue list grind. > Now if you take product away, each of the above gets distributed among the engineering team Precisely, it lands there because it should land there at its natural intersection. The issue is that the engineers aren't given enough rights and decision making authority to make the calls so it becomes an awkward dance where you constantly have to ask for permission to do things because if you ever do something that the leadership doesn't like, you do get bad feedback. As Steve Jobs famously said and I'm paraphrasing: Once the engineers who actually make the products stop being at the center and the salespeople and managers take over it all becomes bad. It really doesn't matter how good a manager is, he will never be better than the guy who actually built the thing. The reality is that a good PM would be advocating for engineers to be able to work on whatever things they want to work on, which is what never happens of course because that wouldn't help them. You can just look around in this thread: The PMs here all wanted to drive product direction, that's why they got into the job. Guess what every engineer went into the job for: They want to drive product direction too and they actually build the product. Who became an electrical engineer or programmer or game developer only to be told by some PM what to build? The PM is often not even really supposed to be his boss and yet it ends up being that way for absurd reasons. For utterly absurd reasons the PMs are given the ability to make product decisions even though they dont build anything and they aren't leadership. I've had PMs that were engaged, cared about making a product that makes sense etc. And yet ultimately the job is mostly around telling the actual implementors what to do while pretending that they aren't the boss of them but really, that's how it is because they talk to the leadership because what else would they be doing, of course half their job is to make sure that leadership does whatever the PM wants and they are generously given an entire job title just to talk to leadership and customers (which every engineer has to do too of course but with less time)

bazmattaz 3y ago

I’m a PM and this is spot on. The PM is not some sort of authoritarian decision maker that tells the team what to build (like this article seems to say), the PM should be a close ally of the team. He/she will work closely with their team to define the roadmap and prioritise work that will have the biggest impact for customers and the business. When The PM is doing a great job, it should be so obvious for the engineers what problems they need to solve next and understand why they need to solve it.