Getting feedback from customers - appointing a champion within the team

In the previous post (Exposing team to customer feedback), I talked about how the team benefits from exposure to customer feedback and the problems that customers face in their regular workflow. In this post, I will take a specific point about the logistics of doing this and how to ensure that the team does not drop this concept of interacting with customers for getting their workflows, primarily through interacting with the customer support team.
One of the ways of ensuring that the process remains ongoing, that the team does not get tired of seeing these problems with customers in their workflows (from experience, it has been that direct ongoing interaction with customer support to get information about problems can get depressing to the team, just hearing about problems and more problems), that there is a controlled system of working this feedback into the schedule of the team members. Managers of these software teams do get involved, but it cannot be a manager driven, command ruled interaction with the customer support team.
One way of ensuring that the team remains involved with the customer issues, including with the customer support team, in a controlled manner, is by deputizing somebody from the team to handle this interaction and figure out the parameters by which the team would operate. The person who does this works with the customer interaction team (primarily the product support team in most cases), works out the schedule of such interaction, works out the prioritization of the issues that are thrown up about customer workflows, and tries to work out a system whereby problems are highlighted, as well as positive customer workflows feedback or any direct appreciation from the customers about the product or the development team directly (this needs to be genuine feedback, not something that is created to keep the team in good spirits; you would not believe how many times positive news is massaged to make the team happy).
This entire plan of what the person is expected to do, as well as a slight reduction in the work schedule of the person in order to give them time to handle this additional work of customer support interaction is something that would emphasize to the team the importance of this work. In addition, the managers should atleast have some critical items from the customer feedback that are meant for incorporation into the product, again emphasizing the importance of feedback from the customers. It would be ideal if the person who is appointed the champion gets some prioritized items and presents this to the team and the product manager.
The role of a champion for this effort is something that should be offered to the team, to any member of the team who wants to work on this. Even though the managers might have somebody in mind for this, they should let somebody else do this work unless the mismatch is too high. The position can be rotated at a regular interval, say maybe every quarter so that more people get exposure to this role and also more exposure to feedback from customers. 

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.