This is always a controversial opinion, at least in some circles, but: I've long said that the PM role was created solely because companies can't find enough good engineering talent.

That isn't to assert that PMs don't do fantastic, necessary work. More-so that there's a more ideal reality where the engineers should be doing that work; the outcomes, in my experience, are better in orgs where engineering is not just influential in, but responsible for, customers, business outcomes, product planning, etc.

This isn't always possible. Most orgs don't resemble Whatsapp; they resemble Google. A hundred product divisions building a thousand different things. Its already difficult to hire engineering talent to fill an org like this, let alone the additional number you'd have to hire in order to account for the fact that a double-digit percentage of an engineer's role should be PM-like stuff.

So, throw away idealism; outsource that part of the engineer role to another specialty which is easier to hire for: PM. Its reasonable.

But the issue has arisen in that industry has forgotten than this was a necessary sacrifice; its not desirable. We've now got university and bootcamp programs dedicated to training for PM roles. Many companies have entrenched the idea that every team/org needs a PM. Tons of people are now adding financial momentum to this idea that their skillset is valuable and necessary; the ship can't be turned so easily.

At the end of the day, this is a disservice to many engineers, as their people, product, and business skills fall out of practice and they're further relegated into code-monkey positions. Its actually a disservice to PMs as well; they could have been trained in engineering and unlocked far more professional mobility. In the worst cases, it leads to PMs resembling the Office Space "what is it, exactly, you do here" guy ("I bring the specs from the client, to the engineers!" "Then, why don't the engineers just talk to the clients?" "Well, they're not people people!" mhm)

> Most orgs don't resemble Whatsapp; they resemble Google.

When they were a startup, Google didn't resemble Google, either.

For large organizations, I'm a fan of the "internal startup" management structure. This just means each product team should be largely self contained, but has the resources of the larger organization to fall back on.

So the leader of each product team can act like a mini-founder, defining and driving the product without being tightly coupled to any other product teams release cycle.

I can attest Product Managers were the downfall of one startup I worked at. The company had dozens of millions in funding and managed to piss it all away with ill-founded escapades driven by a handful of Product Managers. If anything, the Product Managers seemed to be managing their careers, not the product. They babied engineers until most of the engineers stopped caring about the product and just gave up working hard at all. All the brilliant ideas were trite insights you could read on two year old Gartner reports -- "release a cloud version".

CEO and CTO beware, do not let Product Managers happen to your company.

On the flip side, my old PM had an incredibly deep understanding of both the product and the customers buying it (an area in which us SWEs were lacking), in addition to a semi-hands-on understanding of the engineering process too.

He wasn't a professional software engineer, but he took the time to actually learn how to program through some side projects and through this gained a real understanding of what would be trivial for us to implement and what wouldn't.

To top it all off, he had good rapport with the CEO and was adept at managing upwards.

The product wouldn't be half as good as it was if not for him.

Rather than tarring an entire profession with the same brush, I think a much fairer "warning" to founders is to make sure the people you're hiring are competent and that the job they are doing is something that actually adds value to the organisation. PMs, when deployed appropriately, can be worth their weight in gold.

What you describe is the ideal PM. Someone who understands the business and customers and some of the technology. There are two kinds of PMs that are good. The one you describe who understands the business and the former developer who has been with a company many years and has made transition to PM role. However in a lot of companies this is not always the case.

>> adequate business context, a decent design spec, and letting them figure it out.

I wish more PM's thought like you.

Ditto. As an engineer, it feels like product managers often feel a need to keep cranking out new features as a way to justify their seat at the table. I would love to work in an engineering culture which found a way around that problem. If that means the job falls on me instead, so be it.

> If that means the job falls on me instead, so be it.

Precisely this. I don’t know when “engineer” turned into “order taker”. There’s no reason to have a Product Manager define and engineers work. Good engineers are more than capable of defining their own work.

> There’s no reason to have a Product Manager define and engineers work

The PM isn't supposed to define features in isolation, but crystalize them into consensus between engineers and stakeholders the PM is accountable to.

If your PM isn't your peer, the org is setup wrong. Tech leadership should be helping define this, but people don't know what they don't know and so things end up with PM's becoming de-facto "team leads".

They had me at adequate design spec.