How Frequent Should You Release Software Versions?

Reading time: 5 minutes

“How often should my company release new features for my software products?” and “How frequently should I release new versions?” are some of the questions I get all the time. Companies around the globe are responding to them with a wide range of approaches, making new releases with frequencies as high as every day and as low as every three and a half years. The question remains: how often should updates be released?

Too many software companies are not realizing that the frequency in which they release new versions of their products has a huge impact not only on the market appeal of their offerings (and, therefore, on revenue), but also on other aspects they care about: repeat business, costs, productivity, quality, customer satisfaction, partnership alignment and corporate communication.

Look around you. Is everyone using the latest versions of applications in their computers and phones? Benchmark more mature industries, such as the automotive. Do they make changes to their products every month? Similarly, does Apple release the really cool new software features for their devices in-between product releases? (Yes, Apple’s and car makers’ customers have to buy the new model, but you too may have to “sell” a new version to your customers, even if they pay an ongoing fee and are already entitled to it). Why the answer to those questions is “no” when they all could be so easily “yes”? Because “no” makes more market sense than “yes” in many situations.

Of course, there is no single right answer to the question title of this article. There are many more factors to consider in defining the best frequency to ship new or enhanced features than the so discussed agility to build and make them available to end users. Obviously, fixes for defects should be made available as soon as possible – even days may be too long. Applications that are highly intuitive, destined for the use of individuals, non-mission critical, with no plug-ins or similar implications, can also easily receive new features. What about complex, mission-critical applications, that are heavily personalized, customized, integrated with other software? Many times, these applications can significantly impact customers’ business processes, and often require great amounts of effort to train users and prepare everything that is required for the adoption of new features. For this type of products, too frequently I have seen software companies shoveling customers features in a frequency and amount they don’t really want.

But can more be less? The answer is yes. In the desire of delivering more features and benefits to their end users, too many times companies are offering their customers a disservice. Users don’t want to go through learning, analysis, updates of their personalization and customization, review of software interfaces, changes in their operating assets, and so on, at moments an upgrade is not desired, or at a cost higher than the benefit they perceive from the new features they are getting. Ask your friends why they are not using the latest software updates (for their operational systems, word processors, browsers or personal financial assistants) in their personal devices, no matter whether they are downloaded or used in the cloud. You probably will hear answers like “I haven’t had the time to check the new version” (it was not a priority), “I prefer the stability of the older version”, “I just learned the features of this version and don’t want to have to learn about the new one”, “the new version is or may be incompatible with the versions of the other applications I am using”, or even “my machine is slow and new features usually further slow it down”. In sum, customers often have good reasons for not wanting “those nice features”, when we want.

How to define the frequency of software releases

Then, if for so many types of applications, end users don’t want to receive new releases so frequently, why on earth are we throwing so many versions at them? The answer is simple: companies are not taking the time to analyze the entire life cycle of their products. They should understand better their customers’ overall needs, and orchestrate internal policies and processes to really offer more to the market, simplifying internal operations, improving revenue e reducing overall costs.

Providers of complex software products – especially enterprise solutions – should address the following operational and business matters when determining a frequency for new product releases:

Proper product testing, including functionality, usability, performance, integration, and security.
Producing and updating productization artifacts (such as user documentation and training materials).
Training effort for customers, internal teams and business partners (sales, services, and customer support personnel).
Personalization and customizations performed for, and by, customers.
Interdependencies and integrations with other applications, software components and hardware (market solutions, partnering solutions, customers’ home-grown software).
The life cycle of utilized basic software and related hardware.
Changes in regulatory requirements.
Impact on, and costs of, customer support and product maintenance.
Frequency and levels to which customers are comfortable in adopting new features.
Needs and ways to create a perception of evolution (needs for marketing communication, events, and splashes in general).

When reviewing the frequency for your product releases, consider the entire life cycle of your product, from product management and production to sales, services and customer support, without ever forgetting what your customer really wants. Lastly, remember: timing in marketing is as important as product features and quality.