Facilitate Knowledge Transfer in Online Communities

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

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