Feedback and Microsoft
I have an interesting job. I write software that helps Microsoft manage feedback and connect with customers in a meaningful way. That may sound like marketing-speak, but it's true.
I've found that in my time here, I've learned a huge amount about how "feedback" works. One of the first things I had to do was to re-evaluate my own idea of what the term means. I thought that it just meant that someone could send a note and it would be read. Now, I hadn't come up with some formal definition as such, that's just what my perception of the term meant when I examined it.
Of course, it's a much larger concept. And defining exactly what it means is one of the core challenges to doing what I do. It's not enough to say "we'll set up a form and people can fill it out", or to set up a system where people can submit bug reports that go straight to internal bug tracking. That's not going to work. It may work from the customer's perspective, which is great- but if it doesn't actually help Microsoft create better products, or even hinders that process, it's broken.
I'm still new enough at this company to have been using Microsoft products for much longer than I've been working here- and I recall my perceptions of Microsoft as a company at times. By many customers, Microsoft is perceived as being a large, monolithic entity with no interest in individual customers or their experiences- only in the aggregate.
There's a syndrome I call the "black hole effect" when it comes to large companies and feedback. It's the perception- warranted or not- that feedback goes into a black hole when you provide it. Any responses that manage to eke their way outside that event horizon are rare indeed. It's not always easy to identify who you should send an email to, or who has the information you need.
In other words, many of our customers don't think we read or respond to feedback. So they don't bother to provide it. Of course, there's another side to this coin. The problem of the "fire hose effect".
What happens if a product team puts out a beta and solicits feedback, and then can't close the loop with the customer simply because of sheer volume? When you can get 1500 bug reports in one day- for one feature area of one product- that is a huge burden on any triage team. Pretty soon, the process will be dropped because it's simply not manageable. And then the loop is broken- customers are back to "throwing it into the black hole".
So, the problem is to manage feedback in such a manner as to allow:
- Large numbers of customers to communicate with small numbers of product team members in a meaningful fashion.
- Small numbers of product team members to communicate with large numbers of customers in a meaningful fashion (yes, these are two separate problems).
- Actual collaboration between customers and product teams, so that the customer's needs, desires and insights actually contribute to the product.
- Closing of the loop with each and every customer. Nobody's going to bother continuing to provide feedback or bug reports if they don't get any acknowledgement that they're actually contributing in some manner.
So exactly how do you set up a system where you have ten, twenty- a thousand- customers per developer/tester, and they all have something to say? How do you parse that feedback so it's actually useful and allow the team to close that loop- the most critical part of the process- with the customer?
