Furthermore, PMs are often customer facing. In my experience, they're often the people you bring in when the account manager wants to have roadmap and other relatively technical discussions.

There are degrees of seniority like everywhere else of course. But, in my experience (was a PM for hardware systems for a number of years), they're not typically right-out-of-school.

A good PM knows that all they should own is the definition of "what" should be worked on, but the bad ones seem to gravitate towards the "how" as well. I suspect this has something to do with many PMs transitioning out of engineering roles, but it can be very frustrating to work with a "Product Micromanager".

It depends on the company. For some companies, the PM is responsible for "what" should be built and "how" (functional how) it will behave. Developers then try to implement the PM's "how" and then there's a back and forth between Dev and PM. For example, Dev might say - there's a better way to achieve this but it will change the functional behavior; or if we implement what you want, the page load time will be slow so is it OK if we do it this other way...

At the end of the day, the PM's focus is - how will the average user use this product, what does the average user expect this product to do. That is generally not Dev's focus. Dev's focus is typically - what is the best way to get this done so that application loads quickly, doesn't place undue stress on the server, etc. Sometimes, Dev doesn't pay attention to how the UI looks, they just care that the code runs efficiently

Good PMs, yes. A few I have worked at previous companies barely understood their own products, how to use them, or their customers. They were over glorified email forwarders. Sometimes they could copy-and-paste to Jira, and maybe take a few screenshots.