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

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

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.

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.

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.

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.

Agree on all counts!

Or they are super into weeds polishing stuff in code level but it is never between those two approaches. Also very good pm can be kinda shackled if there is lots of mediocre pms running around.

On the other side I have worked with PM/POs who have no clue and the developers are just telling them: "Oh this is super complicated you would not understand" or "This will take a long time to implement" and its a small feature.

There must be a balance. There must be some basic understanding by the PM/POs. They cant be the person that barley can use a computer.

It also helps to be able to understand the tech enough to know if a certain approach is going to impact other initiatives which are further down the roadmap. One of my favourite questions I've been asked by a PM is "Will any of this work become easier to do if we change the order of these work items?"

I would have thought every manager asks such questions either to himself or to the team quite often.

Not in my experience - juggling priorities is usually difficult enough when you're just trying to manage the C-suite's favourite ideas, or feature requests from the highest revenue customer, etc. Factoring in synergistic engineering efforts is out of reach for a lot of PMs that I've worked with.

Product managers own the "Why?" and the "What?". Project managers own the "When?". Engineering managers own the "Who?". Engineers own the "How?".

When people try treading on other patches, it always ends in disaster. That works both ways: engineers are lousy at the "Why?" and the "What?" because they think too much in terms of "How?"; and yes, product managers need to step away from the "How?" unless it's to clarify the "What?" or the "Why?".

Hard disagree, cross role context is critical for intuition on getting stuff done. A designer with no insight on engineering will create shitty designs that take forever to build, create patterns that arent reusable, etc. Engineers with no insight on product will not be able to balance the debt/product ratio properly. You can say that all of this gets sorted out with proper communication, but knowledge and intuition will always beat leaky bucket cross role comms

"Having context" isn't the same as "having ownership or accountability".

Of course there needs to be communication and context, but when engineers start to try and direct the "what" or the "why", it becomes as absurd as PMs trying to dictate the "how".

If this is the ownership and Engineers ask "How?", there's no one overall to connect the dots. For instance with this ownership dynamic product managers will come up with what and why, and engineers will come up with "how", but no one validates whether the whole thing is worth it considering the technical complexities involved. So scenarios where PMs come up with this and Engineers just ask "How?" there will be initiatives that take a lot of resources, while not giving enough in return.

There's no one to balance the complexity of building this vs the gains achieved.

I think best engineers would be people who also use the product and can give their own insights on this, as well as best PMs are someone who have good knowledge of the technical background and context.

The customer voice - represented by product managers - help join the dots.

It's a team sport, there needs to be communication, but there also needs to be clear areas of ownership.

That only works when the people under them are competent and business interests are reasonably aligned with reward structure.