Piercing the veil

Corporations are rarely transparent in their operations, and Microsoft is no exception. It has historically difficult to understand exactly Microsoft was doing to address specific customer desires or complaints. Previously, the ways you might have been able to talk to Microsoft were:

• Writing to MSWish - despite being monitored, user rarely got any feedback as to whether their bug was to be fixed or their feature suggestion taken into account other than the boilerplate text. [NOTE: MSWish is no longer operational at this time.]


• Talking to PSS - complaints or feature requests get filtered through this organization, and instead of producing qualitative suggestions to the teams, more often they'd be quantitative suggestions (e.g., this feature area got a lot of calls). Talking to PSS costs both the user and Microsoft money. Users are disinclined to call unless they can't solve their problem in some other way, so we miss feedback. Microsoft is financially incented to reduce PSS calls; better products is just one possible side-effect.¹ All told, a user won't know that their commentary is going to get used or not.


• Talking to TAMs - Technical Account Managers handle the big accounts at Microsoft, and as such you're already a special class of user. You have more pull, but you're paying for the privilege, and the prospect of future purchases keeps our attention.


• Writing to Newsgroups/Forums - There's a fair amount of people willing to aid those who use our products who write to newsgroups, but quite a few of them are not Microsoft employees. Some of them are MVPs, who are well informed and intelligently summarize major problems back to the product teams. Some Microsoftees monitor the lists, either as part of community outreach, or ad hoc, but engage individual users rarely.

With the exception of the TAMs, the general problem with all of these methods is that as a user, you'd not know whether it was worth your time to report the problem. Even if the problem was heard and understood, who knows what internal priority it would be given... would it fall of the list of things to do for this next patch release (or worse, fall off the list of things to do for a major release)? You won't know until you by product v. n+1, and try it out for yourself.

Part of the problem was that the Microsoft culture was one of employees being publicly silent. If you're an employee, and you post on a public forum, and you screw up (anything from revealing confidential information or trade secrets, to implying there might be a next release of something not officially announced (much less whether a particular issue would get addressed in that release), to negatively representing Microsoft), you may find yourself without a job the next day. There was little incentive to talk to the public, and when talking to the public anyway (say you get cornered on an airplane and reveal you work for Microsoft), you'd have to play defense lawyer, and say, "I can't comment on that."

My personal opinion is that this lack of transparency and interaction has hurt Microsoft's public image.

The advent of public bug reporting mechanism such as Apple's BugReporter or SourceForge's bug tracker didn't seem to perturb the way Microsoft did business; semi-standard industry practices aren't necessarily readily picked up. Instead, the advent of blogging has started to crack the official barrier between customer and employee, circumvent the aforementioned "official" routes. All of sudden, you could read a blog and get instant insight to what a product team was doing, even what technical hurdles were having to be addressed. Futhermore, with comments, you could give direct feedback to that blogger.

Consequently, employee bloggers are interacting with the rest of the world in a much more public fashion. Non-public-relations people are regularly writing commuiqués, and the PR and legal departments are nervously fidgiting, waiting for a major gaffe. On the whole, it seems promising; technology evangelists are getting people excited about products, and there's a new transparency into some of the workings at Microsoft. It's unclear how many neophyte bloggers have had to "seek employment outside of Microsoft", but my impression is that it is negligible.

The developer devision seems to be leading this new wave. The MSDN blogs were among the first I had heard of at the company. Furthermore, they're the first group trying to "close the loop" with services like LadyBug. I'm not sure if "close the loop" is some official customer-representative jargon, but I'm using it to mean to be able to receive customer comments, report back what, if anything, we're doing with them and why, and then, once action has been taken, to follow up with the customer to make sure that the action satisfies their desires.

Again, historically, we were far from being able to close the loop. If a user complained about an problem, even if we knew it was an "official problem", i.e., there was a bug report and it was deemed a valid problem, we weren't allowed tell the user that.² Even if we could have told them it was a valid problem, we couldn't tell them much about when we would address it (assuming we knew) except under very limited circumstances.³ At best, we could have kept their contact information around and at the point where we finally addressed their problem and the software that did so was on the shelves, to report back to them. (I think, that happened in very isolated cases.) That still didn't really address the customers whose problems we elected not to solve.

While the new blogger-era rules of interaction are not fully written, it still seems like the new feedback tools and (the promise of) looser restrictions on customer communication will make it easier for customers to tell us what we need to know to do our jobs better and for us to let customers know that we "get it". (Or at least how much we've "gotten it", so they can take appropriate action.)
--
¹ For example, we might add new wizards to aid people who don't know how to use a feature; this reduces support calls, but doesn't make the product better for those who already knew how to use those features. It may not even mean that the product is better when you account for all users of the product. If only 10% of customers are calling about a feature and the rest understand it, the only portion that's costing us money that we can measure are the 10%.
² Notwithstanding our various Licensing Terms, previously known as EULAs, which warrant nothing about the software, the implication that there was a "bug" in the program could be (and in some cases, rightly so) construed as a "flaw" rather than "design limitation". Nobody wants to be sued, and software companies with deep pockets live in some non-zero fear of being the target of a landmark class-action consumer rights lawsuit akin to those in the automobile industry that might require fixing, recalling, and/or punitive damages.
³ If it was going to get fixed in a release not yet announced, that was a no-go. If it was going to get fixed in a release announced, but not on the verge of being shipped, there was a risk that the fix might get accidentally undone by some other work during the course of the project, and saying that it was going to be fixed meant having to make extra double sure that none of them were broken (not so hard), but also fix them if they were (which can be quite expensive if it's at the very end and we're trying to get the product out the door).