Product Management for Pummies - Part 6 (PLM)
Revenue Categorization: Understanding the Product Life Cycle
Before I proceed further with revenue categorization, let me talk about Product Life Cycle Management, which is a very important dimension of Habitat Level Product Management. Understanding Product Life Cycle Management in proper perspective is important to understand the benefits Revenue Categorization leads to.
Product Life Cycle Management starts at the time product gets conceptualized and defined. But traditionally people start Product Life Cycle Management, when it is on its deathbed or sometimes after it has expired!
At the habitat level, Product Life Cycle is all about adapting the product to the different customer requirements, new features needed for operations, customer business etc. In short it is all about creating different species of the product for its adaptation and survival.
But Product Life Cycle management can be thought of as simple as Version management particularly in field. An unskilled laborer says he is placing bricks on cement and mortar. A mason says he is building a wall. An engineer says he is building a house. An architect says he is building a home. It all depends on Product Manager being a laborer or mason or engineer or architect.
Product Manager should have the vision of an architect, plan of an engineer, objectives of mason and work like laborer.
A product generally grows in three different dimensions.
1. One dimension is that of new features as envisioned as requirements by Customer’s or from market that could be applied across to multiple customers. This grows with respect to time and has end-of-life and support issues.
2. Another dimension is due to obsolescence of components or features generated by Product development teams. This also grows with respect to time and has end-of-life and support issues.
3. Third dimension is that of those customizations that are restricted to certain customers or geographies. This grows with respect to customers. Typically these solidify as product models and exist all the time.
Product Manager as a Laborer (Version Control and Management)
The first job of Product Manager is to ensure that there are no uncontrolled versions of products floating around. The next job is to ensure that the number of versions are very limited in all three dimensions. Version growth is like Population growth. It is advantageous in the sense it gives multiple forces to fight the market. It is disadvantageous in the sense it depletes our resources. The product manager has to find a balance in the population growth by working with customers as well as technology teams.
What is the right rate of growth for population..? Ideally slightly less than 2 kids per family. Similarly per particular market segment ideally not more than 2 product models, which may grow in versions as time progresses. Again ideally at any place a version should not exist more than 18-24 months, unless the product model growth has stopped further.
But these could be re-defined based on the product market and geography. The idea is a Product Manager must know what these values are. The product manager has to ensure that the models and versions are well controlled.
Product Manager as a Mason (Model Control and Management)
At a mason level, the Product Manager has the responsibility of defining the models appropriately for different segments and customer needs. He will not be looking at it as version management. The idea here should be to monitor individual models as individual products and track their lifecycle separately.
As a mason, product manager should bring in a serious revenue perspective to growth of models. Models grow based on revenue and revenue potential. As the mason builds walls after walls, a product manager need to build models based on revenue.
Product Manager needs to properly categorize revenue based on the models. Current revenues and Revenue potentials decide the life and intensity of a model. It would be a good practice to create P&L for every model, so that not only revenues, but all associated expenditures are tracked and a realistic margin is arrived at.
Many a times, for revenue categorization Product Managers may have to tweak business processes and how Finance and Accounts handle the revenue and expenditure categorization, as that vision might not be originally built in.
Product Manager as an Engineer (Planning the Basic Models)
At an engineer level, the Product Manager has to plan for different models apriori. Different market segments and needs, customer and customer cultures need to be understood before defining the models.
The key decision is to define when a model is to be formed. Left alone, Technology teams decide models based on features, code base, hardware platform or operating system. This is like building walls based on availability of wood or mortar or cement. Just because materials are available, will we keep building walls..?
The right way to define models is based on the customer need and the revenue differentiation it would bring. Product Managers have to perceive the different product models as like the walls of a business house. They have to be in the right place, conveying the right value.
The value of a wall is in providing separation in terms of privacy and security. Similarly product models need to provide revenue separation in terms of growth prospects and revenue stability. That is, Product Managers should create product models if model definition brings in a different revenue growth and revenue stability.
Sometime Product Managers try to make every product positioning as a model. It would work sometimes. Many times it would not work. I have observed that it works only when the justification for the model based on different product position is due to different revenue flows or revenue growth from other positioning.
At this level, the Product manager should have P&L’s for every model as well as the whole product and understand which model moves currently and what can move in next 3-4 quarters.
Product Manager as an Architect
An architect has to visualize his construction even before a single activity is carried out. Similarly product managers need to visualize their product business even before the product is designed. Once a vision of the product business house is in place, as product develops, reaches customers, matures the vision can be modified to make it more profits, more cash-flow and more customer value.
Hence the product manager must have a roadmap for the product in terms of its applicability and adaptability. An architect while envisioning a building should clearly know for what purpose the building is being built, to what all purposes it need to be adaptable, how much of air, water, light, parking and other sanitary facilities would be required etc.
Similarly a product manager as an architect need to have an idea of which market segments it is currently applicable, to which it can be adapted, to which it cannot be adapted or will be difficult to adapt, kind of resources it would require at customer premises (space, electric power, CPU power, hardware, operating skillsets etc) and kind of resources it would require to develop (Human resources, skill sets, software requirements, hardware requirements etc).
Once these are known, the product manager should set about defining every aspect of the product, to develop it and as it would exist in customer premises. He should also define some basic models possible and then leave it to the engineer for further re-definitions as product moves in the market.
At this level, the Product Manager has to have a P&L for the overall product in terms of its models for next 24-36 months. Product Manager should also have an idea of upgrading the product to newer products. This is because once a product is in market and with customers with decent revenue generation, it gives a huge customer base for the next product.
Version or Model or New Product..?
Often there will be issues in classifying the product as a newer Version or Model or a totally new product.
The desire to ride on existing product would force Product Managers to pitch it as a new model that is upgradeable (or exchangeable). Desire to create more revenues would force us towards New Product approach all together. So Product managers simply end up marketing as new product but selling as a new model. Similarly the desire for revenues pushes product managers to determine newer versions as newer models.
The distinction between them is blurred and flexible.
A thumb rule that I use is as follows:
If a particular version could be frozen and it could fetch fresh sales in the market or could be used to trigger fresh sales in the market, I define it as a new model.
If a particular model offers a break with the past, if contrasted with the existing environment, particularly technology-wise or sometimes business-wise, then I would define it as a new product.
I would NOT make these decisions based on if it is upgradeable or not, though that would be a factor to consider from the customer angle, for positioning the product.
Issues in Product Life Cycle Management
The critical issues generally associated with Product Life Cycle Management apart from the above are When to do it and How to do it..?
When to bring out a version, model or product..? Is it the traditional method, when we start hitting the slump..? How to ensure upgradeability..? How to sell upgrades or new models to customers, when they have already invested in our product..? Can everybody become Bill Gates and ask their customers to buy their product every 2-3 years..?
This and more in my next blog..
-Balajee Rajaram
Before I proceed further with revenue categorization, let me talk about Product Life Cycle Management, which is a very important dimension of Habitat Level Product Management. Understanding Product Life Cycle Management in proper perspective is important to understand the benefits Revenue Categorization leads to.
Product Life Cycle Management starts at the time product gets conceptualized and defined. But traditionally people start Product Life Cycle Management, when it is on its deathbed or sometimes after it has expired!
At the habitat level, Product Life Cycle is all about adapting the product to the different customer requirements, new features needed for operations, customer business etc. In short it is all about creating different species of the product for its adaptation and survival.
But Product Life Cycle management can be thought of as simple as Version management particularly in field. An unskilled laborer says he is placing bricks on cement and mortar. A mason says he is building a wall. An engineer says he is building a house. An architect says he is building a home. It all depends on Product Manager being a laborer or mason or engineer or architect.
Product Manager should have the vision of an architect, plan of an engineer, objectives of mason and work like laborer.
A product generally grows in three different dimensions.
1. One dimension is that of new features as envisioned as requirements by Customer’s or from market that could be applied across to multiple customers. This grows with respect to time and has end-of-life and support issues.
2. Another dimension is due to obsolescence of components or features generated by Product development teams. This also grows with respect to time and has end-of-life and support issues.
3. Third dimension is that of those customizations that are restricted to certain customers or geographies. This grows with respect to customers. Typically these solidify as product models and exist all the time.
Product Manager as a Laborer (Version Control and Management)
The first job of Product Manager is to ensure that there are no uncontrolled versions of products floating around. The next job is to ensure that the number of versions are very limited in all three dimensions. Version growth is like Population growth. It is advantageous in the sense it gives multiple forces to fight the market. It is disadvantageous in the sense it depletes our resources. The product manager has to find a balance in the population growth by working with customers as well as technology teams.
What is the right rate of growth for population..? Ideally slightly less than 2 kids per family. Similarly per particular market segment ideally not more than 2 product models, which may grow in versions as time progresses. Again ideally at any place a version should not exist more than 18-24 months, unless the product model growth has stopped further.
But these could be re-defined based on the product market and geography. The idea is a Product Manager must know what these values are. The product manager has to ensure that the models and versions are well controlled.
Product Manager as a Mason (Model Control and Management)
At a mason level, the Product Manager has the responsibility of defining the models appropriately for different segments and customer needs. He will not be looking at it as version management. The idea here should be to monitor individual models as individual products and track their lifecycle separately.
As a mason, product manager should bring in a serious revenue perspective to growth of models. Models grow based on revenue and revenue potential. As the mason builds walls after walls, a product manager need to build models based on revenue.
Product Manager needs to properly categorize revenue based on the models. Current revenues and Revenue potentials decide the life and intensity of a model. It would be a good practice to create P&L for every model, so that not only revenues, but all associated expenditures are tracked and a realistic margin is arrived at.
Many a times, for revenue categorization Product Managers may have to tweak business processes and how Finance and Accounts handle the revenue and expenditure categorization, as that vision might not be originally built in.
Product Manager as an Engineer (Planning the Basic Models)
At an engineer level, the Product Manager has to plan for different models apriori. Different market segments and needs, customer and customer cultures need to be understood before defining the models.
The key decision is to define when a model is to be formed. Left alone, Technology teams decide models based on features, code base, hardware platform or operating system. This is like building walls based on availability of wood or mortar or cement. Just because materials are available, will we keep building walls..?
The right way to define models is based on the customer need and the revenue differentiation it would bring. Product Managers have to perceive the different product models as like the walls of a business house. They have to be in the right place, conveying the right value.
The value of a wall is in providing separation in terms of privacy and security. Similarly product models need to provide revenue separation in terms of growth prospects and revenue stability. That is, Product Managers should create product models if model definition brings in a different revenue growth and revenue stability.
Sometime Product Managers try to make every product positioning as a model. It would work sometimes. Many times it would not work. I have observed that it works only when the justification for the model based on different product position is due to different revenue flows or revenue growth from other positioning.
At this level, the Product manager should have P&L’s for every model as well as the whole product and understand which model moves currently and what can move in next 3-4 quarters.
Product Manager as an Architect
An architect has to visualize his construction even before a single activity is carried out. Similarly product managers need to visualize their product business even before the product is designed. Once a vision of the product business house is in place, as product develops, reaches customers, matures the vision can be modified to make it more profits, more cash-flow and more customer value.
Hence the product manager must have a roadmap for the product in terms of its applicability and adaptability. An architect while envisioning a building should clearly know for what purpose the building is being built, to what all purposes it need to be adaptable, how much of air, water, light, parking and other sanitary facilities would be required etc.
Similarly a product manager as an architect need to have an idea of which market segments it is currently applicable, to which it can be adapted, to which it cannot be adapted or will be difficult to adapt, kind of resources it would require at customer premises (space, electric power, CPU power, hardware, operating skillsets etc) and kind of resources it would require to develop (Human resources, skill sets, software requirements, hardware requirements etc).
Once these are known, the product manager should set about defining every aspect of the product, to develop it and as it would exist in customer premises. He should also define some basic models possible and then leave it to the engineer for further re-definitions as product moves in the market.
At this level, the Product Manager has to have a P&L for the overall product in terms of its models for next 24-36 months. Product Manager should also have an idea of upgrading the product to newer products. This is because once a product is in market and with customers with decent revenue generation, it gives a huge customer base for the next product.
Version or Model or New Product..?
Often there will be issues in classifying the product as a newer Version or Model or a totally new product.
The desire to ride on existing product would force Product Managers to pitch it as a new model that is upgradeable (or exchangeable). Desire to create more revenues would force us towards New Product approach all together. So Product managers simply end up marketing as new product but selling as a new model. Similarly the desire for revenues pushes product managers to determine newer versions as newer models.
The distinction between them is blurred and flexible.
A thumb rule that I use is as follows:
If a particular version could be frozen and it could fetch fresh sales in the market or could be used to trigger fresh sales in the market, I define it as a new model.
If a particular model offers a break with the past, if contrasted with the existing environment, particularly technology-wise or sometimes business-wise, then I would define it as a new product.
I would NOT make these decisions based on if it is upgradeable or not, though that would be a factor to consider from the customer angle, for positioning the product.
Issues in Product Life Cycle Management
The critical issues generally associated with Product Life Cycle Management apart from the above are When to do it and How to do it..?
When to bring out a version, model or product..? Is it the traditional method, when we start hitting the slump..? How to ensure upgradeability..? How to sell upgrades or new models to customers, when they have already invested in our product..? Can everybody become Bill Gates and ask their customers to buy their product every 2-3 years..?
This and more in my next blog..
-Balajee Rajaram
|
|
