I was inspired by the classic quote, “If I had more time, I would have written a shorter letter” *, which simply suggests that it takes more time and effort to deliver a concise, clearer message which is not distorted by irrelevant information. Applying this concept to a product can be rewarding for your customers and ensures that the features you maintain in production deserve to be there.
MVP is most probably an over-used term in the product world today, but it is still quite a powerful and efficient technique for good product development. I am not going to drone on about the benefits of having a clear, executable MVP, however, I will be highlighting a critical need for the active life-cycle management of features post-production. This is a key element for the dynamic application of any MVP. It is by no means a linear process.
Features that are not yielding any customer and/or business value should be removed. The core feature-set should be adjusted post-production and supplemented by what I like to call the FTOD (Feature Time of Death) approach. It is worth mentioning that I am referring to both B2C and B2B models, irrespective of whether it is Frontend, SaaS or DaaS products, etc. I am also not stating that these candidate features always belonged in “file 13” or a “circular file”, as these features would have been valuable at some point to serve a need, prove or disprove a concept, and essentially aid the evolution of a product through validation in production. Lessons learned from these features could lead to the next great feature.
Getting rid of code can usually be a difficult discussion to have, especially if a lot of time and effort went into features that need to be deprecated. If customer feedback and metrics are explicit about certain features that provide no value, then there is not much of a case to keep ‘deadwood’ in production. The impact of deleting features in production should not be underrated. This is still a change to the product ecosystem and needs to be validated post-FTOD. This change also needs to be supplemented with a solid proactive communication and risk mitigation plan. Good product people do not want to play Jenga with features in production! In most instances, the plan is usually organic and develops over time but the highest priority of all should be the need to get a usable refined solution in front of the intended consumer, as soon as possible. This will allow you to validate your hypotheses and adjust your plan based on reality.
Depending on the type of product, there are numerous options to reduce the overhead of deleting features in production. There are well-known proactive ways to ensure a smooth transition of features from active to inactive, once you have managed all stakeholder expectations. The end state, of course, is the deletion of features in production but these changes should always be tested in a non-production state before you promote them to feature-heaven. I will expand on a few options below that have worked for me in certain instances, but there will be better-suited approaches for different applications.
Fun with feature flags**
This is the middle ground where the ability to toggle features on or off is built into the solution. This also allows ultimate agility as you could ship before the market need and switch features on or off, on the fly. However, switching a feature off should not encourage feature-hoarding as features should still be deleted from production if they aren’t adding business value, or if they do not form part of a product’s future strategy.
This is not a new technique, however, it has evolved and become an extremely powerful mechanism to quickly test the market and settle on a strategy for your product. This could even lead to highly complex and customised market segmentation, which will allow you “act globally but think locally” for various market segments. Inversely it can be used to assess the impact of deleting features in a staggered and controlled manner which allows immediate validation depending on the implementation and your feedback mechanism. When deleting features, it is prudent not to apply a blanket rule to delete features across market segments, especially if there is uncertainty in the respective metrics. As an example, you could validate switching off a specific feature for a small percentage of your userbase in a geolocation with the lowest potential impact. Thereafter, assess the results before applying these changes across various user categories and/or geolocations.
There are many technical benefits of using microservices and qualified engineers could expand on this point further, but I wanted to highlight the flexibility and simplicity that could be built into a product offering from the start. Microservices enable a componentised implementation of different services that underpin your product and ensures that only relevant services are grouped together. You could essentially build in feature-blocks that allow the flexibility to manipulate the feature composition of your product without much pain. If you are considering deleting features and if you have isolated the relevant features, then microservices should allow you to easily assess the impact on your product prior to execution.
Make tech obsolescence your friend
Tech obsolescence could sometimes be an unfavorable task, but I see it as an opportunity and a leading indicator that your product is growing and there is a potential for improvement. Granted, some changes could purely be driven by compliance requirements or simply because certain systems will no longer be supported even though they are adequate for your immediate product needs. This still affords you the opportunity to re-evaluate the way a system or service enables your product, and every tech obsolescence initiative should ideally lead to a more efficient and refined iteration of your product, even if there aren’t any explicit functional/user-facing changes.
The FTOD (Feature Time of Death) approach could improve user experience, increase system performance and reduce testing effort (due to reduced complexity and a smaller regression suite). Your time to market will also improve and support your product’s overall agility, especially when your userbase increases exponentially. Building the right product is important but maintaining and improving feature sets post-production is just as important. It ensures that only valuable features survive for your customers. Hence, If I had more time, I would give you fewer, more meaningful features!
*Mark Twain is often given credit for this phrase, but various literature suggests that it was either Blaise Pascal, or Benjamin Franklin that should be accredited for this quote.
*The Big Bang Theory influenced my title for the “Fun with feature flags” paragraph, it was intentional.🙂