How user discontent translates into profit motive

My (employer-inherited) goal is to sell boxes. Microsoft software product boxes, specifically. Fortunately for me and my CS degree, my particular function in the achievement in this goal has nothing to do with the boxes themselves or the manufacture of the discs, but really only with the software that goes in the box.

Consumers, purchasers of boxes, both like and dislike aspects of the box and its contents. The question that this post is trying to address is how (or whether) whatever dissatisfaction a consumer might have translates into profit motive to fix the problem.

Well, first, there's the recognition of the problem that has to happen. Many problems go unfixed for lack of recognition. In some cases, that can be despite outspoken users on the newsgroups. It can be because we recognized part of the problem but not the larger problem (or the still yet larger problem, etc.). In some cases, people don't even know there is a problem until a user experience person watches them try to use the software and choose a highly inefficient way (relative to some other way the software provides) of solving a task. Some amount of market research is created to see if we could establish what problems are key to get people to upgrade or buy new.

But even once a problem is identified, there's still some measurement as to its importance. The market research may also have details as to how big a populace has a particular problem. Even when there is no market research around a particular issue, our Program Managers, Developers and Testers have to take a stab at how likely it would be for someone to encounter certain problems and if that results in a subset of users, again, how large that subset would be (and how annoyed they're going to be when they see the problem). The size of the affected population multiplied by some factor related to how severe the issue is / how critical that functionality is to the work they do, determines the initial relative priority of working on one problem vs. another. When development and test come in with time estimates for how long it will take to fix and test problems, then there's a more fungible, but more final relative priority of working on problems.

This still doesn't really account for the nebulous issue of, when is a piece of software buggy enough that you give up and won't upgrade. I'm sure there's also research around that, but for us it seems that the quality bar that gets set is largely a touchy-feely setting, that gets set based on experience and consensus between the departments. We hope that that quality bar is sufficiently high to make sufficiently many people sufficiently happy with the product as to keep buying upgrades. Unfortunately, that bar setting is set by different people on a per-application basis, so there may not be uniformity there.

How can you affect that equation so that your bug gets fixed?

• Send cogent, succinct, and detailed bug reports – generally, this means to the newsgroups. This improves the likelihood of problem recognition, and reduces the fix time for development, especially if they don't have to track down a reliable reproduction case. Remember, what you think is a bug Microsoft has been ignoring might be a bug that they've fixed several versions of and think might be gone for good (and haven't seen your case yet).


• Call PSS – As I said before, this costs us (and you) money, and we generally track what problems are coming in. The higher the number of calls, the more likely PSS will ask us to fix it on their behalf. (How important this is is not clear.)


• Make sure other people affected by this issue do the same – again, it's a numbers game, to some extent.


• If it's something that's truly blocking your organization from upgrading, have your license purchaser let their TAM know – The more seats that are affected, the more important it is. In fact, MacBU has had a lot of pressure from Windows Office and Exchange to solve some problems because not having a sufficient Mac solution was hurting Enterprise sales in heterogenous OS environments.


• Bribe your developer contact.

What doesn't affect the equation that you think might:

• Saying how important this bug is – We take these statements with a grain of salt. It might be really important to you and yours, but how representative are you? If the affected users are 0.03%, and experiencing it isn't likely to keep them from buying the product, then it's less compelling than if 10% of the users are seeing it. Similarly, saying you're not going to buy the product anymore, is only so useful if we actually believe you and believe there are a lot of people like you. Bluffing or exaggerating may get results, but more likely, it may get you ignored as a noise generator. Now, if you can point to sharable market research that supports your claims, then, you should be talking to our product planners.


• Saying how long the bug has been around – Sadly, this is nearly inversely proportional to how likely it is to get fixed. If we could afford to ship it once and suffered insufficient adverse effects, then we're more willing to ship it again. That said, there's always some legacy bugs that are just taking their time to percolate to the top of the priority queue.


• Saying how much money Microsoft has to throw at the problem – That Microsoft has coffers is one thing, but we are law-bound to try and make the most money for our shareholders. That means at the business level, we have to justify spending money to make money. Fortunately, that doesn't go all the way down to the individual bug fix level exactly, though it is somewhat mirrored in our priority/severity accounting and triage processes.


• Being polite – Whereas we would sincerely appreciate your politeness and avoiding mockery of us and our products in public forums, if you are actually making a cogent, succinct argument in favor of fixing an issue (that we can tell), then we'll use it despite whatever extra vitriol was included. Hey, we all get frustrated sometimes. On the other hand, no amount of politeness is going to make a super-expensive feature less expensive and thus more palatable.

Unfortunately, none of this is a guarantee, and unless you're a Premier Support customer wanting a QFE, it's entirely possible that nothing (visible) may come of your efforts, or at least that the fix comes a long time off (one or more product cycles). Maybe someday our process will be sufficiently transparent as to show our assigned profit expectations to fixing various problems, and allow people to post bug bounties to push the chances of their particular pet-peeve bug high enough to meet the cutoff bar for a release. But sadly, I don't believe this will ever come about. On one hand, market research is apparently incredibly difficult to publish publically, and without that information, a lot of our profit expectation assignments would just appear arbitrary and cause more consternation that it would create benefit. On the other hand, our expectations of profit making might be considered to be trade secrets, and thus to be hidden.