Your architect, principal engineer etc. (one spot-on job title I've seen is "product architect"), who in turn talks to the senior management.
Basically an engineer with a talent and experience for building products rather than a manager with superficial understanding of engineering. I think the most ambitious teams have someone like this on top - or at least around
I've had your type of product owner, but I've also had a product owner that was an ex-staff engineer. Companies should hire ex-engineer product owners, not strictly people-manager product owners.
Technical background doesn't always help in my experience - it's just a different role. Creating great product requires deep technical expertise to understand where the cutting edge is, vision to understand how it can be expanded and business expertise to understand what makes sense economically. It's just not a manager's job, you can't perform it by collecting customer requirements in a spreadsheet.
If you have 10PMs and 90 devs today, and go to 8 "hybrid" PMs + 2 specialized PMs, you're probably still creating backlog items faster than that team can close them.
So you end up with some choices:
* do you move at the same speed, with fewer people?
* do you try to move faster, with less of a reduction in people? this could be trickier than it sounds because if the frequency of changes increases the frequency of unintended consequences likely does too, so your team will have to spend time reacting to that
I think the companies that win will be the second batch. It's what happens today, basically, but today you have to convince VCs or the public market to give you a bunch of more money to hire to 10x the team size. Getting a (one-off?) chance to do that through tooling improvements is a big gift, wasting it on reducing costs instead of increasing growth could be risky.
