Preparing a plan for ensuring customer feedback reaches the software team

This post is not really going to lay out a plan for how to get customer feedback to the software development team. There are a large number of expert posts and articles that talk about different models of how to get customer feedback to the team, as well as different levels of interaction; this could be a high level of interaction or a summary level kind of detached level of information. The post is more about the imperative of ensuring that the software development team does get some kind of customer feedback, and in a structured way that continues even with changes in the team.
It is necessary for team members to be exposed to some amount of customer feedback, with the level of exposure being decided by the managers of the team; as well as the number of members of the team who are exposed to such feedback.
An important question is about why the team members need to be exposed to customer feedback; after all, in the classical definition of the processes of the team, the product manager is the one who is exposed to customer feedback, massages it to the appropriate functional change or addition and then puts this to the team in terms of the prioritization of this feature vs. other features; or classifies this as a defect which needs to be fixed, again as per prioritization.
However, the classical model needs to be changed. I have seen how exposure to customer feedback changes the way that the team works, their responses to defects, and the eagerness in some of the team members to get more involved with some amount of customer interaction. The biggest advantage comes in terms of getting more acquainted with the customer mind. In some cases, the shock when the team members realize that a defect that they had ignored as minor got some customers really hassled. In one case, the defect was raised to the company management through outside means and came down to the development team as a must fix; when the product manager saw the defect, there was some amount of discussion because this was a defect that had been raised earlier but had been dismissed since it was deemed as too minor and even more surprising, not really impacting customer workflows.
Even senior engineers on the development team have seen jarring signals, whereby the features they worked hard on and pushed a lot, were not really seen as important by the customer while the changes in some of the workflows that was prioritized as higher by the product management was appreciated in customer feedback mechanisms. What this did was ensured that the senior members of the team understood that they need to setup a regular structure of how to get customer workflow, as well as listen more to the product managers. This is even more important when you have development team members who have been there for a long time while there have been changes in the product management team.
Another advantage of getting customer feedback through some kind of mechanism is that the team will also get more acquainted with the people who actually interact with the customers, whether this be the customer support team or some similar kind of support mechanism, and this kind of interaction helps the team do question and answer where they learn even more of the kind of common problems that customers have in terms of workflows, and makes them more receptive to requests for changes in workflow rather than introducing new features.

Supporting a previous version of the product - level of support

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).