|
> The past two years created a new type of hype: PMs. Until the Tech Giants (eg: Google, Meta, etc) made PMs the ‘new normal’ of how to get any product functionally built and delivered, down to the tiniest button, startups used to do just fine with no PMs. Chances are very high you could do with less (no?) PMs. Also an excellent forcing device to kill some of your internal bureaucracy. I think the PM fad has been around much longer, to the point one almost forgets how to build products without PMs. But from my experience, I find that the prevalence and empowerment of PMs is largely turning Devs into highly-paid code monkeys, as opposed to the highly-paid and empowered value builders that they should be. Much of the busy work that many PMs are doing can be replaced with a bit of Agile/Scrum training of a few devs per team. At the same time, I would say that having a product owner who develops a deep understanding of the domain, actively talks to customers, and steers the vision and direction is immensely valuable. But I hardly see any of my PMs doing it. Anyway, I am seeing a lot of negative sentiment towards the prevalence of PMs these days, which I mostly share. Would love to hear any counter-thoughts or corroborations of this. Are PMs necessary? How should they be utilized? |
The important point is that someone is thinking about product vision and how you are actually going to sell/deploy to market your stuff.
If engineers or eng managers were doing that consistently, the PM role would not need to exist.
The reality is that most of the old-school engineers used to do this. As the "aperture" for engineers widened, the ratio of engineers who can actually apply this relevance/business lens to their work has decreased significantly so you need someone whose job is to be accountable for the vision and actual ability to turn code output into dollars.