Simple solution: Small teams that own what they're working on, soup to nuts. This probably means 1-2 devs on a team, a designer spread across 1-2 teams (depending on the scope of the team), and the PM helping all of them, where necessary, but not giving them exact specs of what to build. Product manager in an agile-ish organization is an extremely poorly named title, as their primary function is not to manage, but to communicate and facilitate things that are otherwise difficult or inefficient for designers and engineers to get at.
If the PM is giving the designers and devs exact specs on the product to build, he or she is failing in their role. The PM should be focusing on communicating succinctly the business problems to solve, and the software solutions evolve naturally from the small teams. The product manager, as a member of a team that builds software, should be expected to have some insight as to the general design of the software (maybe in the form of wireframes or whatever). But providing exact specs for what to build is a battle-tested Recipe for Failure™.
This may work with top x% of programmers/designers but the fact remains, majority of the programmers and designers are not equipped to take a business problem and come up with a solution. Their core job never was to think deeply about a problem in a niche domain. Now I understand at startups it is common for multiple of these roles to fall under one person but I am yet to see that system scale, especially at an enterprise level where the customer may have very peculiar requirements the product manager can really help think through before it even goes to the devs/designers.
I'm not convinced it's more likely that the PM can think through the issues better than anyone else on the team.
In any decision, in any industry, in any profession, the only way to make a good decision is to understand the cost and benefit at the same time.
IMO, almost all corporate software disfunction comes from that failure. The decider understands the cost, but not the benefit, or the benefit, but not the cost. Sales teams that don't understand the product, developers that never talk to customers, managers that don't understand how to code are all trivial examples of this.
If the PM designs the feature incorrectly without understanding how to code or understanding the current codebase, there could easily be a 10x cost difference, in terms of implementation and QA. If the developer writes a feature that no customer will accept, all implementation time is wasted.
How to fix that failure depends on the relative costs for the PM to learn the codebase, vs. the developer learning the business domain. Though both are nearly essential to a successful company.
The same terminology would no make sense to the client and a client's terminology("I just want feature x") leaves out bunch of implementation details which a good product person should be able to clarify and fill in instead of leaving it up to the developer to guess.
The startup world is certainly leading the charge in this right now, though I think it's often mischaracterized as a resource constraint problem, one that will presumably be solved down the road by hiring a proper product manager when the company needs to "scale". Training all employees to think strategically about business and product is a universally good thing, but especially for those building the products, especially when the software is the product.
As far as how well the system "scales", I suppose it depends on your definition of scale ;) Facebook seems to be doing pretty well with some version of this approach, and I think they're at about 3-4k employees, at least half of those are technical afaik.
I'm a product designer, and I do see think deeply about a business problem and finding a solution as a huge part of my job. If not to find solutions to problems, what are the job of a product designer?
Forcing the PM to create requirements based on things she doesn't understand well is a surefire recipe for failure, as you said.