Why Doesn’t Engineering report to Product Management (redux)

Not only did  original my post entitled Why doesn’t Engineering report into Product Management generate a lot of comments, but it was by far the most read piece on the blog last week. Tom Grant at Forrester also referenced my article in his post entitled The world turned upside down.

The question of org structures came to mind as I started reviewing some of the early submissions in the survey on Product Management problems. A number of people indicated that there were problems with Engineering and their attitude towards Product Management. I’m pretty sure every technology product manager has experienced some of that in their careers.

While some of those problems may be due to poor requirements and work from Product Management, a lot of the dysfunction between the two groups comes simply from the organizational and power structures in place in companies and the impact it has on the ability of Product Managers to do their jobs.

How the problem starts

Engineering is usually a large organization. In many software companies, particularly smaller ones, it can be 25% or more of the overall headcount.

On the other hand, Product Management is usually a very small organization, usually 1/10th the size of the Engineering organization, or even smaller.

Typically, given how technology companies originate, there is an engineering team from day 1, whereas formal product management is not added until some later stage. I wrote the following in this post:

Typically a product manager is hired once the founder or CTO or chief architect or other corporate thought leader reaches the limit of their abilities in defining the product, or things become so messed up in the company with a product or technology strategy, a member of the Board of Directors tells the CEO to get a Product Manager.

When this PM is hired, they will usually report up into Marketing or Engineering, or in some cases directly to the CEO.  And the job of the PM in that situation starts with doing whatever the thought leader hands off to the PM.  i.e. a “fill the gap” role as opposed to a clear business focused role centered on product strategy and market success.

From this point on, the Product Manager is playing catch up. The Engineering team has a lot of domain knowledge and of course technical knowledge that the PM can only attain over time. Additionally, whereas the thought leader had positional power (being a founder or other Sr. executive in the company) and associated authority, the Product Manager — who is unlikely a VP — has neither the positional authority, and rarely has the credibility with the engineering team to “tell them what they should build”.

Groundhog Day at every company

This process is replayed in many companies of all different sizes. Compounding this problem is the fact that Product Management teams are almost always understaffed by a significant factor. I wrote about this quite a while ago in an article called You can never have too many Product Managers.

The result of the understaffing is a lack of focus by Product Management on the upfront research and analysis, resulting in poor requirements and market understanding.

This in turn further compounds the problems faced by Product Managers by reducing their credibilty with others in the company, and in particular Engineering. It becomes a vicious circle. And from here, the only way to success is the “heroics”, and “the passion” and the “success at all costs” attitudes we feel all Product Managers need.

Where is discussion of Product Management organization, with specialization of roles, of focus and varied skill sets? Every other department works that way, but for some reason, not only is Product Management typically a small understaffed organization, but it is usually one of the flattest organizations in the company.

Time to change from the old way of doing things

One of the comments on the original post included the following:

The VP of Dev has plenty of infrastructure and people to manage. He is a busy guy. He is not focused on customer needs, and he shouldn’t be. If he was, he wouldn’t be able to fill those needs.

Here’s a simple solution to the VP’s problems. Let IT manage the infrastructure and have the VP and the rest of the Engineering organziation report into a business focused EVP of Products. Really. Why not? Managing infrastructure should not be a distraction for any executive. The IT department should provide that as a service within the company.

As for plenty of people to manage, well every VP has that issue. The main issue is the lack of business alignment between Engineering and business as a whole. The VP of Eng doesn’t need to be customer focused or even technology focused, but he/she absolutely needs to be business focused.

As I said in a reply to one of the original comments.

Some Engineering VPs “get it” and understand that the pool of resources they manage must be flexible and be utilized to align with business objectives. But many don’t get it, and you find engineering teams who feel they own the product, and can do what they want, ignore requirements etc.

In the end, this situation will change as the industry matures. But it won’t be quick. There are far too many companies that were started by a few engineers that hit the jackpot without needing business focus. Add to that the fact that the technical barriers to creating sophisticated applications continue to decline, so the incentive to “give it a go” will continue.

Technology is a business enabler. Product Management is the business function that enables companies to best match the potential of the technology and the business needs with market demand.  If people believe this to be true, then why not start out with experienced Product Management alongside Engineering (and Sales and Marketing) and accelerate the path to success.



6 responses to “Why Doesn’t Engineering report to Product Management (redux)

  1. One reason why engineers don’t like product managers is that a large proportion of engineers work in the field because they love what they do, which means they have opinion about it. That means when someone comes and tells them what they should be doing, there’s potential for conflict. I’ve been in both positions.

    The successful product managers I’ve known have been the ones who not only come up a good product plan but also get the engineering team excited or at least committed to the plan (possibly even taking feedback on board along the way). Bad PMs turn up expecting engineers to simply respect their authority, which often causes the opposite reaction.

    Those good PMs don’t need Engineering to report to product. Those bad PMs wouldn’t benefit from it.

  2. One simple way to look at the reporting structure is to consider how accountability and management fit together. It makes little sense for a product manager to be accountable for product success if she doesn’t have hire and fire authority over the people who are essential to its success.

    The success of the product depends on the competence of sales, marcom, and engineering. In organizations that wish to make the product manager fully accountable for product success, perhaps management should be structured as product teams, each with its own set of sales, marcom, and engineering folks, and led by a a product manager.

  3. Another great post on this topic, Saeed.

    I also believe that if there was a better overall relationship with Engineering and Product (which some of us have experienced, and some of us haven’t), those conflicts, which can cause delays and “misunderstandings” and just politicking in general, would be avoided.

    But I think this comes from more knowledge about what product does, which as you state, takes time.

  4. @Richard,

    Very valid points and I would agree with you that there are PMs who think they have authority over PMs or have no understanding of how to interact with other groups like Engineering.

    But, that is not always the case. I’ve seen and worked with Engineering teams who openly disregarded or discounted anything that Product Management unless it fit into their agenda. e.g. complex architecture projects and API development was welcome, but fixing deficiencies in the UI or adding functionality that simplified usage were shunned.

    In the end it’s about power and politics. A strong Product Management group in a company means a shift in power to them, and a lot of Engineering management will not let that happen.

  5. Great analysis, and I think very accurate. I think the current economy is going to benefit the Product Management role in the long run, because more and more focus will have to be paid to the value of what is being developed, in real market terms.

    Your post highlights the underlying attitude (usually initated from the top)that Product Management is only brought to “maintain the product”, when all the innovation is done. That is the attitude that I think will shift over the next couple of years.

  6. Pingback: Product Management Belongs in the Marketing Organization | marketada.com