Friday, August 03, 2007 11:22 AM
Kevin Beares
Enabling a broad feedback channel to the Windows Home Server team and SBS team via MS Connect for RTM releases
So, how do you provide feedback to Microsoft today? What I am talking about when I say feedback is a bug or a suggestion like you would on a beta. I know that participating in a Beta like the Windows Home Server Beta is one way to get in your suggestions and bugs to the product team, but how do you do it on RTM product? For this conversation I want to focus completely on simply providing feedback to Microsoft to improve the quality of the product.
Now, I want to immediately remove one scenario from this discussion. The scenario is a bug that is impacting you today that you cannot get around and you need help. In these cases, you should always get help from either Microsoft Customer Support Services (CSS) or another Microsoft Partner or Consultant.
The methods that I know of that exist today for providing feedback to the Microsoft Product teams are the following:
- Newsgroup or Web Forum. You can post a suggestion or bug in a newsgroup or Web Forum and hope that the thread attracks enough attention that someone at Microsoft or someone like an MVP or a Microsoft Partner pick it up and do something about it. The problem with this technique is that is unreliable, and is inconsistent. The other problem is that it is not a communication technique that allows for the loop to be closed on the feedback. The customer is left with an empty feeling in their stomach because while they may have gotten the issue off their chest, there is no closure in most cases.
- Blog or Personal Web Page. Of course you can always get the issue off your chest by blogging about it. But again, for the same reasons as I mention above this is not a very reliable technique and the there is no closure. The only exception is when your blog or web site has a Big Audience. In these cases, usually issues raised on these very influencial community sites get Microsoft's attention. The funny thing is, usually these people already have an inside track and usually do not blog about it first.They usually just their contacts within Microsoft to get an issue raised. The problem with this technique is it really the voice of the customer or just a vocal minority. In cases where the feedback comes from an MVP or someone who is a very prominent member in the community, the feedback is usually spot on because these individuals have gotten pretty adept at triaginig everything they have read out on the net and been able to raise the issue that they see as the most pressing.
- As I mentioned above, you can always engage with CSS for a bug or suggestion even if the intent of the feedback you want to provide is to simply pass along an idea or an observation. The two options you have with CSS is either pay Microsoft for the case or send a letter. With the pay option you will get a full refund if your situation is indeed a bug, but in the case of a suggestion your only option is to send a letter. With this option CSS will research your bug all the way through and the benefit of this technique is that you do get closure most of the time. You will at least get a explanation of what Microsoft plans to do about the bug. The letter option is kind of like option 1 and 2 above. It makes it to the team, but there is no closure. It is kind of like MSWish used to be.
- So, last, but not least. In some cases, some teams are using MS Connect for enabling feedback with their customer base. The only two that I know of today is the Visual Studio Team and the Microsoft Operations Manager (MOM) team. I was responsible for the MOM team turning on MS Connect for the general public. What is interesting about this technique is that the two teams each have taken different approaches to this channel of feedback. In the case of MOM, the volume is so low, they simply roll the feedback up into their Sustaining Engineering team. In the case of Visual Studio, from what I understand, they have a team that helps triage and look at the feedback. They give feedback to the customers on what they are doing with the feedback and they also get the issues onto the teams radar.
So, here is what I am thinking. I would like to enable the last option of turning on MS Connect to the general public for Windows Home Server RTM and also Small Business Server R2 RTM this year. So, why haven't I done it already you ask? I think it all comes down to bacisally 2 to 3 issues/points of discussion that are all related to one another and overlap in a number of ways;
- How do you prevent this solution from being a black hole? The fear is about setting expectations with the community. If you provide this channel to the community, how do set and meet the expectations? I think a lot of people on the product team side of the fence believe that if we enable this feedback channel, each and every issue needs to be responded to. I think this is a unfair expectation that the product team puts on itself. I do not think that the community actually realistically believes that we have the ability to simply staff enough people on our team to handle any and all feedback on a one for one basis especially in the case of our mainstream products like Windows Server and Office. I think Windows Home Server and SBS fall into the mainstream bucket. In the case of the MOM product which I already mentioned is using Connect to capture feedback on their RTM product, they get about 5 pieces of feedback a week which actually scales for them where they can handle and respond to each piece of feedback on a one for one basis.
- How do you staff/fund it? This to me is a pretty interesting discussion if you actually manage the expectations of the customers from the first point above. If we told the community at large that we want your feedback and we are providing a channel for you to communicate this feeback, but we have a a few rules for this feedback would the community have an issue with it?
- What if we said for example that we will only look at a bug feedback item that has a minimum of 10 votes, has an aveage rating of 4 or above and 5 validations at minimum? And that if you want to get the bug to meet this bar, you have to help us get the votes, rating and validations? You all already know how to do this today. You post a link to the bug on Connect on the web forum/newsgroup and/or blog and you ask people to weigh in on the feedback item.
- Would the community really have an issue with this? We at least are providing a way for feedback to be logged, tracked, triaged, and responded to on a very large scale unlike any of the other techniques mentioned above. The other important point is that the throttle can be adjusted. If the throttle is too wide open and we get overwhelmed we can always pull back and require more votes and/or a higher average rating, and/or a higher number of validations. Conversely, we could always open the throttle wider if we could handle a larger volume.
- What is the process for handling this feedback? Who is going to watch this channel and be on the hook to respond to the issues? I touched upon this before, but if we were to set the expectation of the customer, and if we could throttle the level of feedback that is coming in from the community, what do we do with the feedback? I think it is pretty simple from this point. If we meet the first two points above, the need for additional staff is not necessary. The existing Sustaining Engineering and Product teams should be able to absorb this additional channel with only minimal amount of adjustments to their process because the feedback is being throttled.
There are a number of side benefits of doing this:
- There is a single place where all community feedback lives.
- The loop can be closed for the issues that are looked at by the product team.
- The SE, CSS, and Product teams can look at this feedback at any time to gain additional knowledge of the issues that are effecting the community.
- In the case of SE, this could potentially shorten the time to resolution on an issue that came in from CSS. They be working on a case that they do not have enough information to go on. If they had a database of bugs that came in via the Connect channel there may find a bug that is very similar if not the same that had the additional information that could help them resolve the case faster.
So, what I need from you is a thumbs up/ thumbs down on this idea. What do you all think about this idea?
Thanks for listening.
Kevin Beares
Community Lead
WSSG (Windows Home Server, SBS, Centro)