When is it time to consider rebuilding a product from the ground up versus just continuing to add features? The software landscape is littered with ‘version 2’ projects that were over-engineered and failed to see light of day. However, on the other hand, as a product matures it tends to get featured to death and become unusable or at least unfriendly. Like the management “Peter Principle” that describes how employees rise to their level of incompetence, when a product matures with too many add-on features and capabilities, it reaches the point where it it starts to be trapped by all the baggage.
It is a huge decision to replace a mature product with a new Version 2. The implications go far beyond just the engineering project, and the decision has to be a cross-functional strategic one. Having said that, companies need to be bold when the time comes to re-platform and rebuild a product. Everyone should embark on the project with open eyes and a clear understanding of the objectives, the potential pitfalls, and the likely progression of the project. Replacing a mature product with a new version will pass through a trough of capability, where the new product is less feature rich and less capable than the old mature product, and therefore less competitive in the marketplace. Most companies are ‘forced’ to continue to incrementally invest in the old product to appease existing customers and remain competitive while the new product is coming up the curve. Investment in the new product is high, and duplicative to the investment to sustain the old, and unless there is a clear plan, it can seem like the new product is constantly chasing the old but never quite surpassing it. So, does it ever make sense to start over?
The answer is yes. If you are considering the old product to be a problem, you can be sure your customers realized it long before you did. You probably see it in a declining rate of expansion, or increased churn, or lower win rates, or longer sales cycles. Maybe it is evident in less efficient engineering, or technical roadblocks to adding new capabilities. Maybe it surfaces in increased quality problems and slower break/fix cycles due to the complexity of the code. Maybe it only manifests in a higher volume of support calls and the need for ever increasing product training. If you look for it, you will see that the time for re-platforming is upon you. If you don’t see it, someone else will, and you will probably face a competitive threat challenging your market position.
We see vibrant innovation in start-up competitors that don’t have an installed base or an old product holding them back. They are learning from your mature product and innovating a new and better approach to replace you. If it isn’t a start-up, then one of your mature competitors is going to see opportunity and swoop in to take advantage of it. The automobile industry and specifically the electric car revolution is a good example. How did Tesla become one of the leading automobile manufacturers in what seemed like overnight? To the casual observer, a Tesla may look like just another car. It has the same basic features and capabilities as all the other cars. However, under the covers, Tesla was designed from the ground up to be a new, ‘version 2’ of an automobile. It was built to be new and better, and to replace the status quo. By contrast, most traditional cars were designed and built in a different era with different concepts, and they have a lot of history and features from times gone by. They have an installed base and entrenched engineering and production. In software terms, they have a lot of tech-debt, and they were resting on their laurels of past success. With its clean modern architecture and design, Tesla created a platform for innovation that can be enhanced and improved at a pace well beyond what traditional manufacturers could achieve.
When a product is built from a clean slate, it eliminates the tech-debt. With no tech-debt, all of the investment in engineering is directed toward innovation, and the product can move forward faster than competitors that are struggling with baggage. When it is done well, ‘Version 2’ delivers a springboard to the future, and it enables you to set the pace for the market.
The challenge is that troublesome trough of capability. A common term used to describe the design point for a first commercial release is ‘minimum viable product’ (MVP). There are a few problems with this concept. First, it has to be defined in the context of a market segment with a clear value proposition. If Version 2 is slated to enter the exact same market as Version 1, then to be viable it will need to compete at least as effectively upon launch. To do so, it will have to be feature rich, so ‘minimum’ is really not aligned with the market if the goal is to be ‘viable.’ One approach is to design Version 2 for a different market or sub-segment where limited features can still deliver a value proposition that is viable. This could be a down-market offering. Maybe the mature product addresses the needs of large global organizations with multiple languages and currencies, while the early release of Version 2 could target smaller companies that don’t have the same global requirements. Perhaps the points of enterprise integration or flexibility of configuration can be limited on initial release if the target buyer is less demanding. The key is to select a market segment where Version 2 in its early form can in fact be viable*.
Once launched, the market can lead the growth of the product. The ultimate goal may be to make Version 2 so attractive that traditional customers of Version 1 will find it compelling to adopt even if they have to give up some of their existing V1 features. Alternatively, Version 2 may open the door to a new and potentially larger market than Version 1 ever could address, and it could facilitate a corporate pivot to a steeper success curve. The most challenging design point for Version 2 is to attempt to launch with greater capabilities than Version 1. It has been done, but this is the scenario that typically leads to over-engineering Version 2, and greatly increases the risk of never crossing the finish line.
* Note: I have a real problem with the term ‘minimum viable product - MVP.’ It sounds like the commercial that talked about aspiring to be ‘mediocre.’ Products should aspire to be ‘successful’ not just viable. I insist on aiming for the ‘minimum successful product -MSP’, which has a higher goal than simply being viable.