Defining Product Management: An Introduction (Part 1 of 5)

“Systems program building is an entropy-decreasing process… Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.” – Frederick P. Brooks

[1] For anyone who has worked for more than five years focused on enterprise software development, there is no question of the truth in the above statements. Systems, even great ones (most particularly great ones) break down over time. “All repairs tend to destroy the [original] structure” [2] and that is self-evident in the challenges we often see in the application registers of large organizations. Either there are large, unwieldy, unyielding systems which get bogged down during major processes, or there are systems which are shiny and spiffy and new like a Ferrari off the lot but which still face ongoing maintenance challenges and costs, and the eventual end-state of complete chaos that will simply need to be sold for parts.

That said, while it’s impossible to prevent the inevitable, it is more than possible to delay and to manage the lifecycle of an application, of a product. That, specifically, is the ideal role of a product manager: to manage an application (or product or service, whatever you wish to call it) from its conception, through to its realization, its operation and maintenance, and then its orderly retirement – from the cradle to the grave. It is to maintain oversight and hold back chaos so that there can be “skillful [execution] of program maintenance” which would extend the usability and viability of that product.

Here are some questions which I’ve heard asked as to the value of the product management function, such as:

  • Why do we need product managers when we have project managers?
  • Is there a difference between product management and program management?
  • Isn’t product management the same as business analysis, just called something different?
  • Shouldn’t product management be a business function?

Many of these questions are due to the fact that in across various organizations and across departments of the same organization there can be varying implementations of the functional role. With that variety of approach and how it embeds itself over time in different teams, there is overlap, great and potentially inappropriately, with other functions like business analysis and project management.

While it would be naïve to approach a practical discussion of product management without considering those counterparts, it would be stupid to fail to state this clear premise: none of these things are like the other. All three of those roles are valuable in and of themselves, perhaps irreplaceable, and they all can effectively operate within a mature, and agile, technology delivery organization.

[1] This is adapted from a private paper authored in 2012.
[2] Fredrick P. Brooks, The Mythical Man-Month, p234

Please share this with a friend or colleague who you know would benefit from it and follow me on LinkedIn where I post other items similar to this.

If you would be interested in me coming to work with you or your company on solving a wicked problem you have, please take a look at my background and send me a message at



Leave a Reply

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

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

Facebook photo

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

Connecting to %s