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