> 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 s

> 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)