How and When of PLM..

In the last post, I had talked about PLM from Product business perspective. In this post, I will talk about PLM from customer perspective.

PLM conundrum
There is a fundamental conundrum in PLM. Customers require a stable service without disruption with least management and that goes on expanding its features that fetches them more revenue to fight against their competition. This means that Vendor has to ensure his product is continuously upgraded seamlessly.

Also Vendors life depends on the product. Hence vendor has to ensure that the given product has to provide continuous business that is profitable to maintain. Vendor is also interested in continuous seamless upgrade.

The conundrum is in a more fundamental aspect. The aspect of ‘Change’. Change is rather a series of discontinuities than a continuous flowing element.

Hence change poses a limit to which continuous upgrades that enhances the real value of product can happen. Continuous upgrades can embellish a product further and enhance sales to certain extent. They won’t necessarily give the much needed new life or revenue to the product.

This is the conundrum in which developers perceive change and the customers want change. Customers often want change as smooth flowing and developer perceive it as a series of discontinuities.

Sometimes in my experience, I have seen some continuous upgrades have provided a big lift to the product. But if investigated, it would turn out that the given set of changes/features could have been easily visualized at the definition of product. It is more a ‘catching the tail’ effort, in these cases.

Real product enhancements can happen only when fundamental shifts happen in the way we define the product. This could be due to change in environment, better understanding of customer environment, change in technologies that enable new ideas etc.

When such product enhancements happen, mostly it is difficult to provide it as a seamless continuous upgrade. So the issue of life of every product assumes importance. When to effect the change in product (when to kill the old version) and how to effect the change in customer environment are important decisions for PLM.

Twin Problems of PLM: How and When..?
The twin problems of PLM, when to kill a product version/model and how to do it in customers place can be resolved only specific to customer environment.

Migration Path
Customers do not bother about fundamental shift in the product design or technology. They look at solutions that fulfill the need. Hence they may not give credit to the fact that fundamental design has changed. They would like to have the new version anytime, if that does not bother their operations or working and is guaranteed to provide more satisfaction.

But that is not the case always. Generally fundamental shift in design is always associated with shift in the way product lives in customer environment. The shifts could be in the form of databases, operating systems, hardware or the concept of user interfaces. So it becomes necessary that customers experience a pain in migrating to new product.

While customers may want new product models, they may not want the associated pain. If they perceive a pain exists in this process, they will throw out the idea of new product models. And this will result in obsoleted product models getting stuck in customer places, requiring expensive support. This could result in bad blood with customer, who if forced to change to the new product with pain, may change the vendor himself.

In my experience the fundamental problem in this is that a migration path is not well defined, when product gets developed and maintained. Frankly in 90% of the cases, a painless migration path is possible in software products, even across disparate and diverse platforms and architectures. But Product Managers and Technology managers do not define the migration path, when new product models or versions get developed or changed. They do not provide great importace to this migration path.

At times, defining a migration path may not be that much difficult. It could be fairly simple. But since no though process goes into it, it appears very difficult and is often left to poor customers.

Hence it is important that Product Managers drive their technology counterparts to define a migration path that makes the life easy for customer, after understanding the customer environment very well.

Timing of Migration
It is important to time the migration of product models in customer places. Product development happens in its own cycle and Customer’s business happens in its own cycle. These two may not necessarily match, as product development follows the aggregate of customer business movement and not individual customer.

Most of the time, I have seen Sales pitching new product models and versions with customers at opportune moment of theirs and not the opportune moment of their customers.

And to identify the opportune moment sales need to work continuously with customers without imposing the new model or version, but by enabling customers to understand that their product versions and service offerings are improving.

When to start NPD..?
Product development for new models and versions can start anytime, once the roadmap is clear and requirements for next set of product versions are frozen.

But these requirements have to be mapped with clear cut business objectives and revenue objectives for the business. The business objectives consists of sales volumes, revenues and margins, future business that are possible, new market/geographical segment or customer diversification that would be made possible etc.

Many a times requirements are not tied with business vision for new models and versions. In such cases there is no way to calibrate the business achievements or success of the new model. Unless there is a goal or business objective is set at the definition stage, its success cannot be measured.

In general it is a good practice to create a P&L for every model, both at the start of the model and with every sale though at times it calls for painful changes in business process. This should be done atleast in important models.

Generally PLM is more treated as a non-revenue, techno-commercial function. But in this blog, I had categorized PLM as an aspect of Revenue categorization under Revenue Focus in Habitat Level Management.

Earning Focus
The next parameter in Revenue focus is Earning Parameters focus. What I call as Earning Parameters are those parameters that determine the success of the product business. They could be Gross, EBITDA or Net Margins as the case may be.

I would strongly recommend Product Managers to understand their business and determine the earning parameter that they need to concentrate on. They need to synchronize this with their management.

In case multiple products or models or versions are being managed, then a parameter like EBITDA can be used effectively for relative comparison of profitability of product businesses. EBITDA is a good parameter at this level as a comparing metric for earnings of different products and over time.

Once a product manager has an earning focus, he would definitely ensure that all upgrades and models are valued appropriately and the values recovered by pricing the upgrades appropriately.

This is needed because Product Managers need to be clear in their mind what is part of Annual Maintenance Contract and Warranty terms of Customers and what is not. They need to communicate it to end customers through appropriate channels and be in sync with customers on that. Once the revenue focus is there it would automatically drive the Product Managers to clean up their house in terms of what they offer to customer on a continuing basis.

With this I end my thoughts on Revenue focus. Let me share my thoughts on Competition focus in my next post.

-Balajee Rajaram