Knowledge sharing goes both ways: As critical as it is to get support information into the development cycle, knowledge generated during the product development cycle can be driven into support.
Posted Mar 1, 2004
Every interaction between a support engineer and a customer is potentially a way to lower costs and improve customer satisfaction with your company's products. All support needs to do get its voice to the table when product decisions are made.
What support should know about the product development cycle
As a support manager you can influence product decisions by understanding the development manager's point of view. A good reception for your information depends on knowing where a product is in the development cycle and providing the information that makes sense for that point in the cycle. In a support organization one day is pretty much like another in terms of fundamental work units, however, the work rhythm of a development team depends on where it is in the cycle. Timing is everything: If you try to approach a development manager with product feedback the day after Code Freeze, for example, your reception will be very different from the same conversation during requirements gathering. Every development team is a little different, so talk to yours and find out when it would be best to approach them.
Following are four stages that are appropriate starting points for a conversation with development.
The release of a product is a trade-off between when it will be released (time), the resources available (cost) and what it will include (scope). Something's got to give, and since time and cost are often a given, that leaves scope as the element over which there is the most control. Requirements gathering is the phase of the development cycle during which scope is determined. Since a good development organization will solicit information directly from customers or their proxy, you may already be involved in this stage. You can be most effective by providing information that will help development prioritize specific features and fixes. One way to do this is to link every customer-specific issue (incident management) with a knowledge-base article describing the underlying product issue (problem management), so you can report on how many times different customers encountered the same problem, even if they experienced it through different symptoms. This is the kind of information that will be truly useful to development managers as they prioritize the scope of the product release.
Change requests are made when someone wants to change the scope of a release. Everyone involved assesses the impact, risk, and benefit of the change, and makes a decision to do it or not. Change requests are opportunities to align development work with customer needs. Become involved in this processes and assess specific changes against support knowledge. You will represent the customer's perspective in these decisions, so it is important for you to use your own subjective experience, as well as the information you have collected from your incident and problem management processes.
The final phase of a release is communicating information about the release to customers. In the software world, for example, this can be done via a readme file. A developer often creates this document and may describe features and fixes without relation to the customer's workflow or symptoms. Ask the development manager if you can assist with release communication, and I promise you will be welcomed with open arms. You can add value by linking back the information provided by the developer to information that will help customers understand how you are changing your product. An easy way to do this is to integrate your incident-tracking system with your support knowledge base and provide a link to the knowledge base for each item being changed.
This one is a bit trickier, but can be very effective...again, if timed correctly. Most project managers hold a "post-mortem" shortly following the release of a product. The purpose of this meeting is to bring everyone involved on the project together to learn how to work more effectively on the next release. Encourage the manager to postpone this meeting until customers have had a chance to use the product a bit. Support can then attend and present a targeted report of top issues as tracked in your knowledge base. You will be able to provide contextual information about what customers were doing and the symptoms they experienced when the problems were discovered. This information can be added to a database of use cases that will make your quality assurance organization more effective and reduce calls to support in the long run.
One last thing to consider is that knowledge sharing goes both ways. As critical as it is to get support information into the development cycle, knowledge generated during the product development cycle can be driven into support. As you implement some of these ideas, I'm sure you will find ample opportunities to encourage development to do just this.
Sponsored By: Jacada, Avaya, Confirmit, inMoment and BoldChat
Sponsored By: Genesys, Avaya, Verint, and Aspect