Qui propono?

December 30, 2004

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.

9 Responses to “Qui propono?”

  1. I manage a product that would not necessarily be described as a “high-innovation” product, and in my case, I often have to serve as the bridge between my user base and engineering. My user base is not computer-technical, but they are technical experts in their fields.

    Even if I did work for a high-innovation company, I would only be comfortable with your suggestion if the engineers were actively engaged with the customer base. If the engineers are isolated from the customers, yet believe that they truly represent the customers, the product could go off on a tangent.

  2. Troutgirl Says:

    So I think part of my issue might be this: why do people generally ASSUME that PMs are closer to the customer than engineers? If the end-user of a product is other engineers, or early-adopter consumers, I don’t think this assumption is at all valid.

    I would definitely agree that products can go off track if whoever is responsible for product ideas loses touch with the needs of customers. But that can happen just as easily with product management as anyone else if they are not required to validate or disprove their ideas. The solution is the same whether initial idea-generation comes from eng or from someone else: use product management to validate or disprove the value of all product ideas in a rigorous way.

  3. mike Says:

    In traditional engineering fields (chemical, mechanical, etc.) you can only become a PM after having *been* an engineer. I think that the software industry is rife with a major problem that just exacerbates the PM/engineering battle. All too often, PM folks have more of a bizdev background without really being in touch with the breaking/bleeding edge of what is possible from an engineering standpoint.

    But also, engineers still continue to assume a prima donna attitude that in alot of cases only reinforces the tantrum-throwing condescending stereotype that software engineering has been known for.
    From my experience, both PM and engineering (in those cases where they battle) are generally too involved with the me-me-me attitude that prevents them from working well together. Good PMs make effort to understand engineering’s concerns about specs/products, and good engineers attempt to understand where PMs are coming from, without taking the nonconstructive role of rigid constant second-guesser.

  4. Troutgirl Says:

    Mike, I think you definitely offer a pretty accurate assessment of the fatal flaws on both sides: bad PM can just not be knowledgeable enough, and bad engineers can be prone to hissy-fits and other unprofessional forms of expression. I also think you’re offering a good _description_ of the behavior of good PMs and engineers. But my question is really more about pragmatic steps that can be taken to avoid the former and work toward the latter. I’m not a big fan of exhortation as a management technique, especially being exhorted to understand the other person’s point of view — my experience has been that the worst offenders invariably congratulate themselves for _already_ having considered the other person’s point of view.

    Maybe one reason engineers often come off as nonconstructive second-guessers is that the “PM proposes, eng disposes” model I’m critiquing often leaves engineers feeling helpless in the face of bad product decisions that were made without input from them? Combine that frustration with social deficits like an inability to clearly communicate without causing offense — and you have a recipe for exactly the kind of problem you point out. So… why is “PM proposes, eng disposes” still the norm?

  5. mike Says:

    I’m not sure that I agree that that model is really the norm, actually in such a binary way. Most of the more successful companies don’t have such a clear-cut model where PMs dictate features backed up with market stats and engineers are to excute those grand plans.
    While I don’t think that it’s the norm, I do agree that it happens in many companies, and at least from my experience, it’s because the organization isn’t trying hard enough to integrate the two. This is somewhat related to what I tried to get at earlier — that PMs (and the upper management, as well) don’t really understand the possibilities when engineers are let in on the loop early and have a real input into the process. That said, it should be *input* that engineering should provide, and not dictation of features. Good PM staff are not market stats/focus group bean counters, and good engineering groups should not be relied upon for dictating features because they are percieved to be somehow magically “closer” to the product.

    Anyway, I think we agree on that, but I’m not sure I agree that it’s the norm. At least not in software companies. My suspicion is that that model probably exists in the web/online world, maybe because the industry is viewed as more of a medium, like TV, film, and radio, and not as real software.

  6. Timboy Says:

    Troutgirl’s insightful post about the relationship between engineering and product management reminded me of a similar puzzlement I had a while back about PM, XP, and about we

  7. Timboy Says:

    An amusing sidelight of the Tour de France is the one coach who seems to spend the entire race in a car right next to his prize rider, with the window open, yelling this over and over again: “Venga venga venga!!! Venga venga venga venga!!!” I think it’

  8. engineer Says:

    I think the correct relationship is to fire all the PMs. If the engineers can’t get close to both the customer needs and the product needs you’re going to lose anyway. Don’t say “but the engineers don’t have time etc”. If the people making most of the detailed design decisions on your product don’t understand the market/don’t care, then you are in trouble.

  9. joanna Says:

    Troutgirl: where you ever fired/repriminanded for having a blog from an employer? And if so, why? What did the employer say?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: