Avoid the feature parity trap
A lot of Product Management literature focuses on introducing new products but ignores legacy product modernization. In practice, however, many Product Managers find themselves modernizing or replacing legacy software and are asked to ensure feature parity (i.e., the intent to create a modernized replica for all current system functions) between the previous version and the future product. This article will explain why expectations for feature parity results in negative user and business outcomes and how to instead apply lean Product methodologies to meet user needs and modernize successfully.
The problems with feature parity
Legacy products have, inherently, been around for a long time. As a result, the tech stack is outdated, driving high development and maintenance costs. Additionally, opportunities to use new technology are either incompatible or expensive.
The quest for feature parity is meant to the remove risk of losing business value while reducing costs by implementing a more modern tech stack. As we will review later, the problem is this approach vastly underestimates the complexity and duration required to achieve feature parity. 
Three main cost drivers of legacy software modernization are:
Hidden complexity of layered changes in the legacy application
Funding new product development in parallel to maintenance of the legacy product
Opportunity Cost of not developing for current and future user needs (because you are focused on historical needs)
For example, a 10-year-old product carries with it 10 years of iteration, including feature additions and improvements. Successful products hide complexity behind a simple user experience, layering on increased complexity over time. It’s highly unlikely to rebuild an aged product in 3-6 months. Instead, the effort will likely take 1-2 years for a simplified replacement.
Legacy products must be actively maintained in production environments while modernization work occurs in parallel, leading to duplication of maintenance costs and disruption to users straddling both systems. This requires the business to budget for the replacement initiative alongside maintaining the legacy product until the new product launches.
The cost to develop the new product and maintain the legacy one aren’t the only costs to consider. When teams are forced to prioritize replicating legacy features against building new features, innovation stagnates, reducing value delivered to the end user and opening the door for competitors to swoop in. To avoid this, companies often instead choose to innovate in the legacy product, which increases the scope and cost of the replacement product on an ongoing basis.
As years of complexity are investigated and new features are added to the legacy product, the scope and timeline for the replacement effort naturally expands. Suddenly the original timelines and budget for the project no longer make sense, but the business expects them to be maintained. The result is an overworked team trying to meet unrealistic deadlines.
Teams in this situation focus their efforts on opportunities to cut corners or remove scope rather than identifying whether the product they’re building is going to meet user needs and create value for the business. The timelines become more important than product success. This can lead to low morale on the delivery team, resulting in poor quality and higher team turnover. No Product Manager would knowingly accept ownership of a product like this.
Using lean methodologies for legacy modernization
To debunk the requirement for feature parity, Product Managers will have to address the primary need from the business that the new product must fully replace the legacy product when launched.
There are several seemingly valid reasons business leaders use to support their assertion, but If you look at each one closely, they start to fall apart.
Business Objection 1: Putting two different experiences in the same product in front of our users will be bad UX and bad for our brand.
Lean Product Rebuttal: Incrementally improving the experience in the product shows your users that their needs are being considered, and there will be more to come. This can generate deeper buy-in and increased adoption.
Business Objection 2: We don’t want to maintain two code bases at the same time. It’s too expensive.
Lean Product Rebuttal: If you aim for feature parity, you will end up maintaining multiple code bases for a few years regardless, so why not do so in a way that adds value sooner and drives innovation?
Business Objection 3: The new code base won’t ‘play nice’ with the legacy code base.
Lean Product Rebuttal: Making the new code base work with the legacy software may take more time, but it will greatly improve the product in the long run by enabling the product team to learn incrementally while replacing the legacy product.
Business Objection 4: Unless we have complete feature parity, we cannot guarantee that all functionality needs are met.
Lean Product Rebuttal: Your market, the available technical solutions, and business goals have evolved since the legacy system was created. Many functions may be obsolete. By focusing on the current priorities through lean discovery, you can invest in the features that will yield the highest value return, rather than assuming what worked originally is still valid.
Highlighting the pitfalls of feature parity isn’t enough. Product Managers must also show the business that lean product methodologies avoid these problems through a build-measure-learn approach with vertical cuts of product scope.
Build. Measure. Learn.
Effective product delivery is based on the premise that nothing adds value until it is in the user's hands, so the sooner it is live, the sooner users get the product’s benefit. The business also receives value when the product is used:
Revenue enabled by the product
User feedback and usage data
User feedback and usage data informs the Product Development team what is and is not adding value for the user. This enables a better product to be built going forward since those learnings can be incorporated into future development. This is commonly referred to as the Build-Measure-Learn cycle. Applying this cycle early in Product Development enables teams to make informed product decisions based on data gathered in the Measure and Learn phases. By vetting the solution to determine value (or lack thereof) using this method, the overall cost to market and risk is reduced, and business-fit is significantly increased.
The most effective release cadences divide scope into increments no larger than 3-4 months. By strategically reducing the risk incurred with each smaller release, the impact of a failed success metric is much smaller and reverting much simpler. In addition, this approach can identify poor product fit early in the process so that the solution can pivot to meet market needs with a smaller investment overhead, rather than once the entire budget and 1-2 year timeline have been exhausted.
Many organizations replacing or modernizing a legacy product reject the idea that a new version can be released if it lacks features from the older software. Product Managers can resolve this objection by delivering vertical slices of the product incrementally.
Develop software in vertical slices.
Taking a vertical slice of the product’s features means focusing on product depth in a focused area instead of product breadth across many features in incremental releases. Therefore, the initial release is a whole but functionally specific experience, including differentiators and delighters on top of basic, must-have capabilities. As an added benefit, release management will start when the product is straightforward, de-risking the problems inherent in big-bang releases.
Two primary reasons to avoid just implementing the minimum required features in the initial release are:
The product will not be well received by end users without enough features to support a full use case.
Comparing the new release to the legacy experience will not be apples to apples, so your success measures will be difficult to validate.
The idea is to take an isolated feature from the product to inform the MVP. Infuse the initial release with a manageable slice of the core capabilities, differentiators, and elements that delight users. Don’t forget to include analytics so you can track whether your release is successful or not against your product’s success metrics.
Once the initial release is live, start learning and iterating immediately. You may have up to three workstreams running simultaneously with:
Innovation & iteration on the newly released vertical slice
Replacement work for the next vertical slice of the legacy product
Innovation & iteration on the legacy code not yet replaced for business needs that must be addressed in the immediate-term
These three workstreams can prioritize achieving product goals over the timeline or the budget constraints, setting them up for success.
Mitigate risk and modernize legacy products successfully.
In the end, feature parity is an ill-suited strategy that increases cost and risk for product modernization efforts due to underestimation, scope creep, and negative impacts on delivery resources and execution. Instead, Product Managers should focus on generating user and singular business values sooner, which can be accomplished by incrementing the initial scope to a 3–4 month vertical slice and applying build-measure-learn release tactics.
The benefits of a lean product approach include:
The product gets to users sooner.
Teams focus on product value, not timeline or budget success, improving the product and team morale.
The product team can learn and make decisions based on user feedback while continuing to build additional product increments.
The business can de-prioritize initiatives with low ROI more quickly.
For more on lean methodologies and requirements, check out An in-depth guide to custom software development with Lean Requirements.
