What is Product Management? (the core, the over-extended, and the totally dysfunctional)
Sometimes I help companies (usually startups) kickstart their Product Management function. These companies often know they WANT Product Management, even though they often don't have a clear idea of what Product Managers actually do.
In another post, I speculate about why this widespread ignorance of Product Management exists. But for this post, I'm just going to stick to what I've seen based on working with dozens of software companies.
Product Management varies greatly
The roles and responsibilities of Product Management are defined very differently from company to company, even within a tightly defined industry sector.
Before I started working as a consultant, I thought that pretty much every place defined product management like my former employers.
Not so.
At some places, product managers were strategic leaders. At others, they were evangelists, preaching the gospel of their product to the market. At others still, they were basically business analysts focused solely on creating requirements docs. And finally, I encountered many product managers who did not seem like product managers at all, but instead were really proJECT managers (keepers of the Gantt chart), sales engineers, or coders. In short, roles and responsibilities of Product Management often overlap with many other functions.
But despite the wide variation, there were a few areas that everyone agreed were the primary responsibility of product management.
The core activities of Product Management
Industry-wide, almost everyone agrees that defining the product (deciding which feature are in which product release) and guiding development (by writing requirements and/or user stories) are solely the responsibility of Product Management.
However, I firmly believe that it is NOT POSSIBLE for PMs to do a good job of defining products without:
- Deeply understanding the product's market: what its users are like, the problems and pain they face, the constraints they operate under, etc.
- Completely internalizing the product strategy, the "big picture" rationale for why the company is developing this product for this market and why it will win.
- Using strong listening and influencing skills to learn what's most important and to get others (especially developers) aligned with their product plans.
So, at every FUNCTIONAL product management organization I've seen, this diagram shows the CORE activities of Product Management that can't safely be assumed by another function in the company:
The core plus some other product activities
While the above diagram shows the essential activities of good Product Management, usually product managers have several other product-related responsibilities. In the below diagram, I show these responsibilities in the light blue ring.
Product Management is usually responsible for a few of these activities, with other roles like Product Marketing or Sales Engineers are responsible for the rest.
I'd generally caution against having Product Management be responsible for ALL of these activities, because it might take away from time to address the core PM activities, but I think it is good for PMs to take on a few of these product-related activities.
Common Dysfunction #1: Too many non-product activities
This brings us to a common dysfunction: requiring the Product Managers take on several non-Product responsibilities, in addition to the Core PM activities and lots of non-core Product responsibilities. These leave the PMs without adequate time to visit customers or prospects, and can prevent the PM from acting as the "voice of the market" (because they are too busy coding or managing projects).
Dysfunction #2: (The most common and dangerous): neglecting the core
The opposite situation is perhaps the most common and most dangerous dysfunction, where Product Management skips the core activities of gathering market insight and product strategy.
In this situation, the product managers come up with product features based on their personal whims and preferences (which are almost always wrong), spend their time arguing with developers (who don't respect them because they realize the arbitrariness of the PM's decision process), and putting out fires which could have been avoided with a bit more planning and foresight. The resulting products are lack-luster and don't live up to their potential.
I'd estimate that about 50% of companies are victims of this very common dysfunction. Sometimes it's because they just don't know any better. But even very good Product Management organizations can degrade into this dysfunction if they are not vigilant. It takes real discipline and time to have your product managers constantly talking to customers, gathering market insight, and refining their product strategies. It is oh-so-tempting to let these activities slide when you're feeling overwhelmed by the huge amount of tasks Product Management is often expected to help with, most of which are non-core product tasks (the light blue ring above) or not even related to product.
But if you neglect the core activities, no one else is going to pick up the slack. You're just going to be making poor product decisions and stuck in a reactive mode.
In contrast, if you selectively neglect non-core product tasks, there is often another function that can pitch in (such as Product Marketing). And for non-product tasks (such as coding), well, you probably shouldn't be doing them anyway because they detract from the "market mindset" that PMs need.