Company orientation about product manager

Company orientation about product manager
Every business has its own concept regarding the product development process and where PMs fit into it. The three most prevalent forms are shown below, along with their benefits and drawbacks:
Engineering is driven by PM: PMs gather needs, prepare the basic product requirements document, then pass it to engineering to spec out the technical requirements in this “throw it over the wall” technique. This process may be done in a more agile and collaborative manner in today’s firms, but the expectation is that PMs know best what customers want, and engineers is there to help.
Pro: Engineering can concentrate on coding without being distracted, which is ideal for Waterfall development shops with extended product lifecycles.
Con: Engineers sometimes lose sight of the broader picture and lack empathy for clients, resulting in a bad user experience. When technical debt and “plumbing” work must be prioritized over customer requirements, unpleasant conflicts might arise.

Product is driven by engineering. Engineers develop the science & then solutions are tested and front end access points are made (UI, APIs) to tap into this new technology in more technically focused product firms (cloud, big data, networking). There can be a collaborative interaction and feedback loop between customers, PMs, and engineers, but often PMs are servicing engineering in these firms.
Pro: Cutting-edge technology can provide clients with services they didn’t realize they needed. VMware’s VMotion was a good illustration of this. It became a billion-dollar game changer for the firm when an engineer thought it would be fun to do, and a PM found out how to commercialize it.
Con: Engineers pursue the shiny new thing, over-architect the solution, or iterate indefinitely in pursuit of perfection before receiving client input. Customers’ most fundamental requirements are sometimes overlooked when the PM’s feedback on priorities is neglected.
The PM-engineering collaboration: In these cases, PM and engineering have a strong relationship, with mutual discovery, decision-making, and shared accountability. Engineers are present in customer interviews with PMs, and PMs attend in sprint meetings to explain deliverables. The two roles, on the other hand, respect the line where one begins and the other ends. Engineers have empathy for customers’ requirements but leave prioritizing to the PMs, and PMs understand what’s being developed but don’t instruct engineers how to code

Pro: A streamlined prioritization approach that prioritizes technical debt and plumbing projects; enhanced design processes that result in a better user experience; higher-performing teams with greater product velocity, quality, and, in most cases, happier customers.
Con: Breakthrough innovation may not be approved; time-to-market may appear to be slow (though I would argue that what is published is far more aligned with consumer demands and is far more likely to scale).