Mac Word Notes View and OneNote

 

Chris Pratley has blogged about OneNote, with a number of follow-ups here, here and here. Now that we’ve released a demo of Mac Office 2004 that mentions the new Notebook Layout View in Word for the Macintosh, I expect that people will ask a number of questions. Why didn’t Mac Office do a version of OneNote? Why didn’t the Win Office group do a Notebook Layout View in Word? What are some of the external factors that drove these two product decisions? I’ll try to answer these questions, and, hopefully, give some more insights into the overall product development process at Microsoft.

Before I get started, I’ll say that this isn’t a product comparison or reviewer’s guide. You won’t find side-by-side feature comparisons here. My purpose is to discuss how and why the Win Office and Mac Office groups have gone in such obviously different directions in response to the same basic user problem—note-taking.

 

I’ve already blogged about the product development process in general, and the tools we use to try to understand user problems so that our products help users to solve those problems. In that discussion, I didn’t delve all that deeply into the fact that, for any given product, this process operates within a set of constraints. These constraints include available development resources, the underlying technologies on the target platform and potential alternative tools in the target market, and they affect the possible ways that you can approach a given user problem.

 

We can answer the questions above by looking at some of the actual constraints, but it’s important to realize that these constraints operate in concert. Remove one of them, and you might just end up with a completely different product decision. Thus, no single constraint is solely responsible for the product decisions we make. Those familiar with operations research can think of this is a fairly complex linear program without the benefit of having hard numbers for all possible constraints.

 

The number one constraint is development resources. I’ve had some of people tell me that they find it hard to believe that a company like Microsoft, with all its resources, can’t solve some problem they feel is important to the product they use. This reflects a fundamental misunderstanding of the meaning of the phrase “available development resources.” Availability of development resources doesn’t involve what you already have in the bank. It involves the return you can expect to receive from committing those resources to a particular project. It’s about profitability.

 

Mac BU’s life blood is profitability. Were it not for the fact that we run a nicely profitable business, Mac BU wouldn’t exist. It’s the sole incentive that Microsoft, as a corporation, has for continuing to deliver products built for the Macintosh. The alternative to being profitable is euphemistically known around Microsoft as “investment mode.” No business unit exists for long while operating in “investment mode,” and a great way to garner a lot of negative attention is to go from already being profitable back to being in “investment mode.”

 

It doesn’t take a Ph. D. in Economics to figure out that, for any given product investment, the Win Office group can expect more return than the Mac Office group. Even with absolute sales on the rise, Apple’s market share remains at 2%. That doesn’t simply account for more return. It accounts for a difference in return measured in orders of magnitude. That translates into at least an order of magnitude more development resources.

 

But, differences in development resources aren’t enough to explain OneNote vs. Word Notebook Layout View. If we were talking about two different user markets separated only by the fact that one group uses the Mac while the other uses Windows, then the profitability calculus doesn’t change. In order for the calculus to change, some other constraint needs to come into play: underlying technologies on the target platform.

 

For note taking, the most important difference between Windows and the Macintosh is the TabletPC. This doesn’t mean that OneNote is strictly for TabletPCs. In fact, keyboard note-takers remain a significant group of target users for OneNote. Moreover, to really understand the TabletPC issue, we have to look at it from the standpoint of Word, not the standpoint of OneNote.

 

The issue of underlying technologies isn’t simply a question of whether or not those technologies exist. From Word’s point of view, the question also involves the amount of work required to incorporate those technologies into the existing code base. It’s not all that different from the Carbon vs. Cocoa issue I blogged about earlier. It’s far easier to support new technologies in a brand new application than it is to graft those new technologies back into an existing application, and all the more difficult when the application we’re talking about has a code base as old as Word’s.

 

OK. So we have different development resources and differences in underlying technologies, but that’s not the whole story, nor, for that matter, the most interesting part of the story. In fact, anyone familiar with product development in general is most likely to have been able to figure out everything I’ve written above without reading what I’ve had to say so far. The differences in constraints don’t mean that Mac Word’s Notebook Layout View is nothing more than a cheap cousin of OneNote. It means that Mac Word’s Notebook Layout View solves a particular set of note-taking problems better than OneNote while sacrificing some of the more general note-taking features that OneNote provides.

 

Well, OK, Rick, you’ve asserted this, but why is it true? Well, the differences in constraints forced us in Mac BU to look at a different set of end-to-end user scenarios. Also, the fact that we’d had Project Center in the works meant that we could approach portions of the note-taking problem from the workflow point of view. In particular, we had an opportunity to drill into those scenarios where people would take notes with the ultimate purpose of getting those notes into a Word document or would take notes in association with a specific project.

 

A research project is a prime example of both cases. It’s project-oriented, but the output of the research project is usually a paper of some kind. So the notes end up in a Word document. These are the kinds of end-to-end user scenarios that we in Mac BU drilled into more deeply than the Win Office group drilled. We gave scenarios like this one a high priority, while the Win Office group gave other scenarios a high priority.

 

Interestingly enough, a not-insignificant portion of Mac Word’s user base consists of people whose primary work is research. In fact, the most active participants in the Word 2004 beta program have been academics of some form or another, with a few Mac-based IT administrators pulling in a very close second.

 

In any event, doing a Notebook Layout View in Mac Word offered a synergy with Entourage’s new Project Center that Chris Pratley and his group didn’t have. It’s difficult to categorize a synergistic opportunity like this as a constraint. It’s more like the absence of a constraint. But the effect is the same: it shapes how you plan and implement a solution to a set of user problems as outlined in various end-to-end scenarios.

 

It’s also worth noting that we, in Mac BU, didn’t simply start from scratch in terms of usability and general user data. We drew significant benefit from the general user data and usability information that Chris’ group generated through efforts like the acid usability test. Armed with that raw data, we could map it to the end-to-end user scenarios we’d worked up for Mac Office 2004 to find some specific scenarios that we could address by doing a Notebook Layout View. The research project scenario is one, but there were others. The details aren’t quite so important as the process.

 

Which is really the full answer to the questions I asked at the beginning of this post. In Mac BU, we employed essentially the same process that Chris Pratley’s group employed, operated within a different set of constraints, and developed a solution that addressed some of the same basic user problems. The net effect of these constraints was to form a lens, as it were, through which we could view all the user data we’d had to arrive at the solution we chose to develop.

 

In closing, I’ll point out that what I’ve described above is a very systematic process for maintaining product differentiation. I’ve talked about the commoditization of software before, and there have been a few comments on my earlier post on the subject. I hope to respond to some of those comments in an upcoming post. While I’m working on that, I suggest that people ponder the implications of Microsoft’s systematization of product differentiation with respect to the issues that David Stutz has raised.

 

 

Rick