These are typically 2 separate teams. The product development team is the core team responsible for the development of the current and future versions of the product, while the tech support teams can be external to the company or employees of the company. They are typically expert in the area of tech support and handling interactions with the customer, and at the same time, have to be somewhat conversant with the features and workflows in the product as well as the common issues that customers face. The work of these two teams is not entirely separate, nor is it the same. In a number of companies, there is no interaction between these two teams, with the concept that the product team works on the current and future versions of the product, while the support team works on the released versions of the product, and really does not have anything to do with the ongoing versions of the product on which development work is happening. But, I would stipulate that teams that take this attitude are losing something that would help them a lot.
I have also seen groups and organizations that have brought together some interaction between these 2 teams in different ways.
– Members of the product development team go to the tech support site and listen into customer interactions on a regular basis
– The Tech Support team prepares a list of the common customer support problems they are hearing and presents this list to the product development team on a regular basis
– When a new feature development has happened and the product has been released, the product team does a walkthrough of the new features and workflows to the customer support team and answers all queries that they may have.
I have also seen some reluctance on the part of development teams to have an interaction with the customer support team on a regular basis; many of them do not appreciate the work being done by the support team and hence it is even more important for them to understand the need for the same. Why would you want to push such an interaction (including the steps as described above):
– When the customer support team provides such a list of issues and the top ones among those, the product team in some cases will dismiss them as something that cannot be removed, or design issues, or something similar. Put them onto hearing a call where some user is complaining about something, and they get a deeper perspective on the problems that the user is hearing, even if this is only for an hour or more.
– Getting teams to listen to customers is useful since it means that the teams can hear feedback from consumers that they would miss otherwise. My best moment was when the developer who had developed a specific feature spent some time to listening to customer feedback on that feature, and since most of the calls were with complaints, he got feedback on the problems with the feature, something which may not have been understood if it had come from a tester, or even in an email from the customer support team
– The top list of items from customer support provides a good guidance to the team and to the product manager about the common issues that the team should look at when it does work on optimization (rather than new feature work). The product manager can pick and choose from this list and determine the ones that would go into the list of features
– Closer interaction means that the team gets to know quickly about some hot problem that is coming through and which needs to be fixed quickly. Being part of such discussions means that the team can also spend time with the customer (or multiple customers) and understand the problems that the customer is facing.