|NOTE – THIS BLOG HAS MOVED
You can see the new version of this article at the following URL:
How important a role does Product Management play in your company?
Is it truly a strategic role, or is that just what is written in the job descriptions when hiring PMs?
Who sits at the table?
Does Product Management report directly up to the CEO, or does it report through Marketing or Engineering, or heaven forbid, up through Sales. Not that I have anything against the Sales orgs in companies, but if Product Management is reporting up through Sales, the company doesn’t understand the role or the benefits Product Management can provide.
I view Product Management as a key function in a company that should have VP representation at the Sr. Management level. i.e. Product Management should be on par with Sales, Marketing, Engineering, Finance etc. and should not report up through any of them. If that is not the case, then that means that the company views Product Management as subordinate to these other groups and not worthy of “a seat at the table”.
It means that the influence Product Management will have will be subordinate to the influence these other groups have. For example, if Product Management is part of Marketing, and Marketing consists of Corporate Marketing, Product Marketing, Field Marketing and Product Management, guess how much focus and attention Product Management will have from the VP of Marketing, let alone the Sr. Management team?
Are PM roles defined clearly?
Second, it’s very important to clearly define the duties and responsibilities of Product Management and demarcate them from analogous duties that other team may have.
For example, when talking about Competitive Analysis, one must distinguish between the types of competitive analysis that, for example, Product Managers need to help define future releases of products, and the type sales teams need to compete on competitive deals. The end audience for those analyses is important in deciding who will create the particular outputs.
Sales teams need competitive information so they can position products clearly and respond to prospect questions or objections. Sales people may need high level “kill sheets” that list the key benefits and strengths of their offerings, and the key weaknesses and threats of the competition. Sales Engineers working with Sales Managers may need more detailed technical feature/functionality information. This is typically the job of Product Marketing.
Product Managers need very specific information about competitor’s strategic direction (and roadmap if possible), product functionality, limits or shortcomings, as well as key differentiators. i.e. the gaps between what the competitors does (or will do) and what the PMs own product(s) do and will do.
It is based on this type of detailed information that PMs can make the appropriate decisions on how to invest the time and efforts of the development teams to produce future releases of product. But, this kind of information is, in itself, not useful for sales teams.
Now, who can provide this kind of information for Product Management? Likely only other members of the Product Management team — perhaps Technical Product Managers, or Solution Architects or Technical Competitive Analysts — because other groups, such as Product Marketing, or Sales Engineering don’t have a vested interest in doing this work. They have other goals and objectives to focus on.
How to define the roles well?
The question then is how can the roles of the Product Management function be defined for maximum efficiency and benefit? Take a look at the following two diagrams. The first is a relatively well-known Pragmatic Framework diagram from the people at Pragmatic Marketing.
This diagram defines a number of possible activities ranging from Strategic to Tactical, in various categories such as Market Analysis, Qualitative Analysis, Product Planning, Sales Readiness that various people must complete during the product definition, development and launch cycles. Notice that it does not explicitly define the time frames in which these activities must be enacted, nor does it provide any specific order in which these activities must be completed. It is a generic framework diagram that can be used as a basis for defining the Product Management function in a company.
The second is a not so well-known diagram by yours truly.
This diagram is almost orthogonal to the Pragmatic diagram. It lists specific deliverables that the Product Management function must deliver on during the product definition, development and launch cycles. It is categorized by stages in the development process and not by functional area ranging from strategic to tactical. It is, in fact, a specific implementation of the above Pragmatic framework diagram, tailored to a particular company’s need. Your company may have different needs and thus a somewhat different diagram.
This diagram, backed up by a roughly 20 page document describing each of the deliverables in the grid, down to who participates in completing them and who accepts the deliverables that are generated at each cell in the grid, describes very precisely what Product Management does, and equally importantly, what Product Management doesn’t do. Left out of this diagram are specific activities such as working with sales to help close deals or even, for that matter, visiting customers/prospects. Those are fundamental things that must be done as part of the job and feed into the deliverables listed in the diagram.
So, why go through the exercise of creating the diagrams and supporting definition documents? Well, if you truly want to build a Product Management function in your company then the first thing you need to do is clearly define what that function is responsible for. By defining it this way — what needs to be delivered when, to whom and by whom — the focus is placed on the outputs and those dependent on the outputs (the what) as opposed to the specific tasks that need to be completed (the how). Put another way — the people who depend on Product Management to do their jobs know well in advance, what to expect and when to expect it, without placing specific restrictions on how those deliverables must be completed. That is left to Product Management to decide.
Sounds like a model of efficiency to me. And isn’t that what you’d expect from anyone who has a seat at the Sr. Management table?
The rest of the series
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)