Facilitate Knowledge Transfer in Online Communities
I'm often asked how products teams can best participate in their online communities. It would be simple to say "go talk to customers" and be done with it, but you can have a more targeted approach than that.
They key to successful support communities is facilitating knowledge transfer between those with product expertise and a customer set who uses the product. Today the process of knowledge transfer from Microsoft to customers is slow because we create artificial barriers by not investing in, supporting, or measuring the success of community support channels.
This following model describes an example of an ideal flow of information throughout a product lifecycle where knowledge starts in the hands of the product groups, transitions to top customers and support representatives, and finally transfers to a much broader customer set until customers know more about the products we shipped than we do anymore. See the end of this post for an example of the initiatives and goals that could be applied over the lifecycle of a product.
*Although it looks like the product groups have to bear a large “support burden” early in the cycle, the actual volume of support requests into the online system is very low until the product is shipped.
**Volume trend based on web forum and newsgroup data for developer products.
There are several initiatives that can be driven in order to achieve the ideal knowledge transfer that’s demonstrated in the model, including:
Forum Question Answering
Providing great answers to questions that are asked early in the product cycle seeds QnA systems with content that can be reused by your community to provide the bulk of your answers after the product have shipped.Throughout the cycle you should focus your attention on the most difficult questions by giving customers a 24-48 hour window to answer before we get engaged the questions.
In Developer Division we’ve goaled that 80% all questions would receive a validated answer in fewer than 7 days. A healthy community will answer 60% of the questions in fewer than 2 days after the product has shipped.In order to achieve these goals, it will require engagement from product team members during the product development cycle in, funding a support team that assists in question answering while the community is scaling up, and a variety of other engagement strategies that are best described in their own post. There is no silver bullet for answering questions in support communities and you are going to have to do a little bit of everything.
Pilot programs with product support in Developer Division have shown that filling in that question gap above is very possible with relatively minimal effort.
Supplementing answers will not only mean you've generated more content, but we’ve seen that, with each increase in answer rate, there will also be a corresponding increase in readership and participation. This means that you will start pulling more people into the category of customers who show a significant satisfaction uplift when they are engaged in online communities.
Public Feedback & Workaround Publishing
Why wait for someone to call about a problem before you author a solution? Since the alpha of Visual Studio 2005, Developer Division has had a public bug database. We’ve kept it open since the release of VS 2005, and we continue to receive customer feedback. One of the hidden features of this bug database is that customers can submit workarounds to the problems which are reported.
Without any proactive effort to drive the creation of workarounds there were 732 customer created solutions in FY06 for the 12,176 bugs and suggestions that we did not address through a product release. To put that number in perspective our own publishing only covered around 200 KB articles in the same time. The community beat us by almost a factor of 4! To make up the difference today and publish the remaining workarounds it would cost us $120,619. You also get the added benefit of these solutions being published publicly as replies to the bug report. However, you should also encourage this behavior from customers by making it easier for them to publish and highlighting the most critical solutions until a real fix is released.
Training Needs Identification & Publication
Feedback and Forum systems excel at delivering reactive support, but you need to pro-actively identify the documentation and training needs of our products. Similar to performing a threat analysis as part of specifying a feature, a “training needs analysis” should also be conducted.
Each specification generated could identify at least one training opportunity ranked by an analysis of task difficulty and newness. Then training should be published for each release of the product that addresses the high priority training needs. A great example of complimentary content can be seen on the ASP.NET site.
Today these efforts are done on an ad-hoc basis by teams but are quickly becoming a best practice. It’s not uncommon for a team to spend a couple of hours producing a video that will be watched over 14 thousand times. You should seek to standardize a process that identifies these needs up-front, so this content can sim-ship with product releases. Time to start working on Oracs training materials. :-)
Transparency with Specifications and Product Plans
Product plans and specifications can be reviewed by product influencers such as our MVPs. Doing so means that these influencers will be able to start learning about the product before any code is written and they will also give you invaluable feedback that may head off issues before a workaround is needed.
Conclusion
In the end the slide I put up for product teams has three key messages:
- Monitor community health for released and unreleased technologies
- Be primary experts on new technologies & transfer our knowledge to influencers while focusing on escalations and difficult unanswered questions
- Support released technologies by filling in CSS and MVP knowledge gaps and proactively providing training opportunities.
Post Appendix
Structured Knowledge Transfer Initiative Example Goals
Keep in mind that these are only suggestions and example goals. I also can't claim that we've hit 100% of these goals, but they are all very possible and have ben proven individually by teams in Developer Division.
1. During Planning
Review Product Plans & Specifications: During product planning MVPs and key partners must review and sign off on product plans & specifications. Respond to 100% of feedback within 7 days
2. In the CTP Phase
Training: Identify training needs by reviewing product level scenarios & feature specifications. All specifications contain a “Customer Readiness Estimate” that will help identify training opportunities.
Spec Sharing: Share 100% of specifications with all customers as features come online in public CTPs and respond to all the feedback within 7 days. You won't get as much as you think. :-)
Forums: Create public question and answer forums and engage product team members to ensure an 80% 7 day answer rate.
Feedback: Open a public bug & suggestion database where customers can post workarounds and vote & fix all fixable issues that generate 90% of the votes
3. Betas & RCs
Workaround Publishing: It’s likely now that bugs and suggestions are not fixable so goal that 100% of valid bugs and suggestions that aren’t fixed have workarounds.
Forums: Maintain an 80% 7 day answer rate and start engaging your product support team to deal with the ramp up knowledge gap in your customer communities. This gap is your enemy in the first two years and must be nipped early. :-)
Training: Product training published. Example: See the recent releases of the ASP.NET Ajax how to videos. 100% of the training published as screencasts on a Microsoft web presence.
4. RTM to RTM + 1 Year
Workaround Publishing: Continue to provide workarounds to customer feedback that’s not addressed in a service pack or other out of band release.
Forums: Enable escalations from peer to peer support to your experts (internal or external). Start measuring 2 day answer rate and goal at 60%. Share your goals with your customer community.
Training: Open training request database and enable customers to self publish training videos on the web site that others can watch. Drive training generation to address 90% of the top voted requests.
Workarounds: 100% of bugs and suggestions that aren’t fixed have workarounds.
5. RTM + 1 RTM + 5 Years
Forums: Product team members are now only engaged to handle escalations from support or key customers on released product questions. Product groups answer 100% of escalations in < 4 days.
Feedback: Support teams now provide 100% responses to and triage customer feedback to ensure repros before sending to PG teams for inclusion in service packs or V.Next products.
6. 5 Years to End of Life
Forums: Support teams now engaged only to handle only “paid for” escalations.
Feedback: Support and product groups only review the top 10% of voted feedback issues for possible hotfix releases.
Goals: Drive for increased customer contributions in all areas.