Training Banner

Wednesday, October 28, 2015

The critical accountabilities for product management effectiveness

I've written previously about product managers in name only, PMINOS. I would like to elaborate on those thoughts, this time focusing more at the organizational level. As part of my consulting practice, I regularly engage with software product organizations that have allocated product-related accountabilities in a way that I consider suboptimal. These experiences prompted me to describe the accountabilities I consider critical for product management to have the influence they should on the product business and life cycle long-term. To have an impact that significantly increases the long-term chances of product success, software products should have a product management function that unites accountability for:
  • understanding customers and markets ("external perspective")
  • defining and ensuring execution of product strategy
  • operational oversight of development work outputs
Although some may consider the first point obvious, some organizations explicitly divide inbound and outbound perspectives in such a way that product managers spend little or no time talking to external stakeholders. I believe it is impossible to develop adequate empathy for stakeholders without direct exposure. Regardless of how tight the collaboration is with other professionals who engage with external stakeholders, PM cannot develop necessary customer understanding by proxy.

The definition and execution of product strategy may also seem like an obvious accountability to many, especially those in smaller product organizations. However, it is not at all uncommon to find product management organizations that are so overwhelmed by tactical challenges that they fail to define a compelling, explicit product strategy, leaving others to infer what they can or enabling others to define it for them. In terms of defining a strategy, I use the OMG Business Motivation Model as a reference model. It's worth noting that a lack of understanding and empathy for external stakeholders results in a strategy that is, put mildly, unlikely to increase the chances of commercial success. The product roadmap is the most practical expression of vision and strategy to all stakeholders. If PM doesn't own the roadmap, I would content there is no way for them to have the impact they should.

Operational oversight of development work outputs is a perhaps an overly fancy way of saying that someone with a strategic, customer-focused perspective needs to continuously engage with engineering as products are being developed to ensure the final product (or incremental product, for that matter) reflects customer wishes and organizational vision and strategy. Communicating insights regarding customer or market needs and educating engineering on business motivation in no way guarantees that development will stay on track as they, in good faith, set about developing complex products. Effective product managers spend a significant amount of their time assessing the work product of development and facilitating corrections as necessary. Offloading all oversight to a product owner who reports to development is a mistake that will eventually compromise execution strategy.

So there you have it, from an organizational perspective, leadership committed to long-term market success must ensure that these accountabilities are united in a healthy, empowered product management function. Would you agree? Is product management properly enabled in your organization? You can find more information on my offerings, including software product management training, on my site.

1 comment:

  1. 10+ years being a PM here and I agree with the article, although I would stress out that technical competence is something too often overlooked.

    I have seen many software PMINOs that lack the influence because the engineers just flat out do not take them seriously. That usually happens when the PM is not technically savvy. I am not saying the PM should code, but I do believe the PM should have done that at some point. And I rarely see this mentioned.

    Why is this important? For many reasons.
    1) A PM that has walked the walk has a much better feel for realistic timeframes and the PM will be able to more accurately see if engineers are padding their work or BSing
    2) The PM will have a much better understanding for technical/architecture issues that can affect a feature
    3) Engineers will be more cooperative with the PM (for obvious reasons, I think)
    4) The PM is in a much better position to say no (to a customer, another manager, etc)

    I know that many PMs probably don't want to hear that, especially the ones closer to a Product Marketing role, but I do believe this is very important. At a very minimum the PM should have the bug tracking system open at all times and know it by heart.

    At my current company (, the PM role has a deep understanding of software architecture and it works wonders. In 8 years of product cycles we have not once created throw-away code, our estimates are the most accurate I have seen at any company I worked for (this is also partly due to us not obsessing about feel-good, long-term roadmaps) and our customers are very happy with the product and features they get.