Any developing product requires new version releases. This applies to websites, computer software, and mobile apps. Sometimes, the update can be significant and noticeable to everyone, and sometimes, developers prefer to release a series of subtle minor improvements. These are the two main approaches at the moment.
It often happens that the product is modified faster than users can manage to make sense of its existing capabilities, leaving the new ones alone. I am convinced that this approach to software development is obsolete and has many flaws.
It is best to act on the one step at a time principle rather than prepare one major update. In the article below, I will tell you about the basic risks associated with major updates for IT products.
Users have to get used to the new version
Over time, users develop their own model of interaction with the product. They establish a habit, and it is easy for them to find the necessary function as they remember its exact location very well.
When a product undergoes dramatic modifications, the behavioral pattern collapses — a certain barrier appears and requires time to explore all that has changed, and restructure the habits that have been established. Some users may eventually abandon the new version, and some will think: “Why was this done? What was the reason?”
Frequently, the media posts stories telling about significant audience losses incurred by companies that have decided to make such dramatic changes.
Difficult to track modification efficiency
As a rule, a large product release version includes the great number of modifications, making it hard to understand how efficient each of them is if taken separately.
Even if new features or enhancements are good as they are, they may not work properly in combination with other options. It is difficult to conduct a clean split test that could show exactly why the new version is better than the old one, and what is most important, to comprehend what influenced it.
To evaluate the benefits of any process improvement activity, it is necessary to clearly measure the impact of specific modifications. The complex nature of software development means that it is unrealistic to achieve an optimal condition with a single action. Consequently, those who adhere to a multi-stage or iterative approach will eventually gain an advantage.
There is a risk of losing something important
Large companies and projects build their interactions with users over the years, sometimes even decades. It is a subtle and very complex mechanism. Everyone has already forgotten why some things work. They just work — that is all.
When the new version is launched, something may get lost and stop working. Moreover, technically everything may be in order. However, productivity indicators are different.
In this situation, it will be quite difficult to find out what exactly went wrong and what led to the product’s deterioration instead of improvement.
Inevitable issues and flaws
There is no test to make sure the product is completely free of errors and issues before the release. One way or another, it will turn out that something is not working the way it should.
If an app cannot pass some test or a certain function stops working during the development process, it is much easier to find the cause when you made modifications to just one part of the code. Do one thing, make sure it works, and then repeat the action.
Some things can be tested exclusively in real operation processes and real loads. Regardless, the process of fighting various flaws will take place after the launch.
If the flaws are multiple, the usual operations of the company halt and unforeseen tasks arise. What are the consequences? The company loses time and money, and in some cases, its reputation may suffer as well.
The company has either to deal with these losses or accept them. A rollback to the old version is often a complicated step and not everyone would dare to take it.
Increase support costs
While creating a new version of the IT product, the developers carry out double work: in addition to working on a future release, it is necessary to spend time and energy on current version support. This is a difficult and stressful work schedule for the entire project team, and it can go on for a very long time.
If you focus your efforts on improvements for the current version, you can receive significantly better results. Leave the risks connected with incorrect design of a new version alone, which can result in its complete inoperability.
It is easier to test single components for operability than to check the entire project. The more thoroughly you test such single components in the system, the more time you will save in the future.
If you start debugging interoperability among separate components after a major update, you may end up with serious negative consequences.
Once again, iterative and fully controlled work with the current product version allows you to avoid this risk.
Let us summarize
Now, having read this article, you understand that all the possible flaws related to a large product update release are potentially capable of neutralizing all the advantages the new version may have. Moreover, it is hard to completely avoid such a situation.
In the IT area, you can find plenty of examples where new product releases feature a completely unrecognizable interface, remove functionality familiar to the user, and lead to profit and audience losses. At best, if there was a clear need for fundamental modifications, the developers at least should leave the opportunity for users to roll back to the old version.
Prior to planning a large-scale update, it is worth thinking everything over thoroughly and knowing if it is possible to do without it. It is much better to implement all the modifications gradually and move forward one step at a time.
Author: Petro Kovalchuk
The founder and CEO of Lvivity, which specializes in developing software for customers around the world. He has 10 years of experience in the IT industry and specializes in .NET development. Petro enjoys helping entrepreneurs make their ideas become a reality!
