Suppose you are part of an application that has released several versions. What do you do about support for previous versions ? There is a strong temptation to set it such that most of the effort is focused towards creating great new versions for the ongoing and future versions, and if there is any support for the previous versions, a lot of that support will be focused on how to move the users to the latest version rather than really supporting them while they are using the previous version. After all, the money is to be made when users move to the latest version, and the more the support for the previous version, the more the cost of doing so.
However, this philosophy has underdone some changes in the last many years. No organization will directly accept that they do not provide good support to uses of previous versions, but at the same time, there are sizable costs associated with supporting users who are on previous versions. What are some of these costs ?
- One of these costs involve releasing patches and updates for these previous versions. When software has been developed and released, you would expect that there would be no real defects in software after it has been released, and hence there would not be the need for software patches on a regular basis. However, this is far from true. Once a software has been released, defects that were not found during the testing phase will pop up, either found by the team in the new version (but which also existed in the previous version), or found by users and affecting some of their workflows. Some of these defects would be serious enough that they need to be fixed - and in today's world where users can share problems and report lack of support by the organization on various social forum, it can be critical to continue to interact with users. As a result, the organization needs to evaluate such issues and be seen to be responsive.
And then there is the overall environment. There can be updates issued by the operating system or updates to other files that can cause problems. Once for example, an update issued by a popular anti-virus software caused some files in the application to get frozen, and that crippled a section of the software (which had been released 2 versions back). Like many such problems, these were reported by users who came across these issues (typically the users are able to see the problem, but to figure out the problem, there is a need to have some intense technical research done by the support team, sometimes backed up by the product team). If the product team allows such problems to continue on user forums without some obvious research or effort undertaken, it can lead to user dis-satisfaction. The organization could pretend that these were for previous versions of software and such problems are fixed in the latest versions, but such a defense is not easy to undertake and few users are convinced about such a reason. In fact, such a defense tends to put off users, who would think that they would also not be supported when such a problem is faced by them later on.
Read more about this complex topic in the next post on this series (TBD).
However, this philosophy has underdone some changes in the last many years. No organization will directly accept that they do not provide good support to uses of previous versions, but at the same time, there are sizable costs associated with supporting users who are on previous versions. What are some of these costs ?
- One of these costs involve releasing patches and updates for these previous versions. When software has been developed and released, you would expect that there would be no real defects in software after it has been released, and hence there would not be the need for software patches on a regular basis. However, this is far from true. Once a software has been released, defects that were not found during the testing phase will pop up, either found by the team in the new version (but which also existed in the previous version), or found by users and affecting some of their workflows. Some of these defects would be serious enough that they need to be fixed - and in today's world where users can share problems and report lack of support by the organization on various social forum, it can be critical to continue to interact with users. As a result, the organization needs to evaluate such issues and be seen to be responsive.
And then there is the overall environment. There can be updates issued by the operating system or updates to other files that can cause problems. Once for example, an update issued by a popular anti-virus software caused some files in the application to get frozen, and that crippled a section of the software (which had been released 2 versions back). Like many such problems, these were reported by users who came across these issues (typically the users are able to see the problem, but to figure out the problem, there is a need to have some intense technical research done by the support team, sometimes backed up by the product team). If the product team allows such problems to continue on user forums without some obvious research or effort undertaken, it can lead to user dis-satisfaction. The organization could pretend that these were for previous versions of software and such problems are fixed in the latest versions, but such a defense is not easy to undertake and few users are convinced about such a reason. In fact, such a defense tends to put off users, who would think that they would also not be supported when such a problem is faced by them later on.
Read more about this complex topic in the next post on this series (TBD).
No comments:
Post a Comment