What about spec the "why", then engage with the team to figure out the "what", then let the team figure out the "how" by themselves. Believe it or not, the PM is not the only one with problem-solving skills on the team to tackle the mapping between "why" into "what".
Sometimes this is true. It depends on the developers.
Sometimes the developers don't have product skills but know they don't have product skills. This is also fine.
Sometimes the developers think they have product skills when they don't, and this is always a complete disaster.
I can't tell what situation the company described in the article is in. Perhaps the product manager is incompetent (there's lots of incompetent product managers out there), and the developers are correcting for this. Perhaps the developers have good product sense that the product manager is underutilizing.
But if the developers don't have the product skills they need, skills you get by spending lots and lots of time talking with customers instead of (or in addition to) writing code, no amount of process tweaking is going to fix the real problem - individuals assuming that their technical skill translates into product skills, and insisting on also doing something they're not good at.
I've often wondered why the subset of developers who lack product skills and/or the relevant domain knowledge frequently insist on getting involved with product anyway. After all, the head of human resources rarely insists on committing code.
I'm assuming this is for building a product, in which case the "why" is specced by market demand, and the "what" is little more than a goal of the product/feature - such as "product to allow consumers to record their taxes". The "how" is obviously more involved and includes things such as technology choices and specs on what the customer will interact with and how data will be stored.
The "what" would also often include essential features, such as "visual graphs or charts over time". These features would grow (or shrink) over time based on market feedback and testing.
You rarely want your programmers/designers/QA defining the "why" behind your product. If it's a startup, you're generally creating your business because of the "why" - you don't start a company and then use the company to find a "why". If it's an established company creating a new product, you'd have had market research and similar groups set up before the product even started to identify the "why".