In earlier posts, I’ve introduced the Three Layer Product Model (3LPM). Similar to all other software, platforms have three layers of functionality: innovative and experimental, differentiating and commodity. Functionality typically starts as innovative and, when it resonates with customers, becomes differentiating. The differentiating functionality drives sales and market share, causing competitors to develop similar functionality in response. Also, customers often get used to functionality. As a consequence, it commoditizes over time.
Functionality should be treated differently, depending on the lifecycle stage it’s in. During the innovation stage, the focus should be on testing many variations with customers to ensure that we have the best possible realization. Once the functionality is differentiating, we should focus on maximizing the value for customers in various ways, including adding variation points and variants. However, once it commoditizes, the focus should be on minimizing the total cost of ownership (TCO).
The focus on TCO is critically important as our research shows that the vast majority of resources, up to 80-90 percent, are spent on commodity functionality. There are several reasons for this. First, as it tends to cover the majority of the code base, commodity has a high likelihood of being affected by change requests. Second, companies tend to consider functionality to be differentiating much longer than customers do. Consequently, we tend to continue to invest in functionality even when it has turned into commodity in the eyes of our customers. Third, the commodity functionality tends to sit closest to externally provided software, such as operating systems, databases and web servers. As these external components are continuously being updated, there frequently are implications for the commodity software as well. Finally, especially in leaders without a software background, there’s a general belief that software is free once it has been built and that there are no costs or investments required to keep the legacy software up to date.
The main risk in platforms is that, over time, a larger and larger portion of the R&D resources are consumed by commodity functionality. As a consequence, the platform as a whole may start to commoditize and offer fewer and fewer reasons for product teams and external complementors to build on top of it.
We need to engage in proactive efforts to reduce the TCO of commodity functionality. There are at least three mechanisms I’ve seen used successfully in industry. First, between product management and R&D, we need to explicitly label components as commodity once these reach that stage. Based on that, we need to stop, or at least minimize as much as possible, accepting change requests for these components. Rejecting change requests affecting commodity components is often difficult in the beginning but tends to lead to impactful conversations about the platform, the product portfolio and what constitutes differentiation.
Second, where feasible, we should replace bespoke functionality with commercial or open-source components. In many cases, functionality is first built in-house as no external alternatives are available. However, over time, these alternatives may start to emerge and then the principle should be to replace internally built functionality with external commercial or open-source components to remove the necessity of future investments in these components.
Finally, I tend to encourage companies to instrument their products with data collection functionality to be able to know which functionality in the product is actually used in practice. Based on that information, we can decide to simply remove functionality that no or few customers are using. Although hard to implement in practice, often due to the sunk cost fallacy, this is by far the lowest-cost alternative.
All these mechanisms require architecture refactoring to separate commodity functionality from functionality that’s in earlier stages of the lifecycle. It can be hard to justify these refactoring efforts, but failing to invest in this will, in the long run, kill the platform for sure as it will become irrelevant.
Over time, the commodity functionality in platforms tends to consume a larger and larger part of the R&D resources. As a counter, we need to proactively engage in activities to reduce the total cost of ownership for the commodity. To accomplish this, we can stop accepting change requests for this functionality, replace commodity components with commercial or open-source components or remove functionality altogether. As Kay Yow is quoted to say: “Don’t let the urgent get in the way of the important!”
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
