One of the deliberate outcomes of putting a product lead in place is to train the engineer to fully understand the product. For any vertical market or B2B product the chance of hiring engineers who understand the business domain is virtually zero so they need clear guidance to build what customers want.
Having worked in both situations (product person vs no product person), this reads like fiction to me.
Most PMs I worked were nowhere near being able to guide anyone, especially on B2B domains. I had to train a lot of them just to do basic follow up stuff, and honestly the vast majority was below expectation, and mostly just receiving requests from customers and giving opinions on designs.
And even in the best cases, an understanding of the product filtered by a product lead was nowhere near as good as actually having engineers who care, dogfood, talk with customers, read feedback, design solutions and verify them with end users.
IMO the concept of product leads, PMs, etc, is ok, but the implementation is always lacking. It's always a "creative type" that is stifling creativity of engineers while not really adding a lot of value.
I much prefer the concept of "Product Owner" of Scrum: someone that brings the tasks but isn't really dictating taste (except via feedback) or removing the creative part of engineering work.
I completely disagree, but your experience may vary. I am not trying to take away from that.
I am merely saying that maybe there should be a stronger discussion than just dismissing engineers as mere "thing-doers". I also accept that there are many people here who are exactly that, and I and they should find it shameful.
We can't control that, but maybe we should try harder to do instead of being lazy and assuming market forces are the boss... maybe we are the boss (we are).
I have worked as an engineer on a product that didn't have a dedicated product lead and it was extremely hard to deliver new features without understanding the complex business side of things. Working without a dedicated product person to explain the business sounds hell to me.
I'm not saying every engineer has ambitions to be in management, but your quote is just as likely someone who has become fed up with sloppy management and deliberate gatekeeping.
In the days of the rampant layoff culture, where your competence, experience, or output quality no longer matters because someone sorted an Excel spreadsheet in a particular way and had you at the bottom 10% — it should be a miracle when companies are getting this much.
Usually what you end up with is a "three blind men and the elephant" situation; the product is simply too large for any one person to "fully" understand. Humans have a finite context window too.
So ending up with a product manager who is standing far enough away to see the whole elephant, but not in detail, while the engineers have detailed views of their part of the product but not the whole thing, is a reasonable position.
> "the product is simply too large for any one person to "fully" understand. Humans have a finite context window too."
Not personal towards you, but we're gonna wheel that one out again? Bullshit.
We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
> We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
Always was it so; the play remains the same, only the names are changed.
But that doesn't challenge the validity of what pjc50 wrote: literally nobody has time to count the transistors on a modern CPU (exceeds maximum human heartbeats), nor even the much easier task of skim the lines of code in say Windows 10 and the bundled drivers and apps.
We have division of labour because we need it, we have abstractions because we need them.