Skip to main content

Maintaining multiple versions of a product

A product team , when it has more than one client, faces a challenge when it has to maintain multiple versions of the product.

Typically the implementation team would have made some customizations for every installation for the product. However, when they release a new update, they struggle to make it work for all the products since there are customizations and the new update might not be compatible.

There are several considerations that a product manager needs to take while deciding on the product strategy.

Saas versus Installation

Having a saas product makes it easier for the engineering team to push updates. If it is a installer distribution, There are the team will face challenges with distribution. Compatibility is also an issue.

The biggest issue however, from the user perspective, is data migration from the previous version to current version. The best way out of this is to make it a service as well. You can decide whether you want the customer to pay for that or not

Update versus Upgrade

There is no one correct definition for either of these 2 terms.

For the current product team that I am working, we have decided the following:

Upgrade: Any introduction of a major functional feature. This would involve significant changes in the product and there typically would be a need for the users to be retrained. Further there would be a need for data migration from earlier versions to current versions.

Update: This is a minor update that would be addressing smaller sets of feedback or any defects in the product. This would typically be handed out free. There would be no need for data migration and all the data that used to work in the previous version should work in the current version as well.

When we release an upgrade, we have to be careful on how many users are ready to switch to the latest version

Support for older versions

When we release new versions, we also need to understand how much concurrent versions can be supported. Sometimes this could be a cost in itself.

To handle this issue, our product team has decided on the following:
  • We will always handle only 2-3 versions old
  • If a version has less than 5% users we will stop supporting it actively
  • In case there are users that are still in older versions, we will allow them to upgrade freely.
Why would we allow them to upgrade freely?

This is so because we have found that the cost of support is far more than the cost of the upgrade. Hence, we reduce the cost of support by allowing for free upgrade.

Frequency of Updates and Upgrades

The updates can be as frequent as possible. Right here we are thinking of around 4-6 weeks between updates.

Upgrades , however, need more time. We have currently not reached a stage of maturity to release an upgrade yet. Based on our initial plan, we plan to release an upgrade every 12-14 months.

Why is this important?

The upgrade frequency is important for the users for the following reasons:
  • It gives them a visibility of what is going to come and when
  • It ties well with their business calendar and the new upgrade satisfies their new business needs
With all these considerations, the product manager needs to be able to handle support for multiple versions of a product.

Comments

Popular posts from this blog

Principles for developing systems that are anti-fragile

I have been trying to make sense of what anti-fragility means and how do I use that in my day job. As a Business Principal, I tend to work with the abstract but orchestrate a program of work that needs details. This makes my job a little difficult in the terms of designing for more self-preserving systems that preserve the spirit of the abstracted strategy or vision. I came across an article from Daniel Russo on anti-fragility and his attempt at creating a manifesto similar to the manifesto for agile software development. For more reading on Daniel Russo, here is his profile:  http://djrusso.github.io More reading from his paper here:  https://www.sciencedirect.com/science/article/pii/S1877050916302290 This post is an attempt for me to understand what goes into developing a program that uses every opportunity to strengthen itself and achieve its objective - the vision.  I liked the approach of principles for developing systems that are anti-fragile. It i...

Designing for Accessibility

The software world has starting being more inclusive. After serving only the geeks and the techies, a lot of the software that is produced in this world has started looking at how it can be mor euseful. One of the key constituencies of software usage is people with disability. The ADA (Americans with disability Act) has forced a lot of the software developers to look at this issue. The software world has also responded sensitively and with care making as much of the software usable by people with disability. One of the key components that we are looking at in this are people with visual impairment. Over a period of time, a lot of the software has made sure that the user experience is adjusted in such a way that is is intuitive. Google has been a front runner in this and a lot of others are also not left behind. Text The size and the font typology is very important. Choose those aspects with ADA in mind. Media like Images A lot of the media , including video and images ,...

Public Policy and Software Development practices- Convergence

My last 2 posts on public policy discussed on the need to revisit our public policy making process and how it can be mapped to software development . There are a few areas that I would love to focus on for convergence of policy making process and software development process. To provide some context on what is really happening in policy making today, please check this video out.