In previous posts in this series (Supporting previous versions of the software (Part 4)), we have talked about how an organization makes the decision to remove support for a (much older) previous version of the software. Removing support means that customers are encouraged to move to a higher version, defect fixes are not provided and the support team will not take any more calls on that version. This can get tricky, and sometimes the decision is not all that clear as to whether the support would be withdrawn.
For removing support for a previous version of the software, the groups that typically advocate removing this support are the development and testing teams; the number of previous versions of the software that remain supported in the market, the more effort they need to put in. For example, just as an example, there are a lot of compatibility issues that need to be developed and tested, and these increase as the number of previous versions are supported. Another example would be the support team, since they have to keep a track of issues, defects, notes, and other items for all the previously supported versions. However, when you look at product management and marketing, they have a lot more contact with customers, and they are able to better figure out whether it is possible to drop support or not.
I am going to try to layout some reasons where the team took the call regarding whether to drop support and decided that they cannot drop support as of now. Here are some of the reasons (and this cannot be a comprehensive list, more based on my experience in the industry).
- Too many users complaining about support being withdrawn: This happens when the team informs people through support forums and the helpdesk that they are planning to drop support. If there is significant push back (and discussions with some those protesting reveals that they are really going to be impacted), then the organization may decide to not drop support as of now.
- Previous deals commit support for an extended period of time: This happens typically in the case of OEM's or when there is a large deal. As part of the deal, support was required for 5 years after the launch of a version, and this grew tricky in the years to come. But we were bound by this condition, and the only learning was to be more careful of the implications of providing support for extended periods of time.
- The Product Management / Marketing looks at data, looks at support discussions, user forums and decides that the level of discussion is still fairly high enough that the support needs to remain for some more time.
- Data from metrics reveals that the understanding of the team was incorrect regarding the number of people still using the software and the data reveals more people that are using the software. In this case, it could still mean drop of support along with an offer for those people using the older software to get some concessions when they are upgrading to the latest version.
Read the next version of this series (Supporting previous versions of the software (Part 6))
For removing support for a previous version of the software, the groups that typically advocate removing this support are the development and testing teams; the number of previous versions of the software that remain supported in the market, the more effort they need to put in. For example, just as an example, there are a lot of compatibility issues that need to be developed and tested, and these increase as the number of previous versions are supported. Another example would be the support team, since they have to keep a track of issues, defects, notes, and other items for all the previously supported versions. However, when you look at product management and marketing, they have a lot more contact with customers, and they are able to better figure out whether it is possible to drop support or not.
I am going to try to layout some reasons where the team took the call regarding whether to drop support and decided that they cannot drop support as of now. Here are some of the reasons (and this cannot be a comprehensive list, more based on my experience in the industry).
- Too many users complaining about support being withdrawn: This happens when the team informs people through support forums and the helpdesk that they are planning to drop support. If there is significant push back (and discussions with some those protesting reveals that they are really going to be impacted), then the organization may decide to not drop support as of now.
- Previous deals commit support for an extended period of time: This happens typically in the case of OEM's or when there is a large deal. As part of the deal, support was required for 5 years after the launch of a version, and this grew tricky in the years to come. But we were bound by this condition, and the only learning was to be more careful of the implications of providing support for extended periods of time.
- The Product Management / Marketing looks at data, looks at support discussions, user forums and decides that the level of discussion is still fairly high enough that the support needs to remain for some more time.
- Data from metrics reveals that the understanding of the team was incorrect regarding the number of people still using the software and the data reveals more people that are using the software. In this case, it could still mean drop of support along with an offer for those people using the older software to get some concessions when they are upgrading to the latest version.
Read the next version of this series (Supporting previous versions of the software (Part 6))
No comments:
Post a Comment