>Their days are filled with doing work that will not move the needle on any metric that matters to the company
This, 100%. I think this simple observation reverberates across the entire software engineering field and at many (most?) non-FAANG companies as well.
I am not confident there is a real solution to the problem of making sure people only work on things that matter. Medium to small organizations seem to struggle with having management even understand what "good" product looks like or how to optimize for that outcome.
Yeah, I think it's massively under-discussed that product management quality across the industry is generally very poor.
There are multiple manifestations of this but the main factors IMO are: how involved is management in the product? How good is your product definition process and talent?
For big companies the problem tends to be more the former. Product management talent tends to be solid, but upper management is checked out of the process and instead overly focused on non-product areas of the company. Product management functions (PMs + engineers) tend to be flying alone with low external guidance.
For small companies the problem tends to be the latter. Product management is deeply enmeshed with upper management (because what else would upper management be doing at that scale?) but they are bad at it.
Both result in shipping the wrong product. For startups shipping the wrong product is deadly, but for large profitable companies they can keep shipping bad product for years. IMO this is where Google is at - they fundamentally do not have the institutional capacity to ship great product.
My impression (which is a few years old now since I left Goog) is that management understands the problem exists, but seem to believe that they can fix it by iterating on the product management process, but in a way that does not require SVPs and VPs to directly engage with product. I fundamentally disagree with this premise - it is not possible to ship product in a coherent manner with a surface area this large unless the most senior levels of management directly engage with product management.
And ultimately poor product definition and prioritization is an order of magnitude greater source of low labor productivity than any kind of individual-level slackage.
FWIW, I don't think this is the case at Apple. I sit in with the product manager as they get grilled by VPs and SVPs. They get damned hard questions - mainly the short ones ("why", "what if" and "how", and to a lesser extent "when" and who") and part of my job there is to provide data for their cover. I've given demos to SVPs before, and it's not a pleasant experience, I'm very happy to leave it to the PM.
Sometimes my job is to gently point out to an SVP that his/her assumptions are wrong, but most of the time I stay out of the way. The PM puts together the slide-deck (usually with help from engineering management) and the PM presents it, though (s)he can call on others for expertise for specific sections.
PM's have to be very good at defending the direction they want to take the company in, and the top brass are scarily good at coming up with the hard questions, even when those questions are very domain-specific.
In any event, (S)VPs at Apple are very invested in what the company does, when it will happen, what the consequences are, and why we're doing X. Directors and Managers are the ones responsible for execution, and the concept of a DRI is very very important in Apple culture.
Fully agreed re: Apple from first-hand knowledge, and IMO this is a large part of the company's "secret sauce".
Which is both a high compliment to Apple and a damning indictment of other companies like Google: the secret sauce is having your senior leadership and executives live and breathe product! Huh. It seems like an obvious observation, but clearly not obvious enough because most large tech cos do not do this!
Your senior leadership should have encyclopedic knowledge about the product and its roadmap. They should be able to describe, in detail, the major features that will be shipping and why the company is pursuing them. They should also relentlessly question product proposals because most product proposals are absolutely not good enough at inception to be worth building, and refuse to greenlight projects until they pass muster.
This is how you ship good products in big companies.
[edit] Another salient point worth bringing up: there is a deeply-held belief at Google (and from what I hear, also at FB) that product viability cannot be tested except with the public via rigorous A/B testing. The result of this poorly substantiated belief is that trying new ideas requires building out (at minimum) a full MVP. The execution costs for trying new ideas is extraordinarily high, and more than that requires commitments to the public.
This is distinctly unlike more functional product orgs where ideas can be validated in a number of ways short of building the actual thing (user research, focus groups, simplified prototypes tested with selected members of the public under observation, etc.) and are much faster and much cheaper. You can get a lot of understanding of what products and features work without committing to a full buildout.
Yep: Ken Kocienda, in "Creative Selection", his book about Apple's design process, makes fun of how the "others" ran 100s of A/B tests to determine the shade of blue for some interface, and other such metrics obsessions.
Apple's different philosophy is admirable: hire people with "taste".
As Fred Brooks said, "great design comes from great designers" (though by "design" he meant "engineering" but still) [1]
> Medium to small organizations seem to struggle with having management even understand what "good" product looks like
The ones that struggle are the ones that die in a year or two, thus learning the lesson the hard way. Google on the other hand has unlimited money, so people just get moved elsewhere and don't learn from failure.
Founder led companies or where the staff includes some product visionary seems to solve that. It’s not common though at all and not long lasting. In my experience when the non technical or accountant types inevitably start calling the shots effort can get grossly misallocated but utilisation will be high.
This, 100%. I think this simple observation reverberates across the entire software engineering field and at many (most?) non-FAANG companies as well.
I am not confident there is a real solution to the problem of making sure people only work on things that matter. Medium to small organizations seem to struggle with having management even understand what "good" product looks like or how to optimize for that outcome.