It is one of the biggest challenges of software development companies. Over a period of time (years), there are different versions of the product that get released. The discussion that happens gets interesting when the company has to decide which previous version of the product needs to remain supported. It is not an easy decision for the company to decide whether to drop support for previous versions of the product; after all, when the company does decide to stop support for a previous version of the software product, there may be a number of users of that software who raise objections. I have worked with a team which had to make that decision on an ongoing basis. The team would release a software every 15 months which had tens of thousands of paying users, and it had been ongoing for more than a decade. As a result, software was being supported that was released more than a decade back. A long time back, when the company had decided that software support would be stopped when the product was released more than 5 years ago, there was a firestorm released onto the support forums and other networks, and had the potential to be damaging PR. As a result, the company decided to reverse the process of dropping support without getting much more data. During the analysis of this decision and the reversal, it was clear that the data for this decision was not really analysed to the level it was expected to be. It was decided that the next time that this decision of dropping support was to be taken, it would need to be done only when there was adequate data for the same; or at least much more analysis of the decision.
What needed to be done ? Well, the basic data for taking such an decision would be to determine how many users of that particular product version were still there, and what percentage of the total users were still there on that particular version. It would be easier if the instrumentation for this was built into the various products; in which case, it is a matter of building the analysis that takes the data from the different software product versions out there in the market and determines the percentage of users who are still using the different software versions out there. What we finally decided was that once the percentage of users of a previous software version dropped to below 4% and it was the software version that was released the earliest, we would start notifying users, going to support forums and the various social networks to explain the reason for dropping support, providing the users with an upgrade path and the proper explanation for the reason for dropping support.
When this decision is communicated many weeks or months in advance of the timeline, it helps the users to come out in favor or against the decision and lets the team react to these and provide the explanation for the same. Once this kind of discussion happens, it lets many users understand the basis for the decision and maybe even accept it (a lot of users just want to understand why something like this has taken place).
Dropping support for a software version is complicated, we will need more posts to walk through the reasoning and the reasons for the same. Look forward to the next post in this series (Part 2)
What needed to be done ? Well, the basic data for taking such an decision would be to determine how many users of that particular product version were still there, and what percentage of the total users were still there on that particular version. It would be easier if the instrumentation for this was built into the various products; in which case, it is a matter of building the analysis that takes the data from the different software product versions out there in the market and determines the percentage of users who are still using the different software versions out there. What we finally decided was that once the percentage of users of a previous software version dropped to below 4% and it was the software version that was released the earliest, we would start notifying users, going to support forums and the various social networks to explain the reason for dropping support, providing the users with an upgrade path and the proper explanation for the reason for dropping support.
When this decision is communicated many weeks or months in advance of the timeline, it helps the users to come out in favor or against the decision and lets the team react to these and provide the explanation for the same. Once this kind of discussion happens, it lets many users understand the basis for the decision and maybe even accept it (a lot of users just want to understand why something like this has taken place).
Dropping support for a software version is complicated, we will need more posts to walk through the reasoning and the reasons for the same. Look forward to the next post in this series (Part 2)
No comments:
Post a Comment