A couple of years ago, I was engaged with a team involved in the migration of an e-commerce platform. Based on a budget, the cost of ownership, and an implementation deadline, the executive team selected a medium level e-commerce platform provider over other premium vendors and custom coding. Soon we realized that each and every implementation of the chosen vendor’s e-commerce platform was a customized version of its core product and framework.
For some enterprise clients, the custom version of the e-commerce platform had additional features and extra modules (different types of billing channels, promotional engines, analytics, etc.) not present in the core product while for other mostly smaller clients, the vendor did a scaled-back implementation of the core product feature set. This process of having multiple different versions of a single product running simultaneously usually works well if you have a limited set of versions and a limited set of customers and users.
However this strategy becomes increasingly difficult to manage and scale with multiple different product versions having disparate feature sets running at different client locations. New version upgrades, feature introductions, or any changes made under the conditions I detailed above can be a nightmare for a product management team. Looking forward, the product management team may think of creating multiple different flavors of product and market them (for example, a silver, gold, and platinum branding) for different customer bases. However, doing custom implementations on top of each of these versions could ruin the management team’s potential to scale and manage a stable portfolio.
I have seen similar scenarios happen over and over across the industry spectrum, from medium and large telecom billing and customer care (BaCC) product implementations to large-scale educational software products as well as major operating systems. Microsoft Windows is a classic example of how delays in major launches can occur when a significant amount of time is spent by the product group to consolidate feature sets from existing versions. Based on such experiences over the decade or so, I tried to isolate some patterns (or anti-patterns) about why product managers and product teams have a hard time managing their portfolios. I expect few of the traits to be familiar to the readers while others may be not that apparent.
Inaction of Under-performing Products and Projects
A lot of product managers, especially those in large companies, are more concerned about new products and well-performing products rather than ones that are not doing so well. They might expect that those poorly performing products will die a natural death and no one will need to worry about them. However, this inaction on part of the portfolio managers will affect the portfolio bottom-line.
Large banks—or any other multi-billion dollar enterprise—have a predetermined life span for most IT products and applications. However, due to organizational bureaucracy, age-old budgeting processes, and a consistent lack of sufficient and accurate data, the life span is always twice as large the preset limit; remember that Internet Explorer Six is still a preferred browser for some US-based financial organizations.