In Part 1, I defined the mandate of Product Management as:
Product Management’s mandate is to optimize the business at a product, product line or product portfolio level over the product lifecycle.
I’ve emphasized 3 words: optimize, business and lifecycle.
Optimization is the process of changing a system to make it work efficiently within a set of given constraints.
Fundamentally, this is what Product Management is all about: how to invest limited resources to deliver competitive products to market, that are in line with market demands and expectations and then working with other teams to better enable them to reach their targets that make up overall business goals. 🙂
Product Management must always keep business goals in mind and work to achieve or help achieve those goals within the context of the products or product lines. Business goals are typically related to revenue, expense, customer acquisition, market share, geographic expansion or organizational improvement. This is a sample list of goals and doesn’t imply that Product Management must focus on these areas.
It’s important to keep in mind that business goals differ across the product lifecycle. A product lifecycle can be defined as having the following stages:
- End of Life
There may be variations on these stages, but this represents the major phases that a product will pass through. And the goals and objectives for the product will vary at each of these stages. For example, the Development phase usually is pre-revenue. In this phase, Product Management is focused on understanding market needs and working with various parties (internal and external) to create a product or solution that addresses those needs.
With Launch, the goals for the product can include initial customer acquisition, validation of the product in the market, educating influencers, generating awareness etc. Revenue obviously becomes a major factor after Launch, as do goals such as customer retention and ongoing competitive differentiation. The other phases — Growth, Maturity, Decline and End of Life (EOL) — all bring their own challenges, constraints and objectives.
Given the changing objectives over the product lifecycle, the goals of Product Management will change, activities to achieve those goals will change and the metrics that are used to measure them will change.
In part 3, I’ll get more specific, and lay out a model that people can apply to their products or product lines. It is important to note that there is no “one size fits all” solution here. Only at the highest level of business reporting– customer acquisition, revenue, customer retention etc. — can there be a single set of metrics for most products.
Because of the breadth of potential technology products — e.g. SaaS vs. Licensed software, a consumer product vs. a B2B product, infrastructure vs applications, a retail product vs. an OEM product etc. — specific metrics across the lifecycle will vary.
Department vs. Role
I do want to make take a few moments to address a question related to role metrics vs. department metrics. That is, the metrics used for measuring a Product Manager, vs. the metrics used for measuring Product Management as a whole.
In small companies, there may only be a single Product Manager for a given product or product line. I’ve been in that situation myself a couple of times. In those cases, metrics for the Product Manager are pretty much the same as that for the Department.
But in larger companies, where there truly is a Product Management team, most likely with differentiated roles for PMs (e.g. Technical Product Manager (TPM) , Sr. Product Manager, Director Product Management etc.) the metrics that would be used to measure individuals likely would be different that those for the entire team.
For example, a TPM would likely spend much of their time working with Engineering during a development cycle or researching technical issues for upcoming releases, whereas a Director would be more focused on overall product strategy, business alignment, strategic partnerships etc.
The Product Management team may be measured on product revenue, delivering a new release successfully etc., but individuals in that team would have other role specific metrics tied to their individual activities and responsibilities as well.
As mentioned earlier, in part3, I’ll get more specific and present a model that could be applied or adapted by Product Management teams.