My experience is completely the opposite. PMs that don't understand the how, that is, they don't know how their product works, are the worst.
Best PMs that I worked with had a technical background.
Best PMs I worked with just figured out what users wanted and organized the team to build it through good communication. That's it.
Sometimes the technical PMs can be an issue because they care too much about the how and not enough of the why and what.
If your product is selling devtools to developers, then yes, it helps to have a technical PM. Case by case.
You want a PM that knows the product (really) well and brings new work to the developers in the form of well documented problems, not solutions.
You don’t want your PM to get involved in the technical details.
> not solutions
Often yes, solutions. When you're still in the "what are we building" phase you want a good PM deeply involved in the process. I think you may have implied that, but solution creation happens before code gets written.
You also sometimes want a PM to get involved in technical tradeoffs when they impact the user experience. I've found that this happens more often with a technical product (API capability or SDK interface) than a UI screen, but it comes up. When your PM is the expert in your userbase and how they expect to use something, they need to be involved a lot.
It may include knowing technical weaknesses and strengths in the energineering teams abilities and their plattforms abilities and weighing that in for planning and priorities. In reality development in product that are over the teams abilities may lead to a real mess.