Platform lesson #4: Don’t integrate new functionality too quickly
Any solution aiming to stay relevant needs to continuously integrate new, innovative functionality. The main reason is that functionality commoditizes over time so that if we wouldn’t add new features, the entire product or platform would commoditize and become irrelevant. Commodity software isn’t necessarily useless, as proven by quite a bit of open-source software, but it’s hard to monetize software stacks that don’t provide clear differentiating and innovative functionality.
One of the models I often use in this context is the Three Layer Product Model (3LPM). It organizes functionality into three layers. At the bottom, we have the commodity functionality layer where we aim to optimize for minimizing the total cost of ownership. On top of that, we find the differentiating functionality layer with the functionality that’s really liked and appreciated by our customers. Here, we optimize for maximizing customer value, meaning that we provide ample configuration and variation points to ensure that customers can optimally exploit the functionality. The top layer is the innovation and experimentation layer where we try out new functionality that we hope will provide future differentiation. Here, we optimize for maximizing the number of experiments that we can run.
We can use the 3LPM as a conceptual model, but it’s even feasible to use it as the basis for the architecture of the system. In this case, we define interfaces between the three layers to minimize dependencies and clearly classify functionality into different categories. This is important since, especially, commodity functionality is often still treated as differentiating, as a consequence of which it receives far too much R&D resources.
The focus here is the interface between innovative and differentiating functionality. The nature of innovation is that many, if not most, innovations fail to deliver the expected outcomes and shouldn’t be included in the platform or product. The good news is that the few innovations that are successful more than pay for all the failed ones, but we need to make sure that we minimize the negative consequences of these failures.
In many of the companies I work with, the software stacks contain vast amounts of functionality of which few people know whether customers use and appreciate it or not. The challenge is that most companies fail to instrument their software in such a way that they have a good understanding of the frequency of use of their features. As our research shows that half or more of all features are never or hardly ever used, it’s clear that a typical software stack contains significant amounts of functionality that shouldn’t have been included in the first place.
Rather than including innovative features immediately in the product or platform, we should first experiment and confirm with customers that the functionality adds value by ‘bolting on’ the innovative functionality and keeping it at the other side of an API. If it proves a hit with customers, we can then plan the deep integration into the product or platform. If it isn’t successful, we can easily ditch it as it never got integrated in the first place. This avoids bloated products and platforms that contain tons of non-value-adding functionality.
Although this is a generic problem for all software, it’s especially relevant for platforms as there always is a tendency in R&D organizations to include new functionality directly in the platform as it then is available to all products immediately. This is one of the many ideas in software engineering that makes a lot of sense on the surface but proves to be false when studied in more detail. Many companies struggle to remove commodity features and functionality that are no longer used from existing software, so let’s make sure we don’t integrate features that nobody (or too few) will use.
Software products and platforms need to continuously incorporate new functionality and features to stay relevant. The challenge with these new features is that many will prove to be irrelevant for our customers. This means that we shouldn’t integrate new features into the platform immediately but rather build them outside the product or platform, validate that customers actually use them (and not only say they do) and integrate only after we have evidence that each feature indeed adds sufficient value.
In the end, we care about effectiveness, not efficiency. Cranking out tons of features that nobody ends up using is a colossal waste of R&D resources. Instead, focus on finding what customers really care about and then invest heavily in those features. Even if you worry about some rework when a successful feature needs to be integrated into the platform, your overall R&D effectiveness will be vastly greater.
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).
