One of the most complicated and often vexed relationships in the tech business is the one between product managers and engineers. If you ask a product manager what they do, they’ll often say something along the lines of “I [lead, guide, direct, oversee] product development” or “I come up with ideas for products”. A really good one will often put it more like, “I’m a hub for input into the product from all the functional areas, including marketing, sales, and customer service — then I interface with engineers to make sure the right product gets built”. Tension occurs between PM and eng when engineers push back on a product spec or (even worse) an idea that never makes it to a written spec.
Complicating the relationship is that technical product management performs many of the tasks you’d normally think of as “general management” in other fields — driving product, supporting revenue functions, dealing with operational crises — except that they are not empowered with hire-fire authority over the engineers who implement the product nor the operations folks who keep the infrastructure of the company running. In my experience, PM and eng have always been in separate reporting hierarchies up to the highest levels — so if there are serious conflicts of opinion between the two groups, often they cannot be resolved below the SVP or CEO level.
But if you step back from how things are today, one of my big questions is whether this is the correct relationship between PM and eng in a high-innovation company. Should product management propose, and engineering dispose? I’d like to suggest that it should be the other way around: that new product ideas should be extracted from engineers and then validated by product management.
In a company with serious engineering “special sauce”, engineers should be the only ones who have sufficiently deep technical knowledge to suggest major new products — if this is not the case, you have to start wondering how special the sauce really is. Contrary to popular misconceptions, engineers also often have a deep interest in user needs and revenue opportunities. What they don’t have is the time and training to validate their ideas for market opportunity, user impact, and cost-benefit to the company. That, it seems to me, is the proper domain of product: to conduct sufficient research into other groups’ ideas to efficiently validate or disprove them. (Please remember I’m talking ONLY about high-innovation work with significant novel engineering “special sauce”. I am explicity NOT discussing incremental improvements, me-too features, or simply moving a well-understood real-world task online. In those cases, I think it’s possible PM might in fact be closer to user and revenue needs than engineers, and therefore may be able to provide useful guidance.)
And when I say “validate or disprove”, I mean by producing hard data and putting down firm bets — like “this feature will help grow average revenue per user by 2.5% within 3 months, and these are the data to support that thesis”. And this information should be collected in some central location, like a wiki, so the entire company knows exactly what research has already been done. This sounds easy, but I’ve never seen it effectively done by any product management organization. I’ve heard Amazon does something in this direction, and Google certainly has an “eng proposes, PM disposes” model; but too many other companies stick to the model that product management’s deliverable should be novel technology product ideas.