[gabrieledarrigo]

> As a developer, and a development manager, the best product managers I've worked with rarely got involved in the "how".

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.

[aurareturn]

>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.

[mewpmewp2]

This would also depend really on how technical the product is, but if a product is technical and PMs don't have enough technical background they won't be able to understand nuance of what customers wanted and what is actually possible to do.

[nip]

I believe OP meant « implementation » with « how ».

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.

[phillipcarter]

Careful here!

> 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.

[nip]

Agree on all counts!

[havkom]

Best PMs know both the what, why and how and tries to bridge all that.

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.