Well, I’d written about half of this post when Chris Pratley posted this. Fortunately, what I’d written dovetailed with Chris’ remarks rather well. Chris is a Group Program Manager in Authoring Services group, and he’s been responsible for driving One Note. In a number of ways, One Note has different development constraints than those of Office, both Win and Mac, which means we have to use slightly different methods. The overall objective, however, is the same. So, if you haven’t already, go ahead and read Chris’ remarks first. Then come back here.
In my last post, I pointed out that Mac Word 6.0 was a crappy product due to the way we came to set our priorities. One of the folks who commented blamed our priorities on Microsoft’s supposed insularity (in the present tense, no less). Sorry, but “insular,” past or present, had nothing to do with it, nor was our experience with Mac Word 6.0 something that can be reasonably generalized to Microsoft as a whole. It was just plain old bad marketing.
Oh, no. I just used the “M” word. There’s a problem with the “M” word. It has two meanings. Most of the time, the “M” word is used to refer to things like TV ads with butterflies, boxes spinning like footballs and people piling on top of each other like they’d just won the NCAA Division I National Basketball Tournament. Most people think of “marketing” as what you do in order to convince people to buy a product once you’ve already created it.
The other meaning for the “M” word, and the one I intend when I use it here, is all the work you do in order to understand your customers so that you can create a product they’ll want to use. Some people euphemize this meaning by calling it “product planning,” but it still falls under the rubric of “marketing.” If you do this part of your marketing well, the other form of marketing gets really easy. Screw this up, and the other gets really hard.
Eric Raymond said, “Every good work of software starts by scratching a developer’s personal itch.” Well, he was wrong. Good software does have to scratch somebody’s itch, but it doesn’t have to be a developer’s personal itch. It can be someone else’s itch. The trick is understanding the nature of the itch. That’s easy to do when it’s a personal itch. It’s not easy to do when it’s someone else’s itch.
This isn’t just a matter of listening to customers. We have to be active listeners. In one of the comments to my Mac Word 6.0 post, Sandy McMurray wrote, “The number one complaint I have about Word.X is that it uses its own spell-checker rather than the OS X system spell-checker…” But, Sandy’s itch isn’t the spell checker in Word itself. Rather Sandy’s itch is that he has to enter words into two separate custom dictionaries. Sandy’s idea about how to scratch that particular itch, i.e. use the OS X system spell-checker, is really only one way to scratch it. There might be other ways, lest costly ways in terms of development time, for us to scratch Sandy’s itch. If we can find those other ways, then we can free up time to go scratch someone else’s itch.
Another issue we have is the variety of Office users. It’s often said that no one uses more than 60% of Word’s features. On the other hand, every feature that’s in Word is used by somebody—well, I suspect that nobody uses Marching Red Ants, but the list of features that go completely unused is really very small. This variety of users implies a variety of itches. Talking to a handful of users, or even talking to some people who administer Macs in a large organization, can lead to a skewed understanding of our users needs. And, again, I want to emphasize that we’re talking about their needs in terms of what tasks they want to accomplish, not their needs in terms of specific feature requests.
In order to not get a skewed picture, we start by doing a statistical overview of the entire Macintosh market. Within that sea of numbers, we look for usage patterns. From those usage patterns, we can classify the market into different types of users. It turns out that we can break the entire market down into about a ten, or so, kinds of users, where each kind of user is defined by the kinds of things they do with their computer. One group might consist of Macintosh users in a relatively small group within a large organization that mostly uses Windows. Another group might consist of consultants or sole proprietors, usually in the graphics arts industry, who collaborate with customers to produce information for general consumption.
Once we’ve broken the market down into this manageable group of distinct user classifications, we then drill down into the details of the needs of each of these groups. In order to do that, we take a close look at the nature of their work. For example, an important aspect of both the groups mentioned above is the ability to share documents with Win Office users. On the other hand, the consultant or sole proprietor is more likely to have a project-oriented business than the small group of Mac users within a large corporation.
Once we’ve understood what these groups of users are trying to do, we then take a look at how we can make those jobs easier. Some groups of users, for example home users who mostly use their Macs for e-mail, internet access and media applications, are not likely to find Office useful at any price. Others will practically live their lives in Office, usually centered on Entourage. At this point, we cull out the user classifications for which we really can’t provide any value, and focus on those for whom we can provide some value.
Once we’ve figured which groups are important to us, i.e. those for whom we can provide value, we’ll personify each group. For example, we might decide that the needs of a particular group are adequately captured within the fictitious persona of a CEO for a small record label. This may seem gratuitous, but it really turns out to be a very helpful tool, and not simply because it puts a human face on a particular set of needs. It helps to facilitate communication about the needs that a particular feature is supposed to address. A feature specification, for example, will identify the personae who will benefit from the feature, and we then immediately know which sets of needs this feature is designed to address.
At this point, we’ll do two things. The first is to begin to analyze how well our present set of features meets the needs of each of these personas. Some features might not work all that well for what they need. On the other hand, we might have features that already work well. This is where common sense needs to play a significant role. As Chris points out, if you only pay attention to the data, then you’ll be as prone to mistakes as you’d be if you’d simply sat down with a hand-full of users.
Secondly, we analyze how real people in the various groups are using the current version of Office. From that we’ll get a picture of just where we fall short of meeting their needs. For any given need, we might decide to implement a new set of features, or we might decide that we have an existing feature that would work well but isn’t easily discoverable or easy to use. For example, our analysis of Word X told us that people weren’t using Word’ styles as often as their work would indicate they might. So we’ve addressed, or at least tried to address, the usability of styles as a formatting tool in Word 2004.
Only after we’ve completed this analysis hat we move into the design stage. The design stage really has two parts. First, we figure out how a feature is going to work from the user’s point of view. Then we figure out how we’re going to implement the feature to create that user experience. At this point, we still haven’t written any real code yet, though the implementation definition may well include some pseudo-code and an initial definition of programming interfaces. The latter allows us to come up with a reasonable estimate of how much time a given feature will take to implement.
Now we can do a cost/benefit analysis on each of the features we want to do. We’ll prioritize this work based primarily on the cost/benefit analysis, but there are other factors. There might be dependencies that require some work to be done before other work can be completed. Also, if we’re not entirely sure about the UI design of a feature, we’ll try to get that done early so that we can put the product in front of real people and still be able to incorporate any large changes dictated by the usability study.
During this phase, we’ll see if we can’t incorporate specific feature requests that we’ve received from a variety of sources, but we also have to figure out how those feature requests fit into the overall goals we have for the product. This is, perhaps, one of the most unfortunate parts of my job, because there are users out there who will complain that we don’t care about our users because we haven’t implemented their specific feature request. There are only so many itches that we can scratch at any given time. So, if we haven’t scratched your particular itch, it doesn’t mean we don’t care about you. It only means that someone else had more annoying itches for us to scratch.
I’ll close by reminding everyone that this is my personal blog. I’m not speaking for Microsoft, and my purpose isn’t to elicit feature requests on behalf of MacBU. I blog because I find the exercise of writing about a subject for public consumption helps me to clarify my thoughts on a subject. I also enjoy the dialog that it fosters. That doesn’t mean that I’ll ignore feature requests entirely. It only means that I might not discuss them here. Indeed, if you want to make a feature request, the best place to do it is via mswish. More importantly, however, in light of the discussion above, rather than give me specific feature requests, tell me about your itch. That’s way more valuable to me than a specific feature request.
In the mean time, if you want to see some of the upcoming results of this process, keep your eye on this.