Firstly, a company has to figure out their mindset, is it that of Product company or an IT company (IT as an enabler etc.)
Marty Cagan has a fantastic article on this http://www.svpg.com/product-vs-it-mindset
I think the dysfunction starts with defining the role in terms of Responsibility for everything, that leads to others perceiving they are NOT responsible for the product. Another dysfunction is how people define "product" does it represent the codebase (engineering thought) or the next quarter revenues (sales thought). Engineering starts losing ownership and soon you have an army of PMs doing all sorts of secretarial work for engineers who are not motivated.
At the heart of it, PMs need to integrate different perspectives (business, UI, technical) sufficiently to discover the right product. They should be spending most of their time in product discovery, talking to customers, talking to engineers and writing quality documentation on what to build and why.
This tends to sound wishy washy compared to such "hard" metrics like GMV and technical stuff like "we are replacing CouchDB with MongoDB". So inexperienced PMs tend to want to get respect by trying to become solution architects for engineering and project managers for business to respond to do the treadmill of "reporting" to sr. management. I've also seen PMs doing all the testing because the QA team doesn't really "own" the product, so if it fails, it's the PMs fault.
I think it's best to start by not having a PM function till the communication gap between what is needed to be built, what is intended to be built and what IS built is so large that you need to have someone who is a bit of jack of all trades and can do product discovery at a granular level.
Common pitfalls are assigning PMs by "systems" not customer experiences, hiring too many inexperienced PMs, never providing any training on stuff like how to write user stories.