Hardcore Software by Steven Sinofsky (Audio Edition)

Welcome to “Ye Olde Museum Of Office Past.” This section is one of the more deeply product-focused of Hardcore Software. I hope to make it fun. In this section, I will go through the history and evolution of the Office user interface. While there were numerous innovative user interface systems and approaches across the industry, what we developed in Office by virtue of the breadth of usage and position of influence was viewed by many as a standard to be followed. Many readers have experienced the innovations discussed here. By stepping through over 20 years of user interface designs for Microsoft’s word processing applications, we can see the dedication to solving problems. We can also see the creeping introduction of bloat.

Back to 077. What Is Software Bloat, Really?

How did we get to Office 2003 with a menu bar, toolbars, context menus, keyboard shortcuts, task panes, dialog boxes (with tabs), widgets, buttons, and pop-up commands?

We got here by solving customer problems. We got here by making the product easier to use. We got here by listening to the market. We got here by winning reviews. It was that simple.

Or was it?

It is easy to see what happened in hindsight. We added new features, one after another. To make features easier to discover and use, we added additional user interface. Layer after layer, or solution after solution, we built up an array of user interface elements that when looked at in totality created bloat. But it is just so easy to say that in hindsight.

One simple observation was that to win in the market when Microsoft started making applications, we had to win reviews. These reviews meant everything in a world with many competitors, retail distribution, and little word of mouth (and no internet). Reviews were giant checklists of features. For example, Software Digest compiled yearly reviews of all products in market. The 1984/5 edition of their 200-page book on just word processors had a 4-page fold-out checklist of 50 features and a dozen abstract criteria. Fail any of those and the overall score sank. A losing score meant no ability to advertise winning, no recommendations from salespeople, and then the next release and review started in a hole. So, for a decade we made sure to always have those features. There was no choice other than to win reviews. And we did.

When should we have stopped and taken a first principles approach? When would the upside have exceeded the potential downside? When would the market and reviews have tolerated a big change? What if the market rejected a solution we tried? We would have reverted to the old way and delayed addressing bloat for how long, another decade? It drove me bonkers when people thought bloat was obviously caused by too many features. It also drove me bonkers when those that should know better would so quickly conclude that we were making things worse by winning reviews.

There is no easy answer to asking when the right time is to make a wholesale change in approach. Anyone in product development saying it is obvious hasn’t really lived through the risk of making a bad choice or is simply applying hindsight.

Innovator’s dilemma and disruption make it seem so easy to identify and act at the right moment. They also make it so easy to make fun of the leaders who are terrified, I mean literally shaking scared, to make a dramatic change to a product. No one ever gets fired right away for not making a big change. Many people get fired right away for making a big change at the wrong time. The worst part? So many big changes are eventually proven correct over time.

In the case of evolving Office, we were going so fast cranking out releases no one stopped to ask anything big. Customers were buying our product as fast as we could press new CDROMs, so to speak. We were winning reviews. Our biggest competitor was ourselves. We were so ubiquitous that we were punchlines on everything from David Letterman to Saturday Night Live to Dilbert.

Then suddenly, we were boring, bloated, and not particularly interesting. So much so that a buggy, poorly implemented, sort-of clone became a symbol of everything we had apparently done wrong. The world was saying that StarOffice was good enough. Ugh. Our sales, however, were not dented even the slightest. But could they be? We did lose that deal in one city in Germany. StarOffice was a German company so maybe it wasn’t so bad. Then there was a medium-sized US government agency loss. When do you panic when something like this happens? There’s no playbook.

Hemingway wrote in The Sun Also Rises:

"How did you go bankrupt?" Bill asked.

We became bloated gradually, and then suddenly it was too much. The product was collapsing under its own weight.

It was time to revisit from first principles everything we’d done and ask why. And to come up with a better approach, a wholesale reinvention.

The aim of this section is to briefly cover the history of those innovations that got us here so that we have the necessary context in the next sections on the design of Office12. When it came to telling the story of Office12 once he showed it to customers, Jensen Harris (JensenH) dubbed this his tour of “Ye Olde Museum of Office Past.” Please join us on a tour.

Comparing a typical command in Office from the time it was introduced to a release decades later is a great lesson in the compounding complexity of products. Making text bold debuted in Microsoft Word 1.0 for MS-DOS in 1983. Text was made bold simply by selecting the text (actually, it wasn’t simple at all since few had a mouse, but I digress), hitting the escape key, the letter F for format, the letter C for character, and finally the letter B for bold. For those with a fancy monitor, which not everyone had at the time, the text became bold on the screen. Choices at each step were limited to approximately five.

Commands also had keyboard shortcuts from before the mouse as an affordance for touch typists. Early keyboard shortcuts were simple, like using INS(ert) key to copy text from the scrap (clipboard). WordPerfect, and other early MS-DOS apps, devised schemes that were nearly impossible to memorize. Most people had some sort of cheat sheet nearby or keyboard overlay to help remind them of keyboard sequences. Lotus 1-2-3 had a highly structured command architecture known as slash commands as navigating the character-based menus began by striking the forward-slash key (for example, to open a file /WFR for slash, (W)orksheet menu, (F)ile menu, (R)etrieve command). Competitively, the two behemoths in productivity software of the MS-DOS era, WordPerfect and Lotus, arguably clung to their keyboard methods while the industry shifted to the graphical interface, even maintaining compatibility with those keystrokes during the rise of the mouse and standardized menus.

Macintosh, with menus and a mouse (and later Windows), aimed to simplify all this. In Microsoft’s Word 1.0 for Macintosh, text was selected with a mouse and Bold was chosen from the Character menu, like what Apple did in their MacWrite 1.0. MacWrite had about 35 menu commands in total. Menus were mostly a direct mapping of the features to the product code. The whole product could be described by showing screenshots of all the menus in a two-page magazine spread as Popular Computing did in 1984 when Macintosh was launched.

Over time more and more formatting options were added: subscript, superscript, underline, different fonts, color, and so on. Excel was even more complicated because it supported formatting cells as dates or currencies, plus single underline, double underline, accounting underline, and more. This was great—we listened to customers, observed what they were trying to do in the real world, took advantage of new hardware, such as laser printers, color ink-jet printers, and fancy screens, and were adding features like mad. Soon, though, the menus got too long for even basic formatting.

Microsoft’s early Macintosh applications introduced dialog boxes, which were windows that popped up and showed all the formatting options. This was inconvenient for routine formats, so the menus had a mixture of common commands like Bold and Italic, and then a menu to “bring up that complicated dialog box.” This was the start of hide-and-seek with features.

Excel realized these challenges about the same time Microsoft Publisher did and created toolbars. (There’s a history of debate over toolbars—what is considered one, and which team or even company invented them. Many on the Excel team were hardcore about their version of the story.) Toolbars were used for common commands, like Bold and Italic, as well as Print, Save, and Copy. In 1990, the front of the Excel 3.0 box and associated advertising displayed giant toolbar with buttons for Bold and Italic. Toolbars they were such a big deal. Eventually, toolbars were so popular everyone wanted their favorite commands on them, so we created more toolbars and made it easy to rearrange the buttons and hide/show different toolbars.

Under development at the same time as Excel 3.0 was Word for Windows 1.0, Microsoft’s first word processor for Windows (I’m omitting the venerable Microsoft Write included with Windows, which by the standards of MacWrite was every bit a word processor). Word for Windows also had toolbars, two of them, and a graphical ribbon which was the defining user interface element in word processors, owing to the skeuomorphic interpretation of the margin scale of a Selectric typewriter. Word 1.0 also fit on a screen 85% the size of today’s HD television.

Word 2.0 released in 1991 nearly doubled the number of buttons on the toolbars but maintained the same layout and screen dimensions. While each iteration showed substantial gains, the transition from Word 1.0 to 2.0 marked a move from character to paragraph and document-level operations in the main user interface. There were now buttons for inserting tables, columns, charts, and graphics/shapes. The addition of inserting charts, for example, represented the rise of Office-wide technology connecting the applications which was strategically important even if not every customer used the features. Each of these features represented more than single attributes on a character. For example, adding a numbered list encompassed indenting the paragraph, an automatic number, hanging indent for multiple lines, and spacing after the list. These steps could have been executed manually but getting them right each time was error prone, assuming one could get it right the first time. As each of these features were more complex, Word introduced dialog boxes that had buttons on them to summon further dialog boxes, or nested dialogs. This really led to the creation of “where is that?” within the user interface. Designers and program managers worked enormously hard to position choices and options within these nested dialogs, but no user maintained this level of conceptual knowledge of the product. What was the problem we were solving? There was literally nowhere to put all the new features. Menus and toolbars were constrained by working on screen resolutions typified by 15” CRT monitors or first-generation laptops.

By Word 6.0 the race was on (the version number skipped from 2.0 to align with the ongoing MS-DOS version of Word which accelerated its version number to align with share leader WordPerfect—yes that’s how the industry worked). Word 6.0 was a breakthrough product, even more so when brought together with Excel 5.0 and PowerPoint 4.0 as Office 4 in 1994. At that time, Office 4 was a monster of a product as no company had competitive products in all the major categories. Within the categories each Office application was at least tied with the nearest competitor. Office 4 was the last release entirely designed for individuals as the product was quickly becoming a standard business purchase.

That said from a design perspective, the relative heft was obvious. Word 6.0 added 6 additional toolbars and a host of new user interface affordances for accessing commands, while also increasing the baseline screen size by 25%. Word (and Excel and PowerPoint) added right-click contextual menus, tooltips, tabbed dialog boxes (a refinement of the nested dialog boxes), toolbars on bottom of screen, and wizards. What was already a difficult to master set of commands accessible by one action (point and click) became acts of hunting and discovery. Tooltips, helpful text explaining what a graphical toolbar button did, popped up when the mouse was hovered over a button. Some toolbars only appeared when invoking certain features (though they didn’t always go away).

Right-click context menus are worthy of some historic context. Paul Allen (PaulA) Microsoft’s co-founder was a huge fan of the right-click, drawing his inspiration from the original Xerox SmallTalk when he created the first Microsoft Mouse with two buttons. Steve Jobs rejected two buttons in favor of a simpler Macintosh mouse, and for years bemoaned the use of the secret Ctrl+click added to Office applications, simulating right click. Windows had not entirely caught up with its use of right-click but with Office 4, Apps added right-click with abandon. With right-click, relevant commands for a character, a selection, a picture or even a paragraph appeared by right-clicking the selected object. The laudable goal of these commands was that by carefully curating the user-interface the right commands would be available and there would be no need to cruise around the product to figure out what might work. The menus were called context menus for this reason. The feature was marketed heavily, so it was no surprise that sometimes we snuck commands in the context menu that were important strategically, though not always the most likely to be used.

We had our early usage telemetry for Word 6 that came from a specially coded version and data collection via floppy. I vividly recall the data coming back about context menus showing they were frequently used. I shared this data with PaulA who was active on the board still. It was quite a vindication of the two-buttons. The more fascinating datapoint was that for a typical command such as copy/paste the usage of the menu, toolbar, keyboard shortcut, and now context menus were split roughly evenly. A given user did not exclusively stick to one affordance. We learned early on that adding secondary and tertiary affordances to commands was a convenience picked up by a set of users, not a replacement for the old ways. Importantly, and reviews showed this, technical users heavily bought into the notion that user-interface should be available multiple ways for maximal efficiency. While we curated and designed the context menus, it was no surprise that these same technical users wanted to customize context menus because they had their own ideas for what might make sense. The popularity of context menus put pressure to add even more commands over time, eventually obscuring content or forcing awkward positioning on small screens.

It was always the case that menu items that were not applicable at a given time were disabled or greyed out. As commands and buttons began to encompass high-level abstractions, disabled commands started to become a mystery. Why couldn’t I insert a table inside a table? Why didn’t bold work on a chart? And so on. This proved even more frustrating than hide-and-seek. These “greyed out” commands aways seemed to be needed just when they didn’t work. People had no idea why a command was greyed out. Even today searches for “Word menu item greyed out” have hundreds of millions of results.

Recall that the design of Word 95 (technically Word 7.0 for Windows 95) required we not change the file formats. This significantly constrained what features could be done since most formatting and document commands would result in a file format change. Word 95 innovations were mostly focused on IntelliSense, features that just worked with little if any user interface. We previously discussed background spelling and AutoCorrect as examples of these features. While the product did not gain bloat by way of pixels, the sense of product mastery was reduced. IntelliSense features introduced us all to “what just happened” when using the product. Typing a few dashes across the screen and pressing return yielded a clean horizontal line. Pressing backspace was a clever way to undo that so long as that was the next key pressed. This loss of control or as we now know an inability to fully master a product came about by the introduction of features specifically designed to be useful without having to learn a command. Hundreds of hours went into designing interactions such as how to begin and end a bulleted list (using an asterisk or hyphen at the start of a paragraph to begin, and a second return to end a list). Even with a dedicated effort, we could not be right 100% of the time. We began to consider the hypothesis that automatic features might need to be so perfect that they worked 100% of the time, and if we guessed wrong just 1 time out of 100 then to the user the feature was always wrong. Think about this in the context of today’s iPhone AutoCorrect.

Word 97 was the first release using shared code across all of Office for deep architectural features. One of those features discussed earlier was command bars, our first shared code for this critical user interface affordance. The availability of shared code and ample time to develop new features led to an explosion of command surface area in the product. Thanks to 32-bit computing and Windows 95, the base screen resolution expanded to 1024x768, three times bigger than our original target for Word 1.0. An explosion in user interface correlated to the product being labeled a winner, a juggernaut, and competitively overwhelming. But it was not bloatware, yet. Just by toolbar count, the product was twice as big, jumping to 18 toolbars (and each one had more buttons because of the screen size). For completeness the list of new user interface widgets included: toolbars on every side of the screen and floating, menu bar that can be docked on any side of the screen or floating, drag and drop any command anywhere, hierarchical and multi-level menus and context menus, icons on menus and context menus (the preceding all came as part of the new shared code), Office Assistant ("Clippit"), green-squiggle grammar checking, even more IntelliSense (including on-the-fly spell correction), along with more wizards and more multi-function commands on toolbars.

IntelliSense in Office 97 was as much a point of view as it was code in the product. Some of what was designed as IntelliSense was trying to do the right thing with the user interface elements that routinely appeared. We would try to anticipate needing some functionality and pop up the user interface. Often this puzzled the user, and they would quickly move it out of the way. The obvious addition was a check box “Never show this to me again.” The significant problem with this option is figuring out when to show that user interface in the future. If we guessed and showed it again, we were ignoring the user choice. Absent that, the chances of a user finding where to uncheck the checkbox they just checked were slim. The chance of even knowing that is what was required was probably zero. In other words, whatever we popped up was effectively gone forever. This type of intelligence in the design proved to be incredibly frustrating. I’d offer a tip for readers that are designing products: a checkbox offering to never show something again is always a bad idea (GDPR inclusive). Showing it in the first place was the problem.

Word 97 was both our last release aimed squarely at the retail consumer and technology enthusiast and our first release with an eye towards the volume purchasing business customer. It was also the last release that was done without thinking deeply about the impact of complexity on corporate customers. In hindsight it is probably right to look at this release as the start of an overwhelming Office but only because customers would soon be pointing to Office 97 as bloatware. At the same time, by today’s standard the set of features and capabilities were not at all overwhelming, just ahead of the curve for most people. For example, PowerPoint dramatically added photo, drawing, and graphics capabilities which also appeared for charts in Excel and drawings in Word. It is entirely clear these are representative of mainstream scenarios today.

Hearing the early concerns of complexity and bloat from our new enterprise customers deploying Office 97, we looked to a cosmetic/graphic design approach to reducing bloat. Along with the enterprise feature set in Office 2000 we employed the use of the doctrine of “make it simple by hiding it.” We used our command bar infrastructure to implement the personalized menus, where commands were hidden by default in both menus and toolbars. This was detailed in Chapter VIII (Alleviating Bloatware, First Attempt). The feature proved a failure and would be an important part of informing our design for Office12.

In another visual trick, we used the space made available by hiding toolbar buttons by default to place the two main toolbars adjacent to each other rather than on top of each other, called rafting. The contextual toolbars introduced in Office 97 described above were further tuned so they would hide and show automatically in the hopes of returning some control to the user.

I’d offer another tip for readers that are designing products: invisible and hidden commands are in no way at all simpler or more streamlined, though they are frustrating.

The Windows team encouraged us to change our apps to have one distinct window for every open document, with each window showing up on the Windows taskbar at the bottom of the screen, a design long-standard on Macintosh. Previously only the application showed up on the taskbar and multiple documents for the same application were available as separate windows only through the application’s Window menu. This was deemed complicated and not consistent with the direction of Windows. The result especially for Outlook was a ballooning in the number of windows on the taskbar each with ever-decreasing amount of text showing the title as they were cramped together. In other words, a change meant to make things easier turned out to scale particularly poorly when applied to real-world application usage.

By the time we shipped, Word 2000 added five new toolbars.

Office 2002 (aka Office XP) aimed to vector some efforts back to delivering end-user features. With the failure of the Office Assistant and Clippy’s retirement due at the time we shipped, we introduced two features aimed at offering ease of use surface areas. In hindsight, both were poor choices, one of which continues even today (after being removed from Office12).

The first relatively minor change was to make our new internet-connected help system available all the time with a simple “type your question here” box at the top of every screen on the same level as the menus. This rather innocuous addition set a precedent of cluttering the menu bar for additional commands. The awkwardness of the affordance as a place to type questions made it a particularly poor choice. Typing in the menu bar is just weird.

The task pane described in Chapter IX allowed us to greatly expand the surface area of the user interface. The design choice was rooted in the rise of the web. Unlike menus and toolbars which are concise word-length command descriptions, the web evolved with sentences describing the steps, such as “After selecting your dates of travel click here for the best fares.” Many on the design team favored moving Office to a more descriptive user interface as a way of reducing complexity and explaining actions in context. The task pane started as an experiment for a few key long-standing problems. The “New Document” task pane finally gave us more room for the user to choose from a list of previously opened files, document templates, and more. The “Reveal Formatting” task pane was an advanced feature long favored by technical users which showed all the formatting applied to a given selection of text (historically this was also a feature to compete with WordPerfect).

The task pane would prove to be a frustrating experience for customers, especially on small screens where it took over a good chunk of the side of the screen. It is worth noting that laptops had started to switch to wide-screen format (16:9 aspect ratio)—screens remained about the same height but were wider to accommodate a standardized HD (720p) and Full HD (1080p) resolution being used for video. Theoretically the wider screens would offer more space for user interface arranged vertically. Tech enthusiasts became enamored with the idea of stacking the Windows taskbar on the side for this reason. Feedback was mixed. At the very least a large portion of our enterprise customers were still using standard 4:3 aspect ratio screens.

In total, Word 2002 created eight task panes and added another seven toolbars, bringing the total number of toolbars to 30. Task panes were a key part of marketing Office XP, exceeded only by Clippy’s retirement.

Office 2003 as described in the last chapter was characterized by heft. We delivered more new “programs” than in any prior releases, plus services and servers—the entire Office System. The expansion of the user interface continued as well.

The task pane from Office XP proved extremely popular, even considering the feedback from Office XP. We believed that the continued standardization of wide screens would show that using the task pane for user interface was a good use of the extra width. We added 11 (yes, 11) new task panes bringing the total number of task panes to 19. The task panes received a technology improvement adding support for more user interface elements and richer display. The task panes themselves were essentially mini-web sites within the product.

We didn’t stop there. We added a second window aligned on the side for showing online help which would cause a jarring realignment of the whole application shifting everything to the side to make room.

Looking back at each of these releases one other point is worth noting. Each product cycle as we aimed to make things easier, some commands moved around and to users the changes in the interface felt as though the whole product moved around a bit. These small moves were designed to make the product a little bit better, but to users it was often the case that the product was more than a little bit different. Small changes have just as much of a negative impact on the feeling of product mastery as big changes, but a minimal effect on ease of use.

With Office 2003 we reached a point that the was envisioned in David Pogue’s 1994 column as “Word 15.0, due to ship in 2004”, give or take. A mock-up of such a future version of Word illustrates the article showing an enormous number of toolbar buttons filling the screen, leaving little room for editing any document.

Two more escape valves in the design of Office proved to be sources of bloat as well, even as they served to solve problems for our own designs and customers: customization and program settings or options.

In the early days of the products, we added the ability to customize most of the choices we made. End-users or system administrators could move commands to customize the product for their unique use. Over the years we continued to improve the ability to customize. By Office 2003, we had the capability of placing any command anywhere along with the ability to create as many toolbars and menus as required. This customization was embraced by those creating custom programs running within Office applications using Visual Basic.

Many tech enthusiasts took great pride in having a perfect toolbar for themselves or their business. One customer I visited, a big consumer product goods company in the Midwest, spent months planning the rollout of Office such that there were specialized arrangements of the menus and toolbars depending on an employee’s job function. A lawyer, marketer, salesperson, or finance person saw different customizations. This might have seemed nifty, but it also meant the company needed to rewrite the documentation and help for the product, leaving employees with existing product knowledge or those who were using how-to books lost. We invested significantly in making it even easier to customize the product, believing that if more people could customize the user interface maybe it would be easier. We really needed to stop digging.

No discussion of bloat would be complete without mentioning “Tools Options” the settings for an application. These settings would increase every release. A “setting” is most often a choice somewhere in the code that we made in designing a feature, but for some reason we anticipated that customers would make a different choice. Some choices might be preferences or user information, such as default fonts or initials to use in marking document revisions. Others were often obscure compatibility choices such as the most famous of all, operating as though 1900 is a leap year or not. This is an option because the first versions of Multiplan and Excel (Microsoft’s products) and Lotus 1-2-3 incorrectly coded 1900 as a leap year (not to nitpick, but Lotus was incorrect and Multiplan then Excel maintained the error for compatibility with industry leader 1-2-3).

Tools Options was also a place to cover the sins of indecision among program managers. When Excel pioneered the wheel on the mouse in Excel 97, between Word and Excel we could not agree on whether the wheel was meant for zooming or scrolling. To compensate for our own inability to agree we added a checkbox to change the default.

The Tools Options dialog, much like the control panel in Windows or system settings on Macintosh, is often the first stop for reviewers or techies. With over 200 choices there was plenty to keep an eye on. The presence of choices is empowering. At some point, however, empowerment turns into bloat. We reached that point.

Sure, the choices were overwhelming, and people were finding them difficult. But we were also speaking an entirely different language than customers, one they weren’t interested in learning. They had work to do. They knew what they wanted when they saw it but describing what they wanted or even spending time exploring the product was time wasted. We used to joke that if we did a usability test to English speakers using the German version of Office and asked them to do something complicated, they were no more efficient in their native language simply because the words on the menus weren’t words at all. What is “Mail Merge” or “Pivot Table”?

During the design of Office12 we conducted many usability tests where we asked subjects to pick where a command should go in the existing menu structure or to locate where a specific command might reside. Some of our menus had become almost dumping grounds for commands that didn’t obviously fit somewhere. The problem with such a design is that if we don’t know where a command should go how in the world would a normal person guess where it should go? Or even if they got lucky once would they remember it the next time?

Returning to how we became bloated, it was two ways. First slowly, then suddenly.

I hoped to make the case that at each generation of Office we were considered in where those features went. The thousands of hours we spent deliberating the names, entry points, and visualizations for every new feature were symbolic of our commitment to getting this right. We were proud of each the default user interface experience of product cycle. Screen shots were our currency, and we were always happy to see the new screen shots in the press. One thing we noticed was that even with all we added and improved, the ability for customers and the press to identify the new product versus the old from screen shots was rather limited. The product was so overwhelming most people could not tell the difference. We had a design language consisting of a lot of stuff on the screen, but to most people it looked like a bunch of buttons and computer stuff surrounding their work.

An analogy we often used was key to understanding a way forward for us. From crime and police dramas, most are familiar with the role of the sketch artist—the detective who takes a verbal description of a suspect and turns into a drawing that is used on the streets. It is difficult to describe another person as most of us lack a vocabulary for facial features necessary to reconstruct a face. That is why creating such sketches is a highly expert art. Over the years, the use of software to show options to a witness has become the standard for constructing a sketch. People do a much better job describing something from examples than they do from a blank sheet.

Office needed the equivalent of a library of choices rather than an overwhelming vocabulary of features they did not understand.

But how?

Hardcore Software by Steven Sinofsky is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

On to 079. Competing Designs, Better Design

In this and the next five sections, the story of Office12 (Office 2007) unfolds. This is really the story of the development of the new user interface for Office, which became known as the Ribbon. To many readers, this will seem much smaller today than it was at the time, and that is understandable. I hope to put this work in the context of the day so readers can see just how big a deal this was. The graphical interface was the paradigm of computing. The menu bar was the manifestation of that. The addition of graphical buttons or toolbars was a significant advance and clearly the biggest addition to the WIMP paradigm.

One of the realities about a common toolset is that over time all applications get commoditized or at least appear the same. Everything looked like a big collection of buttons. That means two tools in the same category (two spreadsheets) will converge in how they look, and to the market they will be perceived as interchangeable. This perceived commoditization is one half of the story of Office12. The other half is figuring out how to make our extremely sophisticated products usable to hundreds of millions of people, something without precedent. A car typically has a dozen controls one needs to know to use it. Microwaves, televisions, thermostats, and so on are usually less than that.

Regardless of the reason, Office has thousands of commands. Making sense of those is an impossible customer task. So, what did we do? This section is an overview of the specifics of bloat. The next section presents some history, and then the design over the remaining sections.

Back to 076. Chasing The Low-End Product [Ch. XI. Betting Big to Fend Off Commoditization]

In 2001, Jon Stewart, the legendary host of The Daily Show on Comedy Central, performed a hilarious and brutal takedown of a redesign of CNN’s Headline News show. In the segment, he took to task the departure from the traditional talking head, as epitomized by Walter Cronkite and the evening news (and Jon Stewart). He mocked Generation Y (eventually called Millennials) for favoring a seeming onslaught of disparate information at once rather than one camera and a single story at a time. Stewart referred to a new look that “ . . . offers a great way to find out everything without the pressure of retaining anything.”

The punchline, almost 20 years later, is that the redesign Stewart mocked became standard across every medium, web, broadcast, cable, Bloomberg, YouTube, and today’s phone apps. We can bemoan such a change or accept the fact that people prefer consuming information differently than they did a generation earlier. The reality back in 2001 was that people were leaving TV news in droves in favor of on-demand, concise, and always available internet-based news displayed on crowded home pages.

Around the same time, the TV show 24 was considered both a breakthrough and critically panned for a similar departure from the tradition. The show was fast paced, had a complex narrative, and featured dozens of characters moving in and out of each other’s story lines. Critics said the narrative was overly complex. The same generational change was afoot, and the MTV Generation was raised on fast-paced video, clipped dialog, and rapid cutting between scenes. To this new audience, 24 seemed entirely consumable. The single-camera sitcom was in its twilight.

Design, whether functional or aesthetic, is a product of the context of the times. When contexts change—meaning the people and their needs and the available tools and technologies—designs need to change as well.

File, Edit, View, Insert, Tools, Window, Help.

Like the catchy lyrics to a well-worn pop song, in Office we knew the top-level menus appearing consistently in each of the applications. We spent almost 10 years convincing, cajoling, and aligning each other around these words as though they were carved in stone. In fact, these words were the product of compromise—first a compromise between Microsoft and Apple on the original Macintosh applications and then a compromise between our new Windows applications and Macintosh versions. Finally, there was a compromise across Office to reach consistency. As with many compromises, no one was particularly happy with the result and there were plenty of exceptions, but nobody was all that unhappy either.

It wasn’t perfect, but it was our menu structure and our customers liked it. So much so, it was widely emulated across the industry. That made it carved in stone. It was like so many arbitrary design choices that somehow develop a lore of great design, like QWERTY keyboards or P-R-N-D in a car.

While rather adaptable creatures, humans tend to react poorly to change imposed upon them—a new stoplight, a new layout for a website, or the most heinous of all modern changes, a new software user interface for an existing product. Unexpected or imposed changes are viewed at best as arbitrary and at worst as bad (incredibly bad). It is exceedingly rare in the world of software to see existing users embrace major changes to mature products.

Consider something that most of us would today think of as rather benign, a change in the layout and typography of a print-based magazine. Magazines would devote a few pages explaining the design and rationale or perhaps even TV commercials as The Economist did with their 2001 redesign. Such “bold” (they always called them bold) redesigns would often become the subject of weeks of letters to the editor complaining about the failings of the effort and calling for a return to the old design, followed by the inevitable subscription cancellations.

Even if a product makes it through a big change, there often remains an undercurrent harkening back to the good old days for a long time. Whether it is simply conservatism or as some express a true loss of efficiency or effectiveness with a product, change is hardly ever free of controversy.

Yet, we live in a constant state of change. What is it that separates the changes that cause an uproar from the changes that happen with little notice? Technology is changing all around. Consumer behavior and work norms are regularly evolving. Competitors with new perspectives arise frequently. Often competitors with a fancy new design might even compete directly with a small portion of a larger established product with a tired design. Perhaps the new product even garners outsized attention because of that new design, less so than the features it brings. Failing to change remains the biggest mistake technology companies can make.

And as I’d soon learn, failing to change correctly is the second biggest mistake technology companies make. There are no rule books or guidelines that govern how much a product can change and when. There are many books telling you if you don’t change, you’re doomed. There are also a lot of books telling stories of changes going haywire. (Note to readers, this work is both of those).

Office became a bit like the old evening news, not so much Cronkite’s CBS but more like CNN. It was ubiquitous. It was reliable and predictable. It did not draw much attention to itself. Younger people knew about it but didn’t talk about it the way older people did. It was comfortable.

Still, each release was more successful financially than the previous and rated higher in customer satisfaction. Our customer base grew, and they continued to be happier with each release. The Office brand anchored several important traits of Microsoft representing “easy to use” and “professional.”

But comments about bloat continued unabated. Was it insider talk? Were people overall happy and the beltway of tech journalism was searching for something, anything at all, to criticize in the face of success? How could customers be so satisfied, and the business be growing if we were making increasingly bloated products? We theorized that analysts, reviewers, and reporters, those most typically calling out bloat, were users of a small subset of Office compared to typical knowledge workers. One reviewer of a major national outlet would not review Excel because of the view that most people didn’t need a spreadsheet.

As we discussed in creating Office Lite, a pervasive view existed that the product suffered in usability and quality because it had too many features. Specifically, there were too many features for how any individual said they used the product. Too many features lead to a complex experience and bugs, so went the theory.

Another theory was that PCs, not just Office, were becoming increasingly fragile and flaky. Bloat might be a PC problem and the ubiquity of Office simply an easy way to express the problem.

Three factors contributed to a feeling of a declining PC experience—sort of like a car that needed a tune-up to get rid of the engine noises, reduce the squishiness in the ride, and improve performance.

First, PCs were decreasingly interesting to purchase. The newest and best PCs lacked the excitement, and budget, that made consumers want to rush out to buy a new one. The pace of improvement in hardware arguably slowed, but so did the pace of software. By 2004, we were three years into Windows XP with no new release of Windows in sight. Longhorn was perennially under development. Without a new Windows, the need for a new PC was minimal and certainly not worth the pain of moving files and programs to a new computer. It is important to note that buying a new PC was the fastest way to reset the PC experience, cleaning out all the gunk. Without a PC purchase, such a spring cleaning was technically impossible.

Second, the rise of the internet turned everyone into a software downloader. Every first Tuesday of the month Microsoft sent updates to hundreds of millions of PCs to keep them secure—product changes that closed holes that could be exploited by malware and viruses. The creation of Patch Tuesday, as it was called colloquially, was rooted in Trustworthy Computing and was a major innovation in system security and reliability. The seemingly constant stream of product updates only served to emphasize the fragility of the PC. The required and poorly timed reboots wasted time or worse and left a bad impression of PC reliability while also providing great explanations for a PC slowing down or failing to restart.

Users were downloading software constantly as well. It wasn’t only the next version of a browser that remained interesting but the latest media player software, software to control the newest device to plug into a PC, utilities making the aging Windows XP easier to use, and more. From Napster to BitTorrent to Adobe Acrobat, plus an onslaught of games, there was an endless stream of software to download. Software installed on Windows had free reign over the system. Installed software could interfere with performance, memory usage, battery life, or even conflict with other previously installed programs causing all sorts of mysterious problems.

Tech enthusiasts had names for these problems. DLL hell referenced programs that failed to run if the wrong version of a file known as a DLL existed on the PC. Bit rot was the slow decay of the overall system. My favorite was registry corruption which was a mostly meaningless term referring to the slowing performance and potential fragility of a specific part of the operating system due to adding too many programs with too many settings. These conditions led to a new class of software designed to clean PCs, freshen them up, and recondition them. But these utilities only further exacerbated any problems and served to reinforce and accelerate the problems that PCs faced over time.

Finally, PCs in the enterprise were locked down by system administrators with an arsenal of software to secure the machines. These included firewalls, antivirus, virtual private networking (VPN), not to mention intrusive scans and analyses of the PC, slowing down every work session, especially just logging on. The fragility and risk to typical users on PCs created the need for more software, ever more invasive software, to mitigate those risks.

 A typical office worker faced a choice of a lethargic PC at work with disabled capabilities or a PC at home that became increasingly flaky as members of a household continued to pile on an assortment of downloaded software.

As real as all of these were, none were relevant to Office which by and large was well-behaved. We needed to dig deeper. Bloat was our biggest competitive problem. Office still lacked a major competitor, but increasingly the cost and heft of Office were viewed as liabilities or targets. StarOffice was free and continued to be an annoyance. Piracy of older Office was far more of a competitor, and by virtue of its age was more fragile and prone to viruses and security problems thus worsening the perception of Office.

Startups were beginning to experiment with the latest browsers and the technology pioneered by Microsoft known as AJAX—a style of programming web pages so they behaved more like a typical Windows program with interactivity but with all the benefits of simply being a web page in a browser. Across the web there were startups building simple word processors and drawing programs this way, and even a few spreadsheets and presentation programs. Intuit (makers of Quicken) shipped a browser-based database to compete with Microsoft Access called QuickBase that won an editor’s choice for workgroup software. Microsoft invented AJAX for Outlook Web Access, but the depth of features made it useful for only occasional mail not the all-day transaction processing style of usage in Outlook. AJAX seemed far off for building a full-fledged productivity tool. Nevertheless, Office was investing heavily in making portions of the product browser-native, such as pivot tables in Excel and databases in Access, in addition to Word and PowerPoint documents.

The question in the air and among tech elites was chilling: Was Office finished and were the alternatives to Office good enough? This phrase good enough drove me crazy. It was as though there was something about productivity software that people should just settle for what gets enough of the job done today. Like a middle-aged person fighting off what seemed to be inevitable weight-gain was it slowing metabolism or was there actually a change in behavior? I used to ask rhetorically, “is Word (fill in the version) the peak achievement for humankind when it comes to writing?”

The snide comments about bloat were getting old.

The internet only served to magnify what used to only surface in a review. Along with terms like MicroSloth, Micro$oft, and Windoze, every time a tech writer mentioned Office, positive or not, a chorus of bloatware filled the comments section or as we saw old fashioned letters to the editor.

Bloat was an amorphous concept with numerous manifestations. We needed to get to some actionable definition if we were to make progress—the heart and soul of the brand was at stake.

In spite of bloat, we heard endless requests for new features. At one point we compiled the most recent requests and something like 90% of them were features already in the product. Ouch.

What really got under our collective skin was the constant whine that Office had too many features, most of them unused. We worked hard on all those features and every one of them was traced to solving some problem customers asked about. At least that is what we’d tell ourselves.

This bugged us because the data was entirely conclusive: Most of Office was used. But no one person used the entire product. As if to emphasize this point, most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.

We measured usage for a decade, first with the laborious and entirely manual process of the instrumented version described earlier. With the arrival of the internet and Watson technology, we extended the instrumented product to every Office customer, everywhere. Enabling the telemetry of the product was via opt-in only, totally anonymous, and no identifiable information was collected. Several data points were recorded: what commands were used; if a command was invoked by a keyboard shortcut, menu, or toolbar; how long an operation took; and, importantly, what sequences of commands were executed. Things we guessed at 15 years earlier were knowable in what could be called a census of usage. While some people didn’t opt in, a large enough majority of users (meaning an unbiased and large sample of the population) provided us with data upon which to decide how to evolve the product.

We called the extensions of Watson (previously used for crashes and system hangs) to usage data Software Quality Monitoring (SQM), or “skwim.” SQM was the buzz of the hallway and became the linqua franca of the program management team. SQM was how we settled debates over who used what, how much, and what was most important. The insights gained from SQM were as exhaustive as the volumes of charts, tables, and graphs that filled our collective inboxes.

Decades later, the idea of using data to design products is a well-understood approach. At the turn of the millennium, it was new and radical, and a strategic advantage. We focused on using data to figure out how to get things done faster and with fewer clicks. Web sites were using data to figure out how to get people to buy more online, read certain articles, or to click on advertisements. Here we were using data to help people use the product less.

What we were learning with SQM, however, was that people were futzing a great deal with Office. While the most common commands were the obvious (Print, Save, Copy, Paste, Bold, and a few others), with astonishing frequency users were hitting Undo, Redo, Undo sequences trying to figure out how something might work. Seemingly common operations like creating a chart in Excel or a table in Word were tiresome and endless sequences of trial and error. A trivial task in PowerPoint, such as aligning two shapes in a drawing, was done by nudging with arrow keys and eyeing the result, rather than using the built-in alignment tools that were a few (too many) clicks away.

We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable. The idea that documents were being debugged mirrored the complex dialog boxes for adjusting formatting. These user interface elements had incredible series of buttons, measurements, and options available with no indication of what to use when. The picture positioning dialog in Word featured a dizzying array of horizonal and vertical alignments with many options always greyed out, and no simple way to indicate a desire to stop moving everything around so much.

There were routine offenders like trying to fix the spacing between paragraphs or position an image in Word, or the impossibility of altering a chart in Excel. The mere mention of bullets and numbering would be followed invariably by a groan. Arguably, the worst offenders were the infrequently used idioms: creating labels used for holiday cards or the one time when a table called for alternating bands of shading in rows or columns. Inevitably, a person sat there looking at the screen trying to recall how they did it the year before.

None of this was new. A decade earlier, I was taking notes at a planning offsite with the Systems team. The laptop I was using was connected to a projector so everyone on the team could see the notes. In a quick sequence of keys, I created a blank page, a heading, and then followed that with subcategories and bullets. I didn’t leave the keyboard. My breakout group watching me insisted on knowing what sorcery I conjured to create an outline in such a way. That was typical for anyone skilled in Office.

Every plane trip was a usability test opportunity for Office. Watching a seatmate analyze sales in Excel while simultaneously using a calculator was typical—and spectacularly difficult to watch. The daily work of using Office to create great-looking documents was filled with moments of, “If I could only figure out how.” A common task for many, something like a product description page with a photo with text flowing, was impossibly confounding.

The specific user interface for these and other scenarios were an array of options, terms, and choices that are meaningless at best and destructive at worst. Even finding the right place to make a change was a leap in logic for typical users who did not have the benefit of software design expertise or the constraint of just trying to figure out where to squeeze it into the product. Offenders such as the paragraph formatting or picture layout in Word or the Excel cell format options appear to most people to have the same level of complexity seen in the cockpit of an airplane.

It was as painful for us as it was for customers. We sincerely believed we made things easier over the years. We had come a long way since the first reviews of Word 1.0 for MS-DOS that called it “difficult to use.” We came to realize that after a decade, our user interface mapped directly to the implementation of the product—literally the data structures and structure of the code—and not to the results that a person was aiming to achieve. This was incredibly important for us to internalize.

It was not as though we were the first people to stumble upon the idea of making computers easy to use. It was more that after a good run of nearly two decades of trying to make products using a graphical interface easier, we needed a new approach. The irony was that the graphical interface itself, with its friendly mouse and menus, was supposed to finally make computers easier to use. Instead, more features and capabilities went underutilized and over time no one was around to remember just how impossible to use early software really was.

The earliest days of the graphical interface and the pioneering belief of Office was that consistency was the fastest path to easy. This was especially the case because Office was rooted in a collection of historically different applications. If a customer invested the time in learning one module of Office, then consistency made it easier to learn the next, and the one after that. An entire generation of reviews and industry analysis (and even my competitive analysis of Lotus SmartSuite) dove deep into consistency as a positive benefit. When computers were new to the world, it might have been that consistency felt safe and easy. Even IBM documented a consistent interface for the OS/2 operating system called common user access (CUA) that was to span mainframes to PCs, with a rack of design books for developers to follow (they did not).

The internet changed this for everyone by being wildly inconsistent. The web quickly evolved to a cacophony of user interfaces. The text and pictures, with blue links to navigate to the web, transformed into an environment as diverse as a stack of Gen-X magazines. The important lesson for us was that people didn’t notice. Yes, there were sites that were difficult and sites that were easy, but people adapted to adapting. No powers were calling for a standard interface for the internet. As the essayist Ralph Waldo Emerson said, a “foolish consistency is the hobgoblin of little minds.” This saying was used in an influential academic paper on the pros and cons of user interface consistency that appeared in 1989. Several times as a program manager I made copies of this paper and distributed it.

While the Office Assistant was the last major attempt and failure to make software easier, by Office 2003 the product was filled with a series of widgets and affordances designed to surface features in a more helpful manner. Office became a stage for every designer and program manager idea to make things easier at a micro-level, one addition at a time. What started off as something simple, like keyboard shortcuts and dialog boxes, ballooned into context menus, wizards, panes, and toolbars, all customizable, floating, docking, and resizable. The next section will detail some of this history.

Bloat wasn’t that products did too much. The marginal cost—in dollars, memory, disk space, or vague notions of complexity—was not bloat. We tried reducing bloat by hiding features as discussed previously, but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.

We began to consider that bloat was the inability to feel mastery of a product, knowing that the product was capable of something while seemingly impossible to figure out how to make it do that something.

Two important lessons from the product planning and research team solidified our collective view of bloat and formed the foundation of designs.

The first lesson emerged from sifting through usage data. Cameron Turner (CameronT) and others studied the depth and breadth of usage of PCs (how many programs, how often) and also features within Office (what features were used). CameronT was an early PowerPoint program manager hired from Stanford who later left Microsoft to start a company focused on analyzing software usage (long before data science was a hot topic).

Watson crash reports trained the team well to work with the 80/20 rule, and Cameron applied this same analysis to features and commands used across Office programs. Looking at features used by everyone (those who opted-in to anonymous telemetry), 80 percent of the users shared only two commands, Copy and Paste. Said a different way, Copy and Paste were the only commands used by 80 percent of users. In other words, even at the most basic level people used the products in different ways, which was counterintuitive for most observers. At the same time, there were many commands that most people used such as Copy, Paste, Save, and Print. Even then, some commands were not used by even a majority of users, such as Open from the File menu, indicating that a good deal of work happened by opening email attachments or from folders on the desktop. When critics generalized about feature usage in Office, we learned they were almost always wrong.

Importantly, and also counterintuitively, nearly all the commands in the product were used by at least someone somewhere. There was not a lot of dead weight in the product, even accounting for accidental usage or the random case where it was clear a given customer was trying every single thing.

The histogram of usage was steep. There was a small set of commands that represented 80 percent or more clicks and a long Pareto tail for the thousands of other commands.

This second point was obvious to those on the front lines with customers—technical account managers, customer support, and our own sustained engineering teams. Routinely we saw what most would call esoteric use.

The breadth of usage was a major selling point of the product as well. At the high level, while someone might not create a spreadsheet model, that same person might receive one in email. At a deeper level, most in a company might not use a feature such as Track Changes (or Redlining) in Word. But their lawyer would. And contracts or legal letters might arrive via email for review. Rarely used features became part of the work of others. This network of usage was a key advantage of Office and a significant reason behind our ability to win corporate-wide enterprise agreements.

Just as the crash data became an obsession with development and testing, the SQM usage data became an obsession with the designers of our products. In fact, developers also loved SQM data. It gave them a way to push back on program management when they thought spending energy on a feature was a low-yield effort.

The second lesson was about how an individual experienced Office. In parallel, Tim Briggs (TBriggs) was one of the early user researchers to join the Office research team. He began to employ (then) sophisticated eye-tracking studies with volunteer test subjects in our labs. In eye-tracking studies, the test subjects sat in front of a PC and performed a series of typical scenarios. Special cameras were trained on their eyes monitoring where on the screen they looked. A program manager or designer watching the test saw a typical PC screen with Word or Excel running and a little dot flying around the screen representing the subject’s eye focus. The test software drew tracking lines, like a route across the screen, and compiled statistics on the amount of movement, total gaze time, or even how much a subject seemed to look around trying to find something—rocket science at the time.

The results of this technique on Office 2003 were shocking. For basic tasks, if people did not know what to do, they scanned the entire screen in a seemingly random pattern, often for many seconds. They played hide-and-seek with menus and toolbars as they searched for something. The test software generated a heat map, a color-coded view of the computer screen showing where the subject looked most frequently—deep red for the hot areas looked at the most all the way to blue where subjects looked the least. The Office 2003 screen looked like a sea of solid red across the main toolbars and menus. Our test subjects looked everywhere for a long time.

The user interface carefully crafted over a decade was in no way helpful. It was bloated.

Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.

In past experiences with bloat, we only focused on two measures. First, we tried to reduce the user interface surface area by simply hiding commands behind context menus or full/short menus or even toolbars to some degree. Second, we spent countless cycles reducing the amount of disk space and memory consumed by Office to reduce the notion that Office was big or slow.

These are both bloat but that is a narrow and technical definition, one that is engineering focused and not particularly useful to customers. It didn’t really matter if the product used too much memory or disk space, as those seemed like symptoms of the whole computing experience.

In the eyes of customers in practice, bloat comes from the fact (using that word on purpose) that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration is what it means to deliver a bloated product. It did not matter how many ease-of-use features we added, all that did was compound the problem of too many placers to click. What good is a new wizard or task pane if a person has no idea how to access that or if accessing it will yield the desired result.

Bloat is owning a product that you cannot master. No one felt they could master Office.

How is it that Office managed to get to this point and when did it become a problem?

On to 078. A Tour of “Ye Olde Museum Of Office Past”

Welcome to a new chapter. As we approached the launch of the massive Microsoft Office System 2003, it was time to plan a new release and that started by drawing a proverbial line, at least I felt so. We pivoted way too much to enterprise and clearly lost the “personal” in “personal productivity.” It was not that we needed to go back to just building features for individual users editing documents, but our entire product was just too enterprise focused. While the product group owns responsibility, the whole company focus on enterprise meant that no matter what we did, as the product filtered through marketing to global sales to subsidiaries it became even more enterprise (as we saw with XML rising to the top of the release positioning, for example).

As I later told a Microsoft Board Director, betting on enterprise customers is a Faustian bargain—done right and the business is fantastic, but when you do it right products become rigid, complex, and diverge from the end-user. This next release of Office, Office “12” or Office12, was a chance to rethink the complexity and refocus on end-users.

This necessitated a new approach based on riskier innovation, not more disconnected features in the apps, or a design refresh. Our plan was to combat the notion that productivity tools were “bloated” and “commoditized” with an innovative complete rethink of how users interacted with the product. This was going to be much more than user-experience tweaks or “skinning” as it was called. We set out to invent a new paradigm that built on the classical WIMP (Windows, Icons, Menu, Pointer) taking it to a new level of abstraction more appropriate for modern computing—the use of “modern” would become a big part of everything we did.

As part of Office12, we introduced browser-based versions of many core components of Office in addition to Outlook, added many new features, and dramatically improve the quality and security of the product. As amazing as those would be, the new innovative experience was a “bet the farm” innovation that would dominate all the other features, whether we got it right or not. It wasn’t enough to invent, design, and build the product, but customers had to accept it. Fresh off the success of Outlook’s redesign we were emboldened and confident.

Back to 075. Scaling and Transitions

In 1999, Steve Wildstrom, a widely respected BusinessWeek technology journalist, wrote a series of columns postulating a product called “Office Lite.” The first appeared June 13, 1999 “Office Lite: Less Would Be More.” He wrote one brief column based on a discussion I had with him that spawned a second column and a bit of a letter-writing campaign from readers. It was a classic populist move in the world of tech to solicit readers for their wishes, though usually reserved for the annual “what would be the perfect laptop” column most writers did at the year end.

BusinessWeek printed a few letters but took advantage of the relatively new web site and shared dozens more online. In just about every way the letters showed passion for the concept of a smaller, lighter-weight, more tailored version of Office. What could be better than an Office that was easier to use, consumed fewer system resources, and performed better. . .and cost less?

Readers of the column in addition to Wildstrom chimed in with what features of Office to remove. Word has no need to support complex page layouts. No need to support embedding spreadsheets in word processor or videos in a presentation. Remove Visual Basic from the apps as that is really for corporates and even if it isn’t used it adds complexity no one needs.

One reader provided details on the product in the form of a specification “(1) creating, formatting, saving, and printing a document (2) Creating, formatting, saving, and printing a worksheet and a graph (3) Inserting a graph and an image within a document (4) Creating tables within a document using a worksheet and/or a database (5) Creating and updating a database, and generating a report.”

Also important were what features to keep. There should be a full suite of a word processor, spreadsheet, and PowerPoint (much to Wildstrom’s surprise). Each of those were deemed essential. The file formats should be compatible with “big” Office. One reader insisted Lite include “free spell/grammar checkers in multiple languages for those of us in Europe who still write occasionally in French, Spanish, and German.” And another pointed out “why did you leave Access out of you [sic] suggested suite? I think Access is equally as important to a home user as PowerPoint or Excel.”

Also, it should be cheaper. Wildstrom suggested it cost less than $499, though noted the availability of less expensive Office suites.

A common point expressed was who would benefit from Office Lite. Sometimes readers pointed out they would not use it, but they thought it would be better for their kids or retired people, or just non-technical users. We previously discussed the challenge of feedback when it offers an idea that is good for others, but not for the person offering the feedback. That’s gracious but almost always a sign that the product is heading for poor reviews. Coincidently Wildstrom wrote in his positive review of Office 97 that the Office Assistant, Clippy, would be great for other people, just not him.

This column caused quite stir within the Office team especially in marketing. Honestly, it hit a nerve. For many individuals Office had become too much software. It also touched on the fact that the PC itself had become too complicated, too fragile, and too hard to keep working. Many readers used the word “bloat” to describe Office, a word that appeared a half dozen times across the stories and letters. In the next section we will develop a more complete definition, but suffice it to say between too many features, slow, fragile, complicated, and difficult there is an answer to be found. Customers expressing the concept of bloat was hardly new to us. Our own concerns go as far back as the earliest Macintosh applications when we added “Full Menus” and “Short Menus” to reduce the product’s perceived overhead.

Reading the letters in detail, one could see they made just about every argument as to why such a product didn’t stand a chance in the market. Every person writing in had a different idea of what features should be in such a product and why their features uniquely made sense. Wildstrom included what I shared with him about the use of features in the product relaying "that most people use only a fraction of the features in a program such as Word. But everyone uses a different fraction, so there's no way to design a simplified program with broad appeal.” His readers made that very point in their own way.

In my numerous discussions with Wildstrom over these columns (and basically at every meeting) I would point out that we already had “Office Lite”—called Microsoft Works. That was my refrain for years when it came to the need for a low-priced, slimmed down version of Office. In the mass of letters to BusinessWeek someone else, someone with an informed opinion, agreed with me in their letter:

We'll [sic], you're right to be championing "Office Lite," but you're wrong to be dismissing Microsoft Works for the job. Sure it has many inadequacies, but saying it needs features X, Y, and Z to warrant your recommendation is to set your steps in the direction that led to Office 2000 bloatware.

Peter NortonLos AngelesNorton is a pioneer PC programmer and author of numerous books on PC software.

We offered Works at about $100 and Office SKUs at different price points ranging from about $149 to $499, including Student & Teacher, Small Business, Standard, Professional, Developer, and Enterprise. By most definitions in pricing architectures, we were meeting customers at low, medium, high, and very high prices with products offering different value propositions. It should be apparent, however, there was hardly a consensus among the press and its readers on what an alternative price and value structure might look like.

Microsoft Works was an early success, a genuine hit product for the company. Version 1.0 was released in 1987 and joined the ranks of the wildly popular category called all-in-one or integrated software. The category aimed to take the popular modules of productivity and bundle them into a single, easy-to-use, and low-priced product, usually including a word processor, spreadsheet, and database (Works included a communication module as well).

The basic assertion was, and keep in mind how early in the PC era this takes place, that the full-priced products were too expensive and did too many things (had too many features) and most people needed only a fraction of the product. This was bloat even in the earliest days of computing. Works sold for about half of what a single full-priced product cost and ran on very basic PCs with merely 384K of memory. Works was hugely popular outside the US and was localized into dozens of languages, often a tricky proposition in the days of MS-DOS software. Works was a marvel of engineering built with great passion by a small team, and thus extremely profitable.

In 1991, Microsoft released the first Windows version of Works, for Windows 3.0. Again, this product proved popular, though not as much globally where Windows was a slow burn due to hardware requirements. Works for Windows, or WinWorks as we called it, introduced some of the early toolbars and wizards. It was developed in the Consumer Division, home of those inventions and to product teams entirely focused on the home and student markets. WinWorks also supported OLE (Object Linking and Embedding), the enormously complex to implement capability to include data from other applications inside of documents and even included an early Microsoft drawing program to show off that capability. Microsoft made works available for less than $200 at retail and often for only $10 to PC makers looking to include basic software with a new PC. By 2003, Works included a broad range of software for the home user in addition to the all-in-one product including personal finance, maps of the world and major cities, an encyclopedia, a sophisticated photo editing program (PhotoDraw), and somewhat surprisingly the full and current version of Microsoft Word.

On the surface Microsoft had addressed the classic marketing problem of low-end and high-end with price support at the low-end. We could sell Works to price-sensitive customers and Office to everyone else. With the PC manufacturing channel, we could even tactically go after market share for certain PC models aimed at home and small business customers. Like all good marketers we would only sell Works when we had to, with all marketing and sales efforts aimed at selling Office. Even the Works customer would see opportunities to upgrade to Office. That seemed simple enough. On paper this looked like a great spot to be.

There were two problems. First, Works was not compatible with Office. It was only marginally similar in how the user interface worked and not at all compatible with files created by Office, nor was Office able to read Works files. Why would this matter in a world without networking or email? It didn’t. Any given person would just use one or the other and it would be fine to print documents when they were finished with their work. But in our world, the press would ask questions and then make assumptions that all products from the company would interoperate, and by the early 2000s emailing documents was becoming a scenario for many home users. This product limitation led to the eventual inclusion of Word, though not Excel or PowerPoint, in the Works bundle. We failed these tests and too often the product was labeled as incompatible, and in the PC world incompatible is a big blow. Customers expected compatibility from Microsoft.

Second, and this gets to the heart of the matter, people didn’t desire the product that did less. They wanted all the bells and whistles of Office. They just didn’t want to pay full price, or they didn’t have a computer with enough power to run Office. They wanted a more powerful computer and would almost certainly invest in that rather than stop-gap software for their current computer. We had a classic revealed preference problem in customers saying one thing but choosing to take a different action. There was no way around this—customers just wanted more product for less money.

This second point is the marketing challenge everyone with a successful product in software faces at some point.

The natural inclination is to remove some capabilities and charge less. Usually, it is possible to remove features that only a certain customer segment wants (enterprise for example) and that keeps the price low for customers that do not need such features. Today we see this as routine practice where a low-end or even free version of a product is used to upsell to increasingly expensive and feature-rich versions. Again, on the surface this is what we had for varying suites of Office, but we did not have that for the individual applications in Office.

We had a pricing problem. We did not have a product problem in the sense of getting value for the money paid. Customers wanted the value, just not the price. They also wanted the product to be better and sometimes they equated the high price with the reason it was not better, as if a lower price would require less disk space or be easier to use, for example.

Office also faced a competitor with a much lower price, free. Such a competitor is an especially acute problem when that product has a comparable feature set, whether that is real or simply perceived as such. OpenOffice claimed to be compatible and was certainly more compatible than Works, and it also claimed to have the features of full Office. If it was missing features, they promised to add them as soon as possible, just as I personally learned when they changed the product on a tradeshow floor to be more like Microsoft Office.

The scary question for us was would Office be susceptible to defeat in the market by a direct clone. Borland had been successful at making a dent in Lotus 1-2-3 sales and with the relaxed view of copyright law in the courts this seemed a legitimate concern. Still, the technical requirements to acceptably clone Word, Excel, and PowerPoint seemed insurmountable. We knew this because of how much effort it took us to maintain compatibility and document fidelity between our own versions with our own engineers.

In an interesting twist, some enterprise customers equated the low or free price of competitors with low-quality.

In other words, our pricing challenge was not as straight-forward when looked at broadly. This mattered because software did not have highly specific distribution channels like cars or mattresses where we could control which channel sold which products.

The legendary author and marketing guru Geoffrey Moore visited Microsoft in the early 1990s to meet with a few of us to talk about Office. This was before Windows 95 and 32-bit computing, before Office had “won.” Our minds were on adding features and getting new features to market to compete with the category share leaders that dominated the industry by revenue. The conversation was deeply interesting when I look back, though at the time it was not as relevant to Office as one might have thought.

According to Moore as per his Crossing the Chasm framework and book, the PC was still in the early adopter phase. Moore suggested as per the framework that we needed to consider products for specific subsegments of early adopters (legal, financial, consulting, education) providing versions of Office for each of those in succession as we grew the market to later stages of technology adoption. We were worried about price support versus Works, not against a competitor selling a different product specific to bankers or something. Tailoring Office for specific customers, however, was in some way the role of Works, except rather than job title it was skill level or distribution channel. The real mismatch, however, was that we were not struggling to gain adoption with the personal computer. We didn’t have a crossing the chasm problem. We just had to wait for people to have enough money to buy a PC and pay for the software. We didn’t have a segmentation problem. Everyone wanted Office. We did have a revenue maximization problem. We didn’t want a lot of people buying Works.

One problem we did have was software piracy. It was long a bane of Microsoft’s as the company was founded on the premise that software should be paid for just like hardware. Piracy of Office had grown astronomically. We estimated that perhaps 1 in 10 PCs paid us for an Office license, but more than half the PCs out there had at least one major Office application. It was technically easy to pirate Office as we did not employ any countermeasures as were common to software products in the 1980s. With the release of Windows XP (Windows too had a significant piracy problem), Microsoft put in place a global software license enforcement program much to the chagrin of tech enthusiasts and early adopters, not to mention small businesses that often bought one copy of a product and just assumed it would work for a workplace with a few PCs. To say this program was met with mixed results would understate the uproar. Some whole countries prohibited the use of anti-piracy measures and others mandated different mechanisms or terms of use. China officials famously lectured many of us (me personally) by applying lessons from the writings of Confucius (always said with erudition), “software is like a book; it is selfish not to share.” I never looked up if that was an actual quote, but ministers and vice ministers lectured me enough I took it as such.

The result of high piracy? In many markets, customers simply stuck with the older and easy to pirate version of Office. On trips to markets from Italy to South Africa to China, members of the team would invariably return with a CDROM filled with Office 97 and everything Microsoft made five years ago bought on the street for $5. On a trip to China during the launch of Office 2003, I went to a tech market where I was offered a form to fill out where I picked what software I wanted up to the 650MB limit of a CDROM (Office 97, Windows 98, and so on) and within an hour I received my custom CD for just 20 kuai (less than $2).

Absent Microsoft corporate backing off from anti-piracy, something the field salespeople desperately wanted us to do, the calls for a cheaper version of Office were constant. They weren’t quite sure what that would be, but they didn’t want people to like it so much they would buy it instead of the Office that carried a sales quota. Many of the subsidiaries would try to make a case that people could not afford software, even though I saw the price of PCs at the market mirror those in the US, or in some markets such as Brazil PC prices were even higher. The issue was there was a way not to pay, not a lack of ability to pay for software. SteveB loved to point out that the computer market was located near an imported car dealership complete with Lamborghini and Ferrari on display.

The PC itself was also under attack for being too expensive. The One Laptop Per Child (OLPC) initiative out of the MIT Media Lab started in 2005 to address this concern with the goal of providing an extremely low-priced computer running free software for students in emerging markets. Windows quickly followed with their own effort to build an even cheaper version of Windows. This will not be the last of this challenge for me or the industry.

Given this context, the refrain for a low-end variant of Office had been echoing in Redmond for years but now was reaching almost deafening levels. I didn’t really have a choice but to start a project and see where it went. I kicked off a unilateral skunkworks project (without marketing or broad buy-in) to see if we could come up with something that would end this endless discussion. The project even had a code name, Firefly. You can always tell when I wasn’t wild about something when I gave it a code name. The team needed to go through a process to bring closure once and for all. With most of the effort centered on the user interface and access to features, Julie Larson-Green (JulieLar) led the effort from Office program management where she was now leading the shared user-interface team, moving over from FrontPage.

We completely understood how every other product from cars to microwaves to stereos had a cascade of price points for basically the same product. The difference for Office is twofold. First, software is soft, and the marginal cost of more features is zero and customers readily see that. Second, interoperability between price points is key in a networked world and maintaining interoperability when different users can be editing a document with what amount to different tools all at the same time was technically difficult to imagine getting right.

I kicked off project Firefly, which quickly became known as Office Lite, knowing (perhaps that is too strong, I mean assuming) we would go through the exercise of figuring it out only to conclude that no one at the company really wanted it. No one would want to be responsible for releasing a product that was either so bad no one wanted to buy it and the Office brand would get devalued or so good that our enterprise customers would insist on having the Lite version of Office for much less revenue.

The reason I picked a code name was because the mere expression of Office Lite (or Office ES, or Office Prime, or any other marketing moniker) would cause customers to say, “that’s the one I want.” They would do so by attaching all positive attributes to the product: just the features I need, easier to use, boots and loads faster, takes far fewer system resources, and because of those attributes it is also less buggy and won’t crash. There’s something about how low-end products always garner catchy names. Sure enough the name “Office Lite” leaked to the press and customers early in this process.

Our new leader for Office marketing was hired from Adobe. They had not only faced the same problem but tried to do something about it. With its PDF product, Adobe had been struggling with the classic strategy of a free viewer and a paid-for product with the ability to create PDF and a better viewer. The problem they faced was that creating PDF was rapidly commoditized and free (this is the topic of a future section in this chapter as well) and few people needed the advanced viewing features, and certainly not for hundreds of dollars. With their flagship Photoshop product, Adobe had been trying to seed the low-end market with Photoshop Elements (there’s that catchy name) side-by-side with Photoshop. This product still exists today, so we can assume it works for them. I’d say it works so well because you never see it being used (of course I have no data on the real usage and am just speaking anecdotally). This Adobe experience led me to believe that Office would be viewed through this same lens by marketing.

The first step in developing Office Lite would be to go through an exercise where we removed a bunch of features from the product. Doing so technically is not difficult, one would think, but in practice the list of hypothetical problems gets very long very quickly. As an example, someone creates a template in Word that makes a document look a certain way. The document is then sent to someone else who has Word Lite. Can they see the new look? Can they edit the new look? What if they try to modify text within the context of formatting that looks a certain way? How do formulas work in Excel? Does Excel Lite have all the same formulas? What if a spreadsheet with a Pivot Table is sent to an Excel Lite customer, can they pivot it? The list goes on and on.

The fun part of this exercise was just how easy everyone thought it would be. Almost to a person, the first things to be removed for Lite were Visual Basic for Applications, Mail Merge in Word, Pivot Tables in Excel, animations in PowerPoint, then circle back to Word and remove features like table of contents and legal citations, track changes/revision marks, and so on. Everyone brainstorming found it easy to make their own list of easy to lose features.

There’s a core assumption these features aren’t used and so it is easy. That’s the problem. Everyone had an easy time removing features they believed they didn’t need. How does that reconcile with creating a product that the enterprise customers would not want? It doesn’t. In the next sections we will dig into the realities of what features are used or not as we design the next release—we had the real-world data on usage. For now, suffice it to say that it is very easy to make a list of features to remove but very difficult to remove any features that cause customers to feel they need the full version of the product. Those are painful decisions.

Some discussions became almost comical. One of my favorite examples had to do with documentation. For years, Office produced weighty tomes of printed books of documentation that more often than not served as ergonomic monitor risers if the end-users even got to see them. With the rise of enterprise agreements, we moved most documentation online. With the internet we were very excited to have always improving documentation available directly from within the product. One of the key differentiators for Office Lite was a proposal that the only documentation be available as a printed book that would come with the product and no online documentation or connection to the web. We no longer had the ability to produce printed documentation, and before I knew it someone in marketing already put out bid proposals to publishers to create the book for us. The cheap to make Office Lite was getting to be more expensive and have a higher bill of materials than the real Office.

One person who was hardcore about what not to remove was BillG. I exchanged mail with him over some of the rumors he heard about Office Lite and he came back to me saying exactly what I predicted he would say, which is we can’t remove any platform features, such as Visual Basic for Applications. A lesson learned the hard way with platforms is that platforms must be consistent for developers to choose to use them. While it is fine to adorn the platforms differently for various price points, anything a developer might want to use must be in the baseline SKU. Otherwise, they will work around it and either implement something on their own without using the platform or simply not have a feature. That’s why every Windows API is in every Windows SKU where developers can always count on them being there (recall the Tablet PC discussion).

Cameron Turner (CameronT) on the product planning team developed a framework for the brainstorming efforts for Office Lite. I gave up calling it Firefly. These goals included: great for creating simple documents, a great viewer for all Office files regardless of where they were created, effective competitive response to low-end competitors, smallest delta from full Office to reach design goals.

The team also developed a view of who the product was not going to be for. Office Lite is not for: group collaboration, data analysts, developers, online communicators (no Outlook), “beginners”, or multi-language document creators.

The Office team was long expert at resolving what appear to be impossible to resolve challenges such as shipping on time versus shipping with quality. The Office Lite goals, however, were almost certainly, perhaps mathematically, unsolvable. Even something that to Americans seems simple like not supporting multi-lingual documents, becomes problematic for sales even in neighboring Canada. The most unsolvable constraint was that the product wasn’t for beginners. If not for beginners or the home and not for specialists in finance or law, then who was the product for? Who is this broad middle and what are they doing? In this stage of PC expansion, there were tens of millions of customers getting their first PC and first use of Office at work. They were beginners too.

Rumors about Office Lite started making their way around Microsoft. Marketing teams across the company were getting very excited at the prospect of a low-priced Office because for some time they had wanted to have the Office brand associated with their product, but the price was too high. The Windows OEM group, the team responsible for selling Windows to PC makers, wanted nothing more than Office attached to every new PC “socket”. They hated selling Works because it was so cheap. OEMs expected Office Lite to be only marginally more than Works. The emerging market teams loved the idea of a cheaper Office.

Then people started to think through the issues and how revenue would suffer. Not just revenue, but the sales quotas carried by each subsidiary and sales segment.

It didn’t take long before the Office small business marketing team would come to realize that if every Dell Small Business PC came with Office Lite presumably because the OEM team was successful, they’d never make their numbers for selling the Office Small Business SKU. There weren’t enough small business PCs to make it up in volume.

The MSN, Microsoft Network, team was working hard to develop a paid offering because the advertising business was not yet large enough to sustain the investment we were making (recall the pressures mounting on the investment businesses from the previous chapter). They were very excited about being able to bundle Office Lite with a new MSN subscription. We had not yet arrived at a price, but it was obvious that like OEM they though it would add $1 or $2 to the monthly subscription, which was a Works level of pricing, not Office.

Then the other shoe started to drop. Not just the BillG shoe but the global enterprise field. Suddenly my inbox was filled with subject lines “Rumors about Office Lite,” “Concerns about Office Lite,” “Office revenue goals and Lite.” These emails expressed incredible reservations about the potential for tanking the existing business in favor of a product that, by knowing only the name, the salespeople thought was too desirable for too low a price. My good friends in MSKK (Microsoft Japan) sent me a note directly stating they decided not to offer Office Lite in their market. They were so against the idea they just presumptively closed off any discussion in the most non-Japanese way I could imagine.

Problems such as these could be solved. Many businesses solve them all the time. Cars have low end models with a magical suggested retail price, but they do a fantastic job constraining supply of that model. Consumer electronics (including PCs) almost always have good, better, best, but these are often easily distinguished based on capacity measures (memory, watts, screen size) and also by distribution (where the products are sold). Imagine if Word Lite limited documents to 10 pages or Excel Lite had row and column limits.

Software, especially when exchanging data files and documents in a network, do not lend themselves to these artificial constraints. Those that grew up with IBM mainframes know the frustration of IBM upgrades when customers would request a higher-priced hardware upgrade and a tech would show up and simply crack open the case and turn a screw to enable the upgrade costing thousands of dollars per month (this didn’t really happen, but the stories were legendary).

Unlike these other products we were also squeezed at the high end. Office for enterprise customers is designed to be a bundle with everything we sell. As discussed with the addition of Outlook, SharePoint, OneNote, and InfoPath, there was no support for adding more expensive enterprise “bits.” Today many cloud software applications save enterprise capabilities such as security and management for the high-priced (or just priced) SKUs. With Office, 80% or more of the revenue was already coming from the enterprise SKU. There was no appetite to move up with higher prices, which could make the lowest priced SKUs more price-friendly.

The process of planning the SKUs for Office 2003 was an exercise in chasing our own tails, so much so that we spent a significant amount of engineering time to create a push-button feature that enabled the production of a new SKU (a different combination of the 11 different applications) to be created without additional code or testing. This came in handy as the Office System 2003 Editions were rolled out with seven different SKUs.

We started to toy with the idea of being able to dynamically enable or disable different features in this same way so we could make progress on whether Office Lite was even possible. At the plumbing level this was not difficult but with thousands of features and product design elements such as toolbars that depend on features existing, it was not practical.

The design started to go from brainstorming to an actual product offering in a table form. Suddenly, Office Lite did not look so good. After all the sessions over features to remove, the desire to remove features faded away. The team created a table comparing the proposed Office Lite product to competitors. The resulting table was a disaster. It looked like one of those magazine reviews where a product gets clobbered for missing all the checkboxes. After getting feedback from the subsidiaries and hearing their lack of desire to even offer Office Lite, the risk of the subs failing to make their numbers and blaming Office Lite became real. The reality that Office Lite would be a non-competitive product versus our free competitor sucked all the excitement out of the potential offering. It didn’t matter what we removed from the product, OpenOffice could just add it to their product, and charge nothing.

Office Lite was dead. Again. We had to win in the market with a better product that cost more. We had the product people wanted and we needed to sell it harder if that’s what it took. Today we know we had product-market fit and a little thing like pricing was not going to be our biggest problem. By comparison, the Office price of $499 for a perpetual (runs forever) license of Office or the roughly $150-200/year for an enterprise 3-year agreement is comparable to an Office 365 today that can easily cost an enterprise more than $650/year per license, though Microsoft is running Exchange and SharePoint in the cloud in these plans.

What was not dead, however, was what got us talking about Office Lite in the first place. The customer concerns were not really about price. Price was a proxy for bloat. We needed to address bloat. We tried before but now it was critical.

What the heck does bloat mean?

On to 077. What Is Software Bloat, Really?

Wrapping up the development of Office 2003 was an enormously challenging time for me personally, while the team continued to do well finishing a release with an unprecedented breadth and depth. At the executive level the company was under enormous strain, not because of a lack of business results (quite the opposite), but from what the NY Times called a "popularity problem". The core business was less dependent on Windows than ever before and in fact the percentage of Microsoft revenue or profits from Windows likely peaked. In addition, the Server business and Office were doing extremely well. Few companies have more than a single tier 1 business, let alone nearly a dozen billion-dollar products. Wall Street, however, was no more happy with Microsoft than it was with most every other company. In 2010, the "lost decade" was used to describe the lack of broad stock market returns over the past decade (2000-2010). Some began to apply that to Microsoft specifically with the rise of Google, then Facebook, and Apple’s resurgence in consumer devices. This post details the start of that period and I will leave it to readers to judge if this was truly such a start, or if indeed, we simply had a popularity problem, or something altogether different.

Back to 074. Outlook Pride, Finally

Over the course of building Office 11, Microsoft began to see cultural transformations that in hindsight were the product of trying to mature as an organization while not taking on the risk of changing as an organization. It was as though we wanted to add all the benefits of a coordinated, multi-dimensional-thinking, well-executing, mature company while at the same time not taking away the hardcore, code-centric, engineering-driven culture that got us to where we were. The goal was laudable. How could it not be? The only surprise was how long it took us to get to this point.

Around the company we were not executing well, not even a little bit. To some, however, it felt like we were executing. That was only because we had so many activities going on. Everyone was very busy (just try scheduling a meeting with someone) with launches, pre-releases, community gatherings, partner events, PR outreach, ecosystems, big reorgs, offsites, slide decks, spreadsheets, reporting systems, and more. The airmiles were accumulating at a phenomenal rate. A big company has an ability to show a great deal of activity even with little progress. What wasn’t happening was new product innovation, except financially. That distinction is important. The money was coming in but that was for all the products we had already built, in some cases several years earlier.

Microsoft saw less than stellar success across most of our new initiatives. If the primary goal was to gain market share, then we were losing.  SteveB used to say “share is air.” Whether it was phones, consoles, web sites, advertising, and so on, the first few years of the millennium looked like the dot com startups we had ridiculed. To clarify our new initiatives, Microsoft began to report earnings across seven operating segments: Client (Windows), Server and Tools (Windows Server, SQL Server, Exchange, Visual Studio), Information Worker (Office), Microsoft Business Solutions (Great Plains/Dynamics), MSN (all the “consumer online” properties), Mobile and Embedded Devices (Windows Mobile), and Home and Entertainment (Xbox, consumer hardware). Every earnings call and cover story about Microsoft asked when these new businesses would become “profitable”. The calls for “when will you win” were deafening.

Such a question was a naïve approach to how business worked, but that’s how bringing visibility to a product under development is talked about (anyone who has run a business knows that new products are not profitable at the outset and take years for a full P&L view to look profitable, but that’s not how people comment on earnings). At company meetings or routine team meetings, SteveB had a great series of slides where he emphasized the long-term nature of Microsoft’s approach and what it means to invest in the future—“investing” Steve would always emphasize. As a reminder, Windows took at least six years and three major versions for it to become a significant product. Had Windows been reported separately from MS-DOS it is not clear Wall Street would have been forgiving.

The new businesses were still much newer and were part of a vastly larger landscape than Windows or Office were years earlier. Combined, the four investment-mode new businesses (MSN, Mobile and Embedded, Home and Entertainment, Business Solutions) had a (FY 2003) negative operating income of $1.6 billion. Windows, Server and Tools, and Information Worker had an operating income of $17.9 billion, on total revenue of $32.2 billion. In other words, there was no material risk to the company due to these investments, nevertheless losing money or failing to pay off began to permeate the whole of the company’s operating model and external narrative. Culturally, we weren’t used to negative numbers.

There was an additional problem that drove operational changes. The Windows team began to have the signs of a product spinning out of control (my words). The company was experiencing in real-time what SteveB and I discussed in his first series of one-on-one meetings when he became president a couple of years earlier. Big projects can seem to go from execution to out of control in a flash—there is a fragility in large-scale software projects that we had yet to fully grok. The time it took to complete Windows XP SP2, the resulting desire to produce separate releases for Tablet PC, Media Center, and Windows Server, and expanding strategic inputs from BillG shaping Windows development created a situation where the Windows XP follow-on release, Longhorn, was either “at risk” or “out of control” depending on who you asked. In practice, some still believed it was a typical Windows product cycle.

Beyond the new businesses described by segments, Microsoft had a seemingly infinite breadth of new products under development. Few areas of software went unnoticed without a Microsoft group claiming to be in the space. Yet, we lacked clear strategic view or even line of sight view to all these projects, if or how they fit in, when they might deliver, or what progress they were making. A skeptic would say this was an additional level of potential negative ROI hidden underneath the success (or not) of each segment. Optimists would say this was entrepreneurial thinking at its best. The challenge was that as primarily an enterprise company, the customer demand for a strategy, unification, and clarity were ever-present.

Seeing these challenges drove a shift in how the company operated, at least I that was a root cause. A pendulum swung away from autonomy and lack of rigorous strategic and execution oversight at the top-level towards a more centralized approach to planning and execution. In any business environment I’ve seen, when things aren’t working the inevitable solution is to swing the other direction of some easily identified pendulum. In our case, that meant more corporate standardized processes.

I found such a change challenging (for me in Office) in two ways. First, it felt to me that Office didn’t have these problems. We were executing well and had been for a long time. We had processes and delivered results—even when our projects were late, they were not unbounded, and we promised and delivered on plans without any gaming or redefining of deliverables. Second, the problems seen in these new businesses could look like execution problems, but as we’ll see over the chapters that follow, they were fundamentally strategy and manager (versus management) issues. It wasn’t enough to work to get the trains to run on time if there was no understanding of where the trains should run. Some of the projects were running well, but the destination was poorly understood.

That was my perspective. It was not shared by everyone for two reasons.

First, just as with any business if one wants to make a bear case then that would be possible for Office. What if customers rejected a new version? What if open source OpenOffice took share? What if web-browser Office became a thing suddenly? What if we were out of control and just didn’t know it? We just weren’t going to be blindsided by those in 2003, but there was no way to prove that. Any attempt just sounded defensive. I sounded defensive far too often and that was not good.

Second, the company model for all the new businesses was to be a platform. What do platforms need? They need Office to build on the platform to prove it out. Any lack of success in the new businesses was therefore strongly connected to something the Office team was not participating in. As such, their problems were indeed Office problems. They were my problems. I didn’t really believe they were my problems, and my rolling eyes or audible sighs were the tell.

I was busy finishing Office11. That’s what I knew needed to happen, deep down. Putting up with all that was going on around me I thought added a second job. The Office team had gotten so good at planning and execution that there were plenty of cycles remaining for me to focus on those goings-on, even if I did not find doing so pleasant.

Was this the moment when dreaded bureaucracy was settling in? If only Microsoft would have realized as much, might we have avoided a “lost decade” that followed? The expression “lost decade” became a popular way to describe overall stock market returns in 2010 since the dot com bust. The press started to refer to Microsoft’s own lost decade. In contrast to the broader market Microsoft had a “popularity problem” to quote the New York Times, which said “the company hasn’t received credit for its almost-half-full glass: the 40 percent of its business that is not Windows or Office. . . its enterprise software business, formally labeled Server and Tools, as ‘an incredible business’ accounting.  .  .for about 24 percent of the company’s revenue and with an operating margin of 40 percent.” We were putting up the numbers but unlike Yahoo and Google we did not have a consumer business, and because of the internet and the rise of Google that was all that mattered. Yet, that was by design. We were not putting in place an arbitrary bureaucracy or processes, but the logic behind the changes was to try to have it all: an enterprise business, a consumer business, competitive products, and an overall technology strategy. We were not lost as much as trying to do a lot. Maybe too much. We were Microsoft and we thought big. What’s wrong with that?

Dealing with these processes was challenging for me and it showed. Some aspects were always going to be my style. I did not have a staff (a business manager and/or chief of staff for example) who could spend full time in the preparation meetings for the larger meetings. I made slides I was responsible for by myself and got them done on time, but without endless iterations and sweating over every point that can come with a staff working full time on slides. In doing so I wasn’t always part of the month of pre-meetings leading up to meetings and did not always have the context for when something new became a hot topic amongst the staff (what is the Office answer for “healthcare” that came up in an earlier meeting or what are we doing about “small business” that was in that mail thread from UK). It was obvious to me that the processes were an effort to bring the rigor of the Mid-Year Review (MYR) process used by the subsidiaries and field to product development. It was never clear to me, however, that sort of process would work for the creative and uncertain aspects of product development. I was frustrated that no one ever asked for input over what we were being asked to do.

I believed that tired cliché about building products, which is you can’t know everything before you start but you can cause everything to grind to a halt by asking questions at every step or thinking success can be known before we start. I held that romantic view that building products is an art, and no quantity of meetings could turn it into a science. Perhaps the most frustrating (to others) belief I held, was that questioning too much after a product started was a sure-fire way to bring chaos. That’s what I saw happening.

I agreed with the problems that preceded these process changes. I didn’t see processes as the solution. We were not going to fix things by having better slides or box diagrams. We weren’t executing because we lacked the planning infrastructure and organizational structure that was required to deliver. Such a point of view, however, was difficult to prove because the very nature of the processes we were going through (with names such as Business Plan Review or BPR) was to surface the planning and org structure issues so they could be fixed. We were caught in very tricky loops.

“Competing with Linux” was a long series of meetings that was top of mind for the Server and Tools business and illustrates this point. I was running Linux at home. It was comfortable for me as it brought back muscle memory from college and graduate school (that was technically Unix, just to be completely accurate), but importantly it brought back a lot of technical reminders about the architecture of Linux. Office also experienced the rise of Linux through FrontPage, which achieved far more success connecting to Linux servers on the internet than anywhere (or anyone) else. This would serve me well in the product-led discussions, as would the feedback from internet service providers all running FrontPage on Unix and not Windows NT.

Strategy and execution meetings about Linux were overly focused on the immediate crises of head-to-head sales losses. What should be our pricing? Are we positioning correctly? Do we need a better partner? Many in product groups (the development teams) were familiar with the technology, many deeply so, but the product plans did not reflect Linux as a competitor when viewed through the lens of resource allocation and feature lists. It was as though there was broad acknowledgement of the competitive issues without responding with product plans. The basic idea was that we could win if we didn’t change any of the product plans, where the list of must-do features for enterprise customers continued to grow. The real problem was that the business results made this look like the right decision. The sales of Windows Server continued to rise, and Linux was still free as in free like a puppy. We were winning at least in appearance.

From any objective distance, it became difficult to see the difference between how Windows and Office responded to Linux or competitive risks in general. If I suggested Linux was a real product competitor requiring a significant change in product features over what we would do if Linux wasn’t on our radar, then I could just as easily be challenged over responding to OpenOffice. . .”you lost that sale to the German government didn’t you?” they would knowingly ask. A response claiming it was different just made me look like I too was dodging the issues around Office or something akin to whataboutism.

One Linux review meeting reached a surreal phase when the whole of the all-day meeting with hundreds of slides and many presenters boiled down to a request for headcount in order to effectively compete with Linux. As a matter of practice, that was not how meetings were supposed to go. Headcount requests were for another meeting and process. As though it was to emphasize the matter, the actual headcount ask was for two, yes just 2, heads. The entirety of the strategy to compete with Linux from a 10,000-person division required asking for two heads. It was as crazy as it sounds. To his credit, SteveB was not happy with the ask and the team was not happy with the response.

I hesitate to write the above because my experiences at this time could not possibly reflect experiences of the thousands of people during this same transition. It is not even clear to me today what were causes versus correlations of the challenges we faced. Frankly, some of what seemed so wrong then turned out to not matter at all to where Microsoft is today. Such are complex stories. Such is product-market fit, which is likely the most important lesson. We had the most amazing product-market fit, which (at least according to theory) meant it hardly mattered at all what we did.

Through these new processes I reluctantly learned to be pretty good at telling the Office story with respect to execution. I became well-versed in explaining how we worked, organized, planned, collaborated, and executed. I spent an enormous amount of energy detailing these topics to anyone that would listen. Even very small details such as knowing how many people worked on a given project, something we routinely did for years, would take on almost mythical status as SteveB would ask other groups for a report that looks like the one from Office. They would often ask to connect with the staff that created a chart only to find it was usually just me. There were no secrets. We just did the work, but it did have a cost.

There was some personal history to my desire to do a good job explaining resource allocation within the context of this new business planning framework. Back when we organized for Office9 (Office 2000) one of the significant decisions we made was to allocate resources even more towards Office suite-wide development and also to what would become SharePoint. In doing so, the number of developers on Excel, for example, reduced from an historic high of 50-55 to just under 20. There was controversy and disagreement within the Office team, but that was no match for how BillG viewed such a decision as nearly irresponsible. Yet in a short time it became clear that reallocation for products that had won was a much better approach than to continue to incrementally pile on resources. In real-time, both BillG and SteveB got to see the culture difference between Windows and Office when it came to embarking on new projects. Everything in Windows always seemed to be incrementally new headcount (like Linux compete) and everything in Office was a reallocation. I didn't realize it at the time but using today's terminology I relied on the product-market fit achieved by Word and Excel. We just weren't going to lose in the overall Office business because of incremental features we failed to add to those products, even in 2001.

Counting developers became an obsession with me. Starting in Office 2000 I even did a census where I asked each developer to add a row to a spreadsheet saying what they worked on in their own words so I could compare it to the schedule, the vision, and what team they were on. After that we even started using unused columns in the SAP employee database to record what part of the project a developer worked on—that way the information was always available live and could be kept up to date as employees moved around the team. Any time someone asked me how many people were working on some aspect, I just brought up http://headtrax (the internal front end to SAP data) did a few queries and there was an answer. For data across the whole team I’d just export to Excel and create a pivot table.

Such attention to resource allocation was seemingly encoded in my Apps Division DNA. It came from a reality that it didn’t matter what a team said they were working on, rather it only mattered what developers were actually assigned to. As the company grew and cookie-licking became more common—when teams declare they own or are driving a critical initiative but are doing so without the work or resources to support it—the need to bring clarity to those discussions became even more important. I only wished at the time that more teams had clarity of resource allocation reflected in SAP.

Managing personal time was just as important as clarity on developer allocation. Following a lesson I learned from SteveB for the past few years I tracked where I spent time during the day. How many 1:1s, product meetings, customer and partner meetings, skip-level 1:1s, team meetings, and so on. I did this in a very lightweight manner attaching a category to Outlook schedule items. Every quarter I exported my calendar and created an Excel pivot table of hours spent on these categories.  Over the course of developing Office11 I noticed that I was spending more time in what I labeled “process”, the corporate driven planning and coordinating meetings and that was taking away from ad hoc time just talking with people in the hallways or more structured time with the team. I found this disappointing, if not depressing. When I discussed this with my manager or Steve (in a skip-level with him), usually the feedback I received was that I was not spending enough time on corporate. Somewhere between too much and not enough was probably a better answer. I had reached that point where I felt caught in the middle and failing both of my constituencies. My algorithm for addressing this concern was that the team always won out, whenever it could. I just felt so much more useful in working with the team than in corporate rituals. It was easy to feel good because we were making a ton of progress, especially comparatively.

The team was doing a fantastic job finishing Office11, which was formally named Office 2003. Well, not exactly. With new marketing leadership in place and a mission to be more aggressive along with license to spend more doing so, the product branding was brought more into an enterprise perspective.  Office suites sounded so small. We had so much more software. The entire collection of Information Worker software was branded “more than what it used to be” as “Microsoft Office System”, “now an integrated system of programs, servers, services, and solutions”. The suites of Office programs typically bought were called Editions. This meant Office11 was officially known as “Microsoft Office Professional Edition 2003” or as humans called it, Office 2003.

JeffR approved a major advertising campaign to go with Office 2003, over $150 million, five times the $30 million spent on Office XP. It was one of those campaigns where even the campaign itself gets a PR push and stories about it—marketing of the marketing team. The campaign covered print, online, television, and more (such as airplane video). Called “Great Moments At Work”, the campaign was a playful take at workplace successes as though success was celebrated like sports complete with pile ups and high-fives. The ads were fun. The print ads used photos of the same scenes but emphasized the sheer breadth of Office System software.

Breadth was an understatement. The sheer volume, or mass, of software being released as one product at one time was overwhelming for customers and the press. It wasn’t just that it was overwhelming in quantity, but the features individually were so deep, so complex, that few could really understand them well-enough to provide detailed reviews. The product guide we distributed to reviewers and the press was 170 pages, a book! The Microsoft Office System Evaluation 2003 Enterprise Edition kit consisted of 11 CDROM discs and two discs filled with various technical and overview documents, demonstration videos, and an entire disc-based website of Macromedia Flash content. It seems easy to make fun of this today, but then one look at the web site for Office 365 and I guess one could long for the finiteness of a bundle of CDROM discs.

Outlook was the hero of the release, with a little bit of OneNote from the press as expected. From junk mail to the new user interface and especially more reliable mail delivery, Outlook finally achieved status as a first tier Office application. It was a story that started in the mid-1990s and took Outlook 97, Outlook 98, Outlook 2000, and Outlook 2002 before we finally got it right in 2003. Through all the strategic twists and turns, organizational changes, and internal competition it had been quite a journey. With 2003, the product finally made it.

A huge amount of software, and Outlook. That is how I remember the release. We so over-achieved on building enterprise software that even marketing, which by and large picked out the end-user features to promote in previous releases, went all in on enterprise to market the release. In the above Evaluation Kit for example in the included “Top 10 Reasons to Upgrade” four of those top reasons had to do with XML, magical XML.

To that end, the release came across as one deeply committed to the new XML technology, our fifth of five priorities when we planned the release. The problem was that we used XML as an implementation detail, not as an end to itself—we had built a platform not a solution, and it was too soon to tout the uses of the platform that had yet to see adoption. The company was overall was so committed, so enamored with XML technology, that it took on a life of its own. It became the destination. The Office marketing team was drafting off the incredible amount of XML evangelism being done by the Server and Tools group, where XML was a key underpinning of the .NET platform. It was still a text file, but we were going to make it seem magical.

If previously Office 2000 focused too much on cost of ownership and deployment to the exclusion of end-user features, then Office 2003 focused too much on a technology enabler or platform technology to the exclusion of doing more with the technology that enterprise customers could use immediately. Looking back at the vision, clearly the big change at the start of the project removed the bulk of the end-user appeal—the vision of Office.NET as an end-user service. The corporate version, “Team and Corporate Productivity” in the vision from May 2001, delivered well but suffered from the complexity and slow deployment of SharePoint as previously discussed.

Large projects are indeed a portfolio and with something as large as the Office System it is essential to build a product such that each constituency has something significant to grab on to, almost selfishly. This is an intentional part of the planning process—we look at the features we are building through the lens of critical stakeholders and make sure everyone has something. I measured our success on delivering on value by constituency.

Enterprises, medium businesses, IT professionals, channel partners, developers, integrators, and more had the full weight of the Office System. It was what they wanted. End-users, typical reviewers, and the individual “power users” (Influential End-Users in our taxonomy) were left behind, though with Outlook and OneNote there was enough, just not an overwhelming amount. The reviews showed that.

Rob Pegoraro a seasoned reviewer for the Washington Post wrote, even with some stinging criticism of some specifics in Outlook, “If e-mail rules your world, Outlook 2003 offers tough competition for pretty much every other program around. . . But the rest of Office 2003 is a yawner. Most people at home can comfortably sleep right through this upgrade cycle.” That’s what most of the reviews were like. Individual reviewers representing typical Office users struggled to make sense of XML, SharePoint, collaboration, and the rest of the massive Office System. The thing is, those individuals just weren’t our business anymore. Enterprise was our business. Those reviews were incredibly strong.

While we were nine months late, we were never out of control or unclear on where we were in the project. We just had a ton of software to get built. Nine months might seem too long, but with the original schedule finishing in late September that really meant a late January launch anyway because launching over holidays isn’t something you can do with enterprise software. So really it was just 6 months, a cup of coffee. The unanticipated long tail at the end of the release gave us more time to plan. My thoughts were wandering to bringing real excitement back to the product while solving the problem of the heft of the Office System.

The launch was a huge worldwide event. I chose to go to China for their launch. Shortly after the launch, I would use a sabbatical to live and work in China for the subsidiary full-time, on the heels of SARS no less. It was an amazing time in China as the markets were opening up, welcoming us, and anxious to expand business connections. The climate of optimism and collaboration was unique.

The launch was difficult, however. For all we had done to execute well, the last-minute change in the product plans away from a consumer service made the release difficult for me. Most people didn’t obsess over or even think about the change, but it lingered for me. Perhaps because I took it as a personal failure in how I managed the planning effort or perhaps, and more likely, I felt it would have been incredibly cool to deliver on the vision of an “online Office”.

I began to think about what would come next for Office and was clear that the product needed an end-user focus. The enterprise momentum had run its course. We were not going to lose for not being enterprise enough. We needed to regain the end-user. I thought to myself about the commitment to do that after Office 2000 and the moderate success we had in development but that did not translate into the way we sold the product. Office 2003 was to remedy that but the start of the project solidified the all enterprise approach. We faced real competition now and the reviews showed we had real problems for the humans that used Office, not just the organizations.

More than anything, the launch was bittersweet not just for me but for many on the team. Just as the product was going to beta test (summer 2002) the team received some devastating news.

Reader note: The following contains an emotional description of the loss of a Microsoft employee.

On Thursday August 22, 2002 (almost exactly one year before we released the product to manufacturing), I received a call on my landline at home from Steve Shaffer (SteveSh), the HR generalist for Office. A call from HR to my home never happened so I knew something was up before I was able to discern the shakiness in his voice.

“I have some terrible news,” he said. “It is Heikki. He’s gone.”

I was not able to process what he was saying and was silent for what I am sure seemed like an eternity. I managed to ask what happened. Details were thin, but there was a fatal car accident in Monroe, Washington, about 20 miles north of the Microsoft campus in a relatively rural area. While trying to pass a car, Heikki’s car collided head-on with a large vehicle. The roads were clear and dry and there were no visibility problems. It took a few weeks, but we learned that there were no drugs or alcohol involved. A young mother of two was also killed in the crash. The children and their father and grandmother survived.

The sudden death of a coworker, a direct report, long-time colleague, and friend was both a personal event and a team event, and a Microsoft event. Heikki was a towering and immense presence on the team, and many people were deeply affected. Microsoft was still a young company and, while we experienced some tragedies, this was the most sudden loss of a senior leader.

Heikki’s family lived in Finland and made their way to the United States as quickly as they could.

We were all in shock. Yet we got through, in part, by thinking about how Heikki would have guided the team. Heikki in his most Finnish stoicism would have insisted we pick ourselves up and stick to the mission at hand. That was Heikki, Olympic-caliber athlete, submariner, sailor, and friend.

We were not ready for the loss. There was little about a technology workplace that prepared anyone for tragedy.

The memorial service was held at the Finnish Lutheran Church in Seattle. With Seattle’s strong ties to the Nordic region, it was fortunate that he had found this community. There was an enlarged photo on display of Heikki enjoying his beloved boat. The church was filled beyond capacity, and we arranged a satellite broadcast for campus and a memorial gathering after the service. Speaking at church, out of admiration for his work family, I shared an expression that meant so much to him and one we often spoke of as a description of the kind of leader he was. “The sign of a great leader is that when the goals are achieved, everyone says things just happened naturally.”

Heikki always said that he took on the mission and “did what needed to get done.”

Back at work, everyone slowly began to move forward. Asking ourselves “What Would Heikki Do?” helped keep status mail going out and project communication across the team.

But there was a void to be filled. Heikki held the most critical communication and coordination role on the entire Office team, and we were at the most critical point for the project to come together. Big teams have succession plans, but they almost always assume some period of adjustment.

No one was expecting to do anything other than finish Office11 on plan. Antoine Leblond (Antoine) agreed to take on program management. In the same announcement, Don Gagne (DonGa), from Outlook and NetDocs, moved to lead Office development. It was what needed to be done and we were so fortunate to have a leadership that could adjust. The team continued the work while mourning the loss of a friend. It was most certainly what Heikki would have wanted.

The RTM milestone, a muted one for many, almost exactly a year later was a reminder of Heikki and all he had contributed in his time with us that was cut so short. Everyone thought of Heikki often, but especially on that RTM day knowing how proud he was of the team every time we shipped.

In remembering Heikki’s spirit as I write this personal journey, I chose to add a page remembering Microsofties that I personally worked with on Tools, with BillG, Office, and Windows who contributed so much and whose memories are indeed blessings.

On to 076. Chasing The Low-End Product [Ch. XI. Betting Big to Fend Off Commoditization]

Each module of Office deserves a shot at being the hero of a release. That’s how a healthy product bundle should move forward, rather than relying on a single anchor. Excel 5.0, Word 97, PowerPoint 2000, Access 2.0 anchored Office Professional. While Outlook was top of mind for IT infrastructure managers, it remained complicated and frustrating for regular end-users. Embarking on a radical redesign of a major product is a career opportunity and also a big bet for a critical business that continued to be half of Microsoft. That would be difficult enough, but nothing is that straightforward. Outlook would still face internal pressures of strategy and alignment that have made building a breakthrough release so difficult previously. Would this be the moment for Outlook to shine?

Back to 073. **DO NOT FORWARD**

Outlook barely worked. Still.

Such was the product-market fit of Outlook that enterprise customers owning the latest in all the Office tools were routinely deploying the newest Outlook while leaving old versions of the core Office apps on the PC.

Five years and three releases from the debut of the product, Outlook remained fragile, bloated, and too difficult to use. It wasn’t as though the team hadn’t executed, releasing Outlook 97, Outlook 98, and Outlook 2000 in the span of just over three years. Rather the team, through little fault of their own at least after Office 97, whipsawed through strategic initiatives. First, they had to split the product into internet and corporate modes. Then they had to merge the product back together while attempting to integrate with Office and the deployment tools of Office 2000. Then they had to charge up the hill of unified storage for the second time, only to cut the feature again at the tail end of the project. As if this wasn’t enough, the past couple of years saw the rise and unveiling of NetDocs which pivoted to a potential Outlook replacement, only to see that vision meet reality.

Marc Andreessen, founder of Netscape, wrote in 2007, years and a generation after the release of Outlook and long after the demise of Netscape, “The Only Thing That Matters”. This short piece codified product-market fit. Essentially, he said that the market pulls a successful product out of the company, “[t]he market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.” Outlook was such a product. Coupled with Exchange the market simply needed the combination to exist and to be provided by Microsoft. No matter what, the market was going to make the offering successful. It simply didn’t matter what Microsoft did or did not do, Exchange and Outlook were going to be successful. Once customers saw enterprise-grade email running on Windows Server with a single integrated mail and calendaring solution, all from Microsoft, everything else was set aside: bugs, bad user-interface, poor performance, and missing features. The combination clobbered IBM Lotus Notes. The rest is history.

We (or I) could not overcome the internal forces driving Outlook’s strategy in order to give the team space to focus on building the product it needed to be. It was weird to achieve so much success with such a challenging product. That really throws one off balance. Product people, so to speak, like to think that being a great product is what matters in the market. This belief drove so much of the dialog internally and across teams it is hard to think of any other factors that were ever discussed—the battles were over what makes for a great product. We battled features, architecture, performance, competition, and more. We never really debated the other aspects of the 4 P’s of the marketing mix beyond product: price, place, and promotion. Outlook was the right price, available through the right channel, meeting an articulated need exactly the right way. Oh, and Outlook email and calendaring kind-of-sort-of worked.

Still as a product development organization and leader, I really wanted to make Outlook work. We really wanted a release of Outlook we could be proud of in a product sense. It was a mission.

Standing in the way, more strategy.

The stars were aligning to allow us to focus—Exchange 2000 shipped and was stable, and Windows simply moved on from Outlook Express to aim for a grander and more unified Longhorn plan, the successor to Windows XP in the early stages as of this time. Yet, we found ourselves in the middle of a Hailstorm.

Hailstorm was the code name for a set of services announced shortly after Forum 2000 that built on the announced .NET strategy. Hailstorm would provide email, messaging, notifications, storage, and more, aiming to be the foundation for a broad set of consumer internet services.

That hardly stopped the corporate strategy motions. No sooner had Office XP shipped than the Hailstorm juggernaut took aim at Outlook. Once again, the classic Microsoft platform play entered the picture—a platform needed apps, and apps needed to demonstrate the value of the platform as the first and best adopters. Plus there was that other part of the strategy play, which was that the platform wasn’t even close to complete. Pushing apps to support a new platform sooner accelerated its completion. Such a dynamic worked once, with Excel for Windows 2.0, but Windows was under development for several years before Excel really began to drive the platform with feedback. Plus, Excel had already made GUI work on Macintosh. This approach did not work with OS/2, though maybe IBM shouldered some of that blame. It could be said that Outlook contributed to Exchange success, but that was not a feeling shared across teams who did not see Exchange success as a client as much as success of a server (I disagree). Hailstorm managed to get a mandate for Outlook support, old-school Windows-Excel style.

Outlook was going to get beaten with the strategy stick once again. There was, however, one problem.

The Hailstorm platform was marginally more than memos and specifications, and few understood how it would diverge from Exchange (or Hotmail)—in other words Hailstorm implied supporting a new mail protocol for a client that only understood Exchange and was still not very good at internet standards. There remained an old-school belief that the world would accept a new proprietary mail protocol for internet scale email. Hailstorm was going to build on Hotmail infrastructure, but somehow introduce a new scale platform. Underlying this was the assumption that Outlook was architected to accept plugins supporting any email protocol so long as some small amount of protocol-specific code was written. This classic Microsoft miscalculation on the utility and viability of such architectures caused many cross-group skirmishes and much finger-pointing.

What many never really understood about Microsoft’s email strategy and execution was that Outlook and Exchange were tightly coupled, just as Lotus Notes and later Gmail were for their respective clients and servers. They are essentially one product built by two teams. Even though Outlook could sort of support other mail servers, such as Yahoo or Hotmail, using those was never as good as when using Exchange—many features in Outlook required Exchange, with users mostly shouldering the burden of figuring out which features worked or not. Importantly, vast numbers of features were not expressed in the industry standard email protocols that existed and exist today. Hailstorm tried to build a mail server without a client. Supporting Hailstorm amounted to rewriting Outlook to support whatever it was that Hailstorm decided to implement as email, calendaring, contacts, and more.

What became clear was that the three-year Enterprise Agreement train that the Office11 schedule demanded would not be enough time for Hailstorm to deliver a working, solid, and scalable platform for Outlook. Hailstorm needed more time. Beyond Outlook even, Hailstorm proved to be too much, too soon for the many partners it needed.

The world of consumer companies was starting to warm up to advertising on the internet and saw the internet and software broadly as an extension of customer awareness and acquisition. The digital transformation that came to characterize most industries a decade or more later was far beyond what most companies were considering. Hailstorm concepts such as digital payments, customer identity, and even customer support happening through an array of software tools seemed wildly out of step, and, more importantly, concerning, as most companies were not looking to trust 2000s era Microsoft with those interactions.

In fact, many companies and organizations were so concerned, the thought of Hailstorm generated complaints to regulators resulting in a series of Congressional hearings. While many theories about regulations gumming up Microsoft existed (I disagree that was the case), in practice Hailstorm was an example of the specter of regulatory oversight slowing down or even outright killing product development. Whether Hailstorm would have been a success or not is easily debated. Certainly, all the capabilities described continue to exist.

The primary failure or resistance, however, came from customers and their concerns about owning data and customer relationships. These same potential industry partners eventually found themselves in the web of Facebook, Amazon, Google, and the likes of PayPal.

It was a grand vision that proved to be exactly right—and about 15 years too early and from exactly the wrong company.

By the time the fate of Hailstorm was sealed, we were only through the early stages of Office11. This gave the Outlook team time to regroup and renew the focus on making Outlook work. The team was already deep into the designs and features but cutting support for Hailstorm was a gift of development schedule hours to the two main innovations in Outlook11: rearchitecting the basics of mail delivery and reshaping the user experience.

Like many technologies in Office, from working on long documents in Word to recalculating large Excel spreadsheets instantly, delivering and storing mail was not the most electrifying feature in the product, but getting it right was something that Microsoft accomplished uniquely well. Before the rise of cloud-based email, mail delivery systems meant downloading email to a PC where it could be read and filed away—mail was stored locally on a PC and everyone was responsible for backing up their own email. It is not difficult to see how problematic that might be. Such effort was required primarily because storing and backing up mail on a corporate server was expensive (very expensive and time consuming) especially for a corporation with tens of thousands of employees. As an indication for how routine it was for IT to offload critical business functions to end-users, few considered the distributed costs and risks associated with every end-user at a big corporation acting like their own IT department. During the early days of corporate email, another limitation was connectivity (Wi-Fi was not yet ubiquitous)—employees were often disconnected from the network, especially information workers with laptops. Routine business travel was a constant hunt for hotels with wired networking in rooms or guest network cables at customer and partner offices. Of course airports and airplanes were disconnected experiences. Customers were offline and disconnected quite frequently.

The previous two Office releases attempted to address offline using the idea of a new storage technology, the Local Store, or LIS. Outlook supported a clunky way of working offline (rooted in old-school dial-up support), which the team improved marginally, but it needed much more work to be broadly usable by road warriors. Working online was how Outlook was built. By online, I mean Outlook worked best when it was connected to an uninterrupted, reliable, high-speed network.

As mobile work increased, working offline became much more the norm. This reality is difficult to imagine today, but two decades ago connectivity was the main topic of conversation almost everywhere there was a laptop. Connectivity, or lack thereof, was a major point of contention at sales Mid-Year Reviews (MYR) where country managers genuinely believed Redmond’s product designers had no idea how poor connectivity was in other markets. They were mostly right, and even when we visited would had no problems paying $35 per day for wired connectivity in a business hotel. It would be ten years before Starbucks would offer free Wi-Fi.

Offline was the key to making Outlook vastly more reliable and responsive. Everything that a user experienced in Outlook would operate on data that was already downloaded from a server, which was not how it previously worked. If there was no network connection Outlook was still snappy and responsive and every feature just worked. When a network became available, Outlook seamlessly and silently connected, receiving any new mail, sending all the mail that was drafted while disconnected, and filing away emails in the right folders. A key detail was that an individual’s PC was no longer the only storage for email but was a copy of all the email stored on the server. If a laptop was lost or a person wanted to use two computers, mail remained up-to-date and exactly the same. Outlook was a cache or copy of Exchange, which is why we called this cached mode. Through today’s perspective, this is exactly how the Mail application on an iPhone works when connected to Gmail.

In Outlook 97 through 2002, online mode, when it worked (which was not always), worked incredibly fast, and instantaneously. When the server received new mail, Outlook instantly showed the new mail on a PC. That mail was fetched from the server then displayed, which, if the network was perfect, was snappy. Even a small network hiccup (as the CEO of Boeing experienced on a business jet) and Outlook would hang, and almost never recover gracefully. Email was novel and speed of delivery was a feature, so even then customers remembered how fast it all seemed during demonstrations. The important detail was that the mail still existed in storage only on the mail server. The PC was a rendering of the server. That’s why mail delivery seemed so fast—the mail itself did not travel over the internet, just the visible portion of the screen.

With cached mode, Outlook11 changed how email felt. Suddenly, when new mail arrived on the server, the PC silently fetched it, waiting for a good network connection. It was fast, and not always instant, but predictably mail arrived when it could. When it did, the entire mail message, including attachments, was there. Mail with larger attachments took longer to appear. To big customers impressed by the speed of previous Outlook, Outlook11 felt slow and sluggish. With the rise of Wi-Fi on laptops, Outlook could sense when connectivity was available and, without crashing or hanging, continue to work seamlessly.

We were caught in the middle of crazy conversations with customers who could not get past it feeling slower, even though it was not, and it was more reliable. BillG even complained to me several times about how slow Outlook seemed, wondering if we would fix it as product development progressed. Again, we faced how changing small factors in a running system led customers to believe the changes were bigger and worse. Word introduced background printing and saving, and sure enough the absence of a progress indicator scrolling across the screen led people to believe Word slowed down as well. Cached mode, background save and print, and many more changes that improved Office in an absolute sense convinced customers it was slower, more difficult to use, or different and thus worse. At least that was the case initially.

When I was working on the first release of Visual C++, we were deeply concerned about performance when creating Windows programs, new for most developers, especially compared to the speedy Borland Turbo C++. I added a feature to rapidly display a count of lines of code as they were processed or compiled. Much to my chagrin, my code to draw that ticker technically slowed down the process. In usability tests, however, developers always thought being able to see the line count whiz by was perceived as faster. So, we left the line count in, even though overall processing time was slower.

Perception matters. The performance of an interface can depend on perception of the design as much as stopwatch time, though it isn’t always obvious which matters more.

Outlook 2003 was so critical to Enterprise customers and so complex to make work reliably and correctly, that along with volumes of detailed documentation for system administrators we released a 27 page “Outlook 2003 Performance Guide” detailing all the improvements and capabilities for performance, security, reliability.

Office was no longer in the realm of tech enthusiasts anxious for every change. It became business infrastructure and like the floorplan of a factory or cost centers in accounting changing infrastructure was not done on a whim.

The middle-age of the PC was a period during which each change, obvious or not, was viewed with skepticism. It used to be that Office was difficult to upgrade because of the cost of upgrading disk space and memory, but such expense was viewed with a bit of excitement or even pride of accomplishment. Then upgrading Office became difficult because customers did not want it to change at all. Change was different and different was assumed to be bad, especially for Office, which was not the cool place IT was willing to invest time and effort. The complexities embraced on the server and in the datacenter were driving a movement to maintain status quo on the desktop. Change was actively discouraged when it came to the desktop and Office.

Still the user experience of Outlook remained horrible. It was Byzantine and bloated and had the reviews to prove it. Even today, searching for “Byzantine Microsoft Outlook” yields almost one million hits. Outlook11 aimed to recraft Outlook based on what we had learned over four releases and four years since Outlook 97. We were going to take the time to make it right so it could properly share the stage with Word, Excel, and PowerPoint. Each app in Office deserved to have a release where it stood out and was recognized for being great.

Jensen Harris (JensenH) was asked to lead program management for the first broad, and much-needed, reshaping of the Outlook user experience. Hardly the typical computer science hire, Jensen joined Outlook from college where he majored in music. Previously, Jensen attended Interlochen, the prestigious performing arts school, with fellow classmate Jewel. When not composing for all the instruments in a piece or performing, Jensen was programming. Jensen was among the best of a new generation of program managers on the team and he seemed to know as much about how Outlook was coded as even the most senior developers. These skills were put to the test in sweeping changes to Outlook11—a process that, if successful, could prepare Jensen and the Office team for even bigger changes in the future.

While we made many small or incremental changes in user-interface in each release of Office, Outlook11 would be the biggest changes to any one product to date. We would also make these changes in the context of the change-resistant enterprise customer base, especially the email administrators in IT that saw Outlook as a necessary evil supporting their beloved Exchange servers.

To say the changes were sweeping and high-risk only makes sense in the context of the time. First, many small features of Outlook that piled on over the previous years were rationalized, sanitized, streamlined, and in general made better and more accessible. Second, and more importantly, they came at a time when email was the most critical and mainstream tool being added to the workplace. Using email and Outlook often meant taking a training course, buying a book, or simply struggling to master a few scenarios and little else. Email was still in an expansion stage, leaving ample opportunity to make it better for new users not just change the user experience for existing users.

That context is important because so many of the paradigms we think of in email today were pioneered or refined in Outlook11: message flags, preview pane, switching between calendars, contacts, mail, message thread view, junk mail filtering, integration with instant messaging, and much more.

The most acute pain point in using email, any email not just Outlook, was unsolicited mail, junk mail, or SPAM. The rapid rise of email brought with it an exponential rise in the morning ritual of deleting unwanted mail offering everything from get rich quick schemes to fast college degrees, and even offensive sexually oriented offers. Everyone felt invaded by the onslaught. Unfortunately for Microsoft, the rise of Hotmail with hundreds of millions of accounts was both a source of junk mail and the target of junk mail senders. The junk mail problem on Hotmail was so bad that @hotmail.com addresses became synonymous with spam. It wasn’t just an inconvenience, but email was losing its utility for businesses to communicate with customers as primitive junk mail technology too aggressively filtered out legitimate mail.

In one of BillG’s most successful (and perhaps last) great cross-company technology initiatives, a working group from Microsoft Research, Exchange Server, and Outlook convened over many months with Bill insisting we collectively make improvements in junk mail filtering.

The work from Microsoft Research was one of the early applications of the same technology used in the Office Assistant, Bayesian probability, advancing beyond typical keyword filtering that falsely flagged messages. Junk mail senders adopted their language rapidly to get around filters, substituting alternate spellings for words such as S3X instead of SEX or S1NGLE instead of SINGLE. Exchange server pioneered some of the first cross-industry efforts at verifying legitimate senders. Outlook took advantage of MSR technology used in Hotmail to apply it to the desktop application so it could work for any email service customers used. The Outlook features were so well received that almost every review mentioned them, though they also mentioned Hotmail as the biggest junk mail headache.

So successful was the feature in the previously released Outlook Express that I found myself along with several lawyers in a San Jose courtroom defending the right of Outlook to even have junk mail filtering. A popular electronic greeting card company (yes, web sites that created a JPEG birthday card were a big thing for a short time) sued Microsoft for falsely flagging some of their free greeting cards as junk mail. I spent several weeks creating new mail accounts and collecting the junk mail that would routinely arrive even before using the account for legitimate email to show the judge as we entered arbitration. The lawyers made a great case for the right to protect consumers, but in the post-DOJ era the David v. Goliath environment was too difficult. We settled the case for an astonishing amount of money. The good news is that over time it paved the way for the industry to legitimately offer junk mail protection, if for no other reason than everyone with email recognized the junk mail problem.

In applications, the way to signify a major update is to change the user interface substantially. Doing so signals to the world how big the change is. BradWe, our product design leader, referred to this as the ten-foot test. Looking across at a PC screen ten feet away, could a typical customer see the difference in the product. This is surprisingly difficult as most people see typical screens as an array of meaningless graphics. On the other hand, when it comes to using a product up close even the smallest changes elicit massive feedback. The rise of Outlook in a few short years created a good deal of muscle memory, even though the product was awkward and complex. Most customers were not just learning Outlook but learning email, to many Outlook was email. Changing Outlook was changing email, and email had rapidly risen to be a core part of work. No one likes their daily workflow changed for no good reason. These conflicting goals set the bar high for JensenH and team to deliver on a vastly improved, and iconic user experience for Outlook.

The team answered this challenge with an entirely new layout for the main Outlook window, one that would pass the ten-foot test. The screen was divided vertically into three columns: folders, mail messages, and a single message open to read. It was a clean and logical design that was . . . broadly panned during beta testing. The visceral reaction to seeing a narrow column of the inbox subject lines and that the view was showing each message with two rows led beta testers to think less email was shown on the screen, and less email meant less productivity. Similarly, the relatively narrow reading view of the message led to a conclusion that less text of a message was shown on the screen. These observations were hotly debated on the newsgroups and the subject of many outcries from testers.

Yet, these observations were not true, and easily demonstrated. Jensen and team were hyper-analytical in the design and measured everything about the interface—in particular, the design showed a much higher level of information density on the screen, while apparently making people feel like less was on the screen, which would make it easier to read and less tiring. Brilliant. Over a few weeks the outcries were settled with volumes of screenshots and posts to the newsgroups, leaving a design in place that is routinely used by all email clients today. This was another example of visceral perception of user experience versus actual experience.

Outlook users tended to be either pilers or filers when it came to managing email. Pilers, like the BillG I knew, let their inbox grow, seemingly without bound. Inbox was where mail was read and also stored. When a piler wanted to find a message, they used Outlook search, which was slow and deeply unsatisfying, or more likely they sorted thousands of messages by sender or date or subject, which was fast. Filers created elaborate hierarchies of storage folders and messages. Advanced filers created email rules, moving messages to folders even before they read them. One reporter I knew maintained a folder for every company, and a folder within that for each contact at that company. He worked with all the folders visible and the whole hierarchy expanded, watching for unread messages.

There’s a challenge when customer knowledge of the past makes improving for the new, faster-growing base of customers super difficult. The customers we heard from in early testing were those with knowledge and time to engage. They raised issues and engaged in debates that others happily let product design work out for them.

We came to learn that many of the tech elites were avid filers, making use of email rules. When a customer goes through the effort to create a rule, mail messages are automatically placed in a desired folder as they arrive in the inbox based on criteria such as the sender’s name or company name, or perhaps keywords in the subject line. The general concept of advanced tech thinkers embracing hierarchy was consistent with how people made use of folders of files on their PC. Typical users often had desktops filled with files including what they were actively working on, whereas techie users tended to have elaborate folder hierarchies and store documents in the right place from the start.

Studying how customers used Outlook, rather than listening to how they thought they used Outlook, revealed a spectrum for how the onslaught of email was being handled. Customers tended to self-report how they wished to be perceived rather than how they used a product, something we learned over the years with the instrumented versions. As an example, customers routinely self-reported sending far more mail than they actually sent or would rarely get the number of messages in the inbox approximately correct. BillG, the piler, used to wax poetically about his love of filers as though he was one primarily due to his fondness for hierarchical lists, but also to make a point about the future of storage that would support hierarchy. He also exaggerated the amount of mail he sent and received.

Business books are filled with stories and strategies about learning from customers, getting feedback, and doing what customers want. In technology products, and in Office in particular, in the more than a decade I worked on the product, much of that feedback would have frozen our product where it was and prevented us from moving forward. Staying true to learning the reality of what customers experience was such a key lesson reinforced with Outlook11. The lesson was one for the ages and one that impacts every technology product, including, as I would learn, Windows.

Showing Outlook11 to the press and reviewers was not just a demo, but a story. We incorporated the data about how customers used the product in reality and showed the analytics behind the product. It sounds obvious, but it just wasn’t something done in the industry because prior to the internet no one really knew. We had surveys and focus groups, and the early data about quality, but with Outlook and Exchange we had real data about real people doing real work. This story-telling approach dramatically changed not only how we designed and communicated product changes, but our willingness to take risk to make bigger changes that met customer needs.

Outlook 2003 had its own “Reviewer’s Guide” that was provided to the press and Enterprise customers. It was 35 pages!

As the success of Office continued, we were fast approaching the point where most everyone that wanted Office owned it, legally or pirated. PC sales in 2002 (post dot-com bubble) were nearly 130 million units, growing at an anemic rate of 3 percent or less. There was a fear that we had peaked and that conservatism in making changes should have ruled how we thought of the product. Some thought we should have been focused on listening to customers and not rocking the boat.

Except we were listening to customers.

There’s a famous saying falsely attributed to Henry Ford suggesting that when potential customers of the Model T car were asked what they wanted, they said a faster horse, not a car. No customers wanted a graphical interface with a mouse, or an integrated suite of productivity tools, or even for those tools to evolve with the changing nature of information and the internet.

Finding a balance between listening to customers, while also moving forward with technology, is the most difficult challenge any successful technology company faces. Microsoft was no exception.

On to 075. Scaling and Transitions

As readers of this chapter have seen, the theme of Office11 continues to be enterprise, though now it is turned up to 11 so to speak. Despite my concerns about end-users and reviewers, the unstoppable force at Microsoft remained enterprise customers and meeting their needs or the needs of our growing sales force serving them—whether those needs were technology, positioning, or strategy, as expressed by customers or the field sales teams. A key attribute of enterprise software strategy is connecting the dots and making sure one part of the full enterprise stack uses (or leverages) another part. A cynical view of this is that it encourages a form of lock-in relative to the Microsoft stack of software. A practical view is that customers appreciate this interconnectedness because they are buying everything in a bundle and broader usage of what is already owned offers a high return on that investment. A charitable view of such a strategy is how it makes for more elegant implementations where the various parts simply work together. Perhaps the story of Windows Rights Management (also called Information Rights Management within Office) generated a seemingly unachievable level of complexity while simultaneously facing an unrelenting technical buzzsaw of customer feedback.

This lesson from this section is not a one-off. Instead it is prototypical of the era but also what happens when a product pivots to enterprise customers and the enterprise relationship dynamic defines how products are built. It is a tale of caution.

Back to 072. Notes on Tablet PC Innovation

“I’d like to present to the witness Exhibit 6508, Bates number 0017811. Mr. Sinofsky, do you recognize this email that lists you as the sender?”

To anyone involved in modern litigation, especially being deposed, there’s a sinking feeling that comes with being presented an old email. A similar feeling arises when receiving a call from a reporter starting with, “I was just anonymously forwarded an email about . . .”

Email became ubiquitous across the corporate world by the early 2000s. With the rise of companies moving ever faster came “business at the speed of thought” (that was the name of Bill Gates’s second book from 1999) or “flattening organizational hierarchy,” to name two of the many touted benefits of email. In the early days, while senior managers at non-tech companies were still having email printed out for them and assistants transcribing email replies, not much thought was given to the permanence of email or the instant impact of an employee innocently (or not) forwarding email outside the company.

Every company that deployed email and embraced an email culture eventually wound up with a company policy on the use of email, likely explaining the ramifications if one were to be less than scrupulous in his or her use of email.

Born out of this were automatic disclaimers placed at the bottom of email, “THIS INFORMATION IS CONFIDENTIAL,” or my favorite, simply writing in red letters across the top of a message (perhaps the first use of rich email formatting) “CONFIDENTIAL.” We should not forget putting “**DO NOT FORWARD**” before the subject line of the email. We all knew that those emails were the important ones, and these warnings weren’t even worth the bytes they took up—copy/paste and printers still worked. Just in case there was a button on every keyboard since the first PC “Print Screen”.

Outlook featured commands that implied “Confidential” and “Do Not Forward,” though these did little more than offer a fancy version of red text and, worse, were invisible to recipients reading the mail on systems other than Outlook.

Maintaining the corporate confidentiality of email became the Achilles heel of the platform, except that email found such incredible product-market fit that there was no putting the toothpaste back in the tube. Customers wanted a solution that protected email misuse, or more clearly made Outlook enforce a company email policy or intent of the sender.

Over the previous several releases of Office, we steadily improved the ability to encrypt Office documents. Office always had the ability to add a password to documents, and for years a top call to customers calling PSS was trying to retrieve a lost password (Microsoft provided no help, but a search on the internet quickly led to a variety of tools that worked with trivial effort up until about Office 97, and incidentally those search results were a common way to spread malware). We eventually added true encryption that made it increasingly difficult to read a document that was not yours to read. This level of security eventually became minimal as the ability to break encryption techniques had steadily improved.

A peak effort and an early test of our platform capabilities for encryption was working to win approval for Outlook and Exchange to be used in the Defense Messaging System in the Department of Defense in the United States. Implementing the required encryption was useful only to the Defense Department but we eventually added it anyway. That was not before the head of North American sales, Orlando Ayala (OrlandoA) made his case to me by standing on top of a table in the briefing center begging for an update to support the DoD. I was terrified. The customers were impressed. We did the work.

The core of implementing encryption was an ongoing collaboration between Windows and Office, as well as Microsoft Research. Encryption was not exactly one single thing or feature, but a complex platform that required servers, user identity, and a lot of sophisticated math. It was exactly the kind of infrastructure that enterprise IT was gobbling up in the early 2000s. The old days of encryption were rapidly being supplanted by the need to encrypt information that flowed across the public internet and used public internet infrastructure. It was no longer as simple as a closed network with known proprietary endpoints.

Protecting files (and messages) with encryption was not without controversy, and without exaggeration for some technologists it was a line in the sand—crossing it put one squarely in the camp of the man. Encryption often collided head-on with the libertarian roots of the software field. Encryption was something of a third rail in the counter-culture elements of software.

The rise of the internet for online commerce created a brief moment where software vendors got caught up in the intricacies of import/export laws related to military products, specifically munitions. For a few years, the basic encryption algorithms—the results of widely-published academic research—were classified as munitions by US law and thus restricted for export. The hardcore technology advocates created a t-shirt featuring the code that implemented encryption with the implied threat that wearing such a shirt through a border crossing might subject the individual to law enforcement action of the highest order. The result was a headache for software vendors who maintained a secure version of products for the US market and a markedly less secure version for “export”. President Clinton signed an executive order ending this awkward situation and at least one type of encryption flourished.

Broader awareness of encryption came about because of the iPod, surprisingly, because of how Apple chose to protect digital music downloads from being copied or pirated. The music industry embraced digital rights as a way of protecting the world from another Napster, the online music service that institutionalized either digital distribution of music or mass-scale theft of music depending on which side one was on. Essentially, using digital rights management (DRM), Apple’s iTunes service ensured that the person who purchased a song was the only person who could listen to it and could only do so on devices authorized by Apple’s iTunes.

Such usage restrictions had shades of authoritarianism harkening back to the early days of commercial software. In the first years of MS-DOS, software vendors routinely encrypted software in such a way that only the licensed user could install it on a PC using serial numbers that would unlock the floppy disk and permanently assign it to a given user. Vendors also made it difficult to impossible to make copies of the software disks forcing buyers to be extra careful with their $500 purchases. So annoying was this to even legitimate buyers, that I spent several weeks one summer internship writing a low-level assembly language program to make copies of Lotus 1-2-3 disks for a huge defense contractor. Historically, Bill Gates was at least on the side of the honor system by and large though he believed strongly in active enforcement of legal ownership of software.

The industry collectively backed off from rights enforcement during the high-growth years, particularly at the urging of upstarts such as Borland, who used the absence of anti-piracy measures as a selling point. Then, as piracy of Office and Windows increased, so too did the use of serial numbers and activation codes, which were then labeled DRM by some, as if to further inflame consumers seeking legitimate use of their license. Thus, any feature using any software use restrictions was going to enter the maelstrom of tech enthusiast ire. BillG was particularly unphased by the pushback, widespread negative news coverage, and relentless hostility online in just about every language of the world taking place just after resolution of the antitrust saga.

For many in the tech community DRM in music was the devil’s technology. DRM prevented “fair use” of music and video all in the name of profit. The music and visual arts communities did not see it that way. Anything that looked like any combination of encryption or restricted use of digital information was labeled DRM. Anything called DRM came under intense scrutiny with the potential to backfire as features capitulating to authoritarian forces.

Nevertheless, enterprise customers were quite enthusiastic about a “Do Not Forward” button that worked. As one can imagine, in Microsoft’s top-down selling motion, it was the C-suite executives most interested in protecting the rights of their own email and documents. Even though we knew the idea of protecting email from being forwarded had all the makings of being labeled DRM and building the feature would utilize previously militarized technology, the allure of solving such a clearly articulated need was enough to overcome such resistance.

During the early days of building out the Microsoft enterprise infrastructure stack, customers were perhaps unknowingly open to enormous amounts of complexity to implement new features. Our sales force actively embraced complexity if it meant opportunities to link products together in a cross-selling motion, especially across Windows Server and Office. Office11 Information Rights Management (IRM) did not disappoint. We called it IRM as if to distinguish it from DRM, kind of. We knew we were walking straight into a messy feature. In an early nod to the complexity of the feature, the Windows infrastructure used by IRM was called the Windows Rights Management Service (RMS), thus implementing our DRM-like features called IRM used RMS (phew!).

Customers were already annoyed that they could lose a password to a document and Microsoft could not, or perhaps they thought would not, help them. IRM, in the eyes of detractors, implied that Microsoft held the keys, literally, to documents and somehow positioned themselves to become gatekeepers of email and documents. Or perhaps, as some customers thought, Microsoft did not hold the keys to documents and email and somehow a company’s own information would be subject to some sort of super-password that even they might not be able to unlock. What if there was a bug rendering the company information inaccessible? The questions were endless.

There was something inherently untrustworthy about the potential of using a content protection feature that could render the content unreadable. This was not theoretical. Many were already experiencing owning a library of rights-managed music, only to find it inaccessible when a company went out of business. Stories of lost music players and accounts disconnected from the rights were endlessly populating support sites. Whether these cases were real or not, they all contributed to a distrust of rights management. At this point in the company’s history, Microsoft was not always viewed with the most latitude in terms of doing the right thing for customers.

IRM proved to be one of the most complex features we ever shipped, perhaps overly complex, but in many ways it was symbolic of the overall complexity we were delivering to customers, whether it was IRM, SharePoint, or even the base infrastructure of Windows Server.

During vision planning for the release the feature was proposed so an Office shared team was created to tackle the implementation of IRM for Office11—the team aimed to implement the feature across the suite of products, not simply a one-off for just email. They had a bold vision for a future where companies could have much more control over their corporate information.

Lauren Antonoff (LaurenA) led program management, and with her prior experience on the Windows platform side she was great at navigating the extensive collaborations across the company to make this feature possible. Mark Walker (MarkWal), a veteran of several releases of Word as well as SharePoint and one of the most consistently smart and broad-thinking engineering managers, led development. Brian Wiese (BWiese) led testing, perhaps the most complex interoperability test responsibility we had created to date.

From the start, even when sketching out the original feature, IRM was a big feature. All we were aiming for was that “Do Not Forward” button, but to the surprise of many we overachieved.

IRM had to handle a plethora of edge cases, as testers called them. What if the users lost their PC? What if they wanted to read a message or documents on a rental PC in a hotel? What if they wanted to use IRM with a trusted partner who was on a different email system? What about access on a BlackBerry? What about wanting to open a file on an old version of Office? What if in the future someone needed to open a file on some not-yet-existing Office15? Then lawyers started asking if documents were part of legal discovery orders? How would screen readers used by the blind work? Or what if an employee was terminated? These what ifs went on and on. Every time I stopped by LaurenA’s office I learned about another case they were working on.

The strategic changes at the start of Office.NET seemed to be the kind that might reduce the complexity of this feature, because we no longer needed to worry about a parallel implementation of enterprise and outside the firewall, as we generally called it. The feature, however, needed to work outside the firewall if, for example, executives were to be able to read protected information on the road. The team took on the mission. We ended up doing much of the same work as we did for a hosted service but in bits and pieces, enabling IRM to work for customers using Hotmail in a browser, as long as the customer used the latest version of Internet Explorer.

As each development milestone progressed, M1, M2, M3 . . . the complexity continued to rise. IRM added code to Office, SharePoint, and Internet Explorer and required additions to Windows Server and to Active Directory. Administrators needed to learn to manage and distribute encryption keys, something that was making its way into enterprise infrastructure.

Along the way we experienced surprises that questioned the notion of Microsoft implementing IRM at all. Historically, many third parties—companies building products that relied on Office files or email—relied on being able to change documents or read them without launching the app by directly modifying files. Screen readers for the blind were one such example. Many document management systems relied on reading the contents of Word documents. Financial systems routinely read the contents of spreadsheets pulling out specific cells or data. Such behavior should have been impossible because the files were encrypted. Ultimately, the team designed capabilities to enable these “hooks” but at the expense of even more complexity. The depth of the feature was astounding.

The operational flowcharts created by the IRM team were legendary. The team rose to the occasion, producing untold volumes of written materials for corporate admins, partnering with all the teams at Microsoft, and coordinating the documentation across the writing teams that made this feature possible. Setting up IRM remained a monumental task.

IRM’s pièce de résistance was the addition of administrator-created rights management policy templates. It wasn’t enough that a message could be marked “Do Not Forward” or a document could only be opened by a fixed set of people. Office11 enabled IT to create new document policies that expired (like Snapchat, but 15 years earlier), or for documents to be forwardable but only within a company. Several combinations of permissions could be set via policy.

The keepers of secrets in enterprises, especially those sending mail on behalf of big bosses, were super happy. IRM was an enormous hit in the Executive Briefing Center. Emails on corporate reorgs or M&A PowerPoint decks could finally be shared worry-free.

Then came the debate to end all debates. In an early customer briefing about Office11 the details of IRM were discussed. With all the work going on to secure Windows XP SP2, marketing and the field thought it prudent to refer to IRM as a security feature. The problem is security features imply a promise of robustness in an absolute sense. Either a document or email message was secure, that is it could not be read or forwarded, or it was not. We had those nasty details to contend with such as the Print Screen key (or the more cryptic Prt Scr key on laptops). What if someone was reading a document and took a screen shot? That was a “security bug” according to the customer. The field sales reps were frustrated. The documents and emails were more secure because they were encrypted, but they were not absolutely secure from all forms of attack. Nothing is. After a scramble, work was done to disable screen capture involving the Windows team and marketing repositioned the feature away from security, we thought we were set. At least we thought so.

Once Office11 was available to Microsoft globally in pre-release, IRM quickly became an oft-used feature. Routinely the most interesting mails were rights protected. Re-org announcements, strategy changes, schedule shifts, anything to do with sales numbers, staffing adjustments, and more were reflexively rights protected. Employees started rights protecting snarky threads commenting on other rights protected threads. Along the way, many learned an inescapable workaround for capturing the text of a protected message. Using another new Windows feature that allowed one to remotely log on to another PC, all one needed was a second PC to remote into your primary PC. After connecting, just read the message normally on the remote PC while capturing the screen on the second PC where the session was started. This was not something we could address. Most people didn’t have a second PC so we felt reasonable about this and if administrators wanted, they could disable this capability, primarily used for servers anyway.

The feature, however, came just as mobile phones were gaining cameras and suddenly photos of screens were passed around with the latest news about a reorg or product schedule slip. Mobile phones would prove to be a huge challenge, especially non-Microsoft phones. Microsoft implemented support for protected content on Windows Mobile in a reasonably timely manner and released it to an anxious Microsoft workforce. Those of us still on Blackberry or Treo devices, however, would have no idea what juicy secrets were sitting in a protected message we received while at the movies or out to dinner. We’d rush home to check out the message on a full PC as soon as we could. The proliferation of mobile devices only amplified the complexity of rolling out IRM to an organization. Almost fifteen years later, I joked with the founder of Accompli, a company that Microsoft acquired in 2014 and rebranded as the mobile Outlook client for iOS and Android, that among his first Microsoft duties would be to add IRM support to his product. A request that quickly materialized.

IRM could in no way protect anyone from discovery and litigation. Administrators had all the requisite tools to comply with courts. It was the start of a new era of information control. The era at least in Microsoft, of mail that frustratingly could not be forwarded. A feature of IRM was not just that the mail could not be forwarded but even the attached documents in mail received the same protections as the mail message. Documents could be saved in SharePoint where entire document libraries could be protected against unauthorized sharing. In fact, long memos could be protected so they could not even be printed. Those email attachments had to be Office documents, however, as people quickly learned. Photos or PDF files that were attached to protected messages did not receive those same restrictions.

Office IRM gained many fans inside Microsoft especially with the sales team who simply loved the way it connected all the major company initiatives of Office, Windows, SharePoint, and Windows Server.

Customer usage, however, was far lower than we hoped. This was perhaps in part because most end-users didn’t want to invest the time and effort into dealing with the restrictions and no doubt IT departments could not absorb the complexity to deploy and manage the feature. It was likely that the only team that was able to run much of Microsoft’s mid-2000s era infrastructure correctly, securely, and reliably existed in the 425 area code and carried blue Microsoft badges. Setting up, deploying, and training end-users was beyond the reach of most customers who were struggling to keep PCs functioning and patched with all the latest updates.

Setting up and deploying IRM in a company was an enormous undertaking. Once Microsoft successfully deployed IRM, a Showcase IT whitepaper detailing how MSIT implemented the feature stretched over 40 pages. For an average company to deploy the feature, they would need to invest in hardware and skills training across the Microsoft product line. On top of the typical deployment for desktops with Office and Exchange email, a company needed the Windows RMS server (or several), a Windows Server running Microsoft SQL Server, an SSL Certificate server (the encryption infrastructure), as well as to configure numerous externally facing web addresses for access outside the company network. While these products could be covered by an extensive Enterprise Agreement, typically adding these components was an upsell.

We were creating features that were, for all practical purposes, impossible to consume. More than anything, this defined the era we were enabling. The problem was not that we created these features, but that customers and the sales force were embracing them—not so much deploying the features but embracing the underlying strategy of the features. Complexity was empowerment for the enterprise IT leaders, so it seemed. While there was continued backlash about bloat on the desktop and bloat within Office, the newness of servers and server infrastructure made features that relied on servers seem cool, and they were given a free pass regardless of complexity. The routineness with which IT succumbed to “standing up another server” was incredible. The enterprise account managers did not hesitate to push features that required more infrastructure—doing so was showing more value to customers and good for Microsoft’s bottom line.

IRM was an incredible collaboration across the company. Development teams including Office, Windows, Server, Research, and more contributed to building the feature, while sales, support, and Consulting contributed to selling and working to deploy the feature. It was an amazing sense of pride of execution capability, that I wish was met with as much enthusiasm to deploy and use the feature as routinely as we would have hoped. Today’s Microsoft 365 and Azure made the feature somewhat more accessible and perhaps more usable, though the decisions of an architecture from decades ago still linger in an underlying complexity that was probably good at the time in theory but not good relative to first principles.

Somehow, we had gone from simplicity as the guiding light to complexity as a sought-after competitive advantage. The story of IRM is both one of successful implementation and a cautionary tale of too much focus on customers to the exclusion of what is usable and desirable.

The world turned upside down, or sideways, or something.

On to 074. Outlook Pride, Finally

Few products have captured as much attention as Microsoft’s Tablet PC (except perhaps Xbox, which coincidently launched the same year). The company’s history working to deliver the form factor goes back to the earliest days of Windows. BillG’s intense focus on handwriting recognition led to one of the first extensions to Windows, Windows for Pen Computing (1992), and a bitter lawsuit with then perceived leader, GO Corp. Subsequently, handwriting recognition was among the very first groups chartered in the new Microsoft Research organization. The small Windows-derived handheld devices, PocketPC, were pen-centric. Then finally in the early 2000s Microsoft began in earnest (meaning in Windows proper) the technology for pen and handwriting that made it into a special edition of Windows XP for Tablet PC and a new type of computer. This arc took place a decade before the iPad was released (purists do love to point out the Newton from Apple came and went in the 1990s). Famously, Steve Jobs tells the story of the iPhone as one that began with a tablet form factor, but that was abandoned in favor of the phone. With such a long story, one could easily write a book on just the evolution of the tablet and the Wikipedia history page represents the industry search for a paradigm-defining product. In this section, we’ll start with the launch of the modern Tablet PC from Microsoft and detail the much more difficult (in my view) challenges of building software for the form factor in the context of Windows.

Back to 071. Resolving NetDocs v. Office

I should have been prepared for what transpired following the unveiling of our Tablet PC. I was not.

The line to enter Bill Gates’s keynote at the November 2001 COMDEX snaked through the hotel and required metal detectors and body searches following the events of September 11, 2001. Themed Digital Decade 2001-2010, it was set to be a highlight of the week—discussing bringing digital innovations across industries and emphasizing increases in productivity, richness of business infrastructure, and significant changes in home entertainment.

Previously at Fall COMDEX 2000, Microsoft unveiled the Tablet PC, showing a prototype tablet created by Microsoft, highlighting BillG’s personal favorites of pen-based handwriting capabilities and online document reading. At the time printing was still the standard for sharing business information. The prototype was how we hoped to convince OEMs to build similar PCs.

A recurring theme for the Windows business was to use big tradeshows to demonstrate exciting new PCs across the PC ecosystem. JeffR joined BillG on stage to show off multiple innovative PCs running the new Windows XP Tablet OS, many of which were to be available later in 2002 with the tablet-capable version of Windows XP. As with all things Windows, the strength in bringing the product to market was emphasized by a broad array of hardware of different sizes, shapes, and price points. Building off the first party prototype demonstrated the previous year, the keynote brought the full strength of the PC ecosystem to this new form factor with support in new variant of Windows XP.

Alan Kay, a pioneer in visualizing and prototyping the concept of a tablet while at Xerox PARC, conceived of the DynaBook, perhaps the original tablet. The DynaBook was envisioned as a “personal and portable information manipulator" described in his amazing paper, A Personal Computer for Children of All Ages (1972). Of the launch of Microsoft’s Tablet PC in 2001, he told Newsweek’s Steven Levy, "Microsoft's Tablet PC [is] the first Dynabook-like computer good enough to criticize." In PARC-speak, that was a high form of praise, not a back-handed compliment.

The quest for a PC tablet was not new and perhaps dates back in our memories to Captain Kirk on the bridge of the starship Enterprise with his tablet and pen. In the 1980s and 90s the PC industry was buzzing with innovative large screen computers based on tablets and pens from the likes of IBM, GRiD, Momenta, NCR, Compaq, and Asian companies like NEC, Samsung, and Toshiba. Small screen computers arrived (and departed) as well. Palm had a breakthrough with its Pilot, while Apple failed with its Newton. Windows CE devices were blessed with a stylus as well.

What Microsoft envisioned to do differently was to build a new class of computer. The Tablet PC would be a full notebook sized computer, but better. It was a notebook PC in power with the convenience of an actual notebook and pen. It was also fully capable of running the latest Windows and Windows software. This was not only the core of the Tablet PC strategy but the core of everything Microsoft was doing with the “scalable Windows architecture”, or “one Windows, with many implementations”.

Microsoft’s new Tablet PC group, led by Alex Loeb (AlexLoeb), reported to JeffR’s division (rather than Windows) to streamline delivery of a killer productivity solution. As the original manager of the pen computing effort a decade or more earlier, JeffR had a longtime passion for pen input (Some personal trivia is that my first trade show booth duty was showing off C++ support for Windows 3.1 for Pen Computing 1.0 at Spring COMDEX 1992). Jeff was an early fan of PocketPC devices, never missing a chance to use the stylus to jot down notes or show off the latest financials in Pocket Excel.

While the connection to information work was clear, this organization structure was a tacit admission that the Tablet PC might require more end-to-end design and implementation than a typical new Windows PC. To build a complete experience required integrating product design and engineering efforts across Windows, Office, research groups where the ink and handwriting technology was being developed, as well as hardware engineering for digitizers and working with PC makers. Coordinating marketing and partnering with OEMs introduced another aspect of the end-to-end effort.

Technology for digital ink progressed significantly, primarily as a result of the increasing focus on screens and digitizers—the technology that picks up a signal of some form from a pen and converts it to a series of datapoints representing what is drawn on the screen. Flat panel displays for notebooks were progressing quickly. The Tablet PC was timed well to capitalize on these innovations as display and touch/ink sensor-equipped panels proved to be the limiting factor for building even a marginally acceptable experience.

From its earliest days, Microsoft Research was working hard to make handwriting recognition a reality. Handwriting recognition had long been one of the fundamental linguistic technologies (along with language translation and bi-directional speech) that were always 5 years away (since the mid-1950s). Our state-of-the-art approach was fascinating in hindsight. Improving digitizers were able to capture many more points (coordinates) as the pen moved across the screen, even when moved quickly. These points were used to connect dots, which could then be smoothed out to look like a continuous line of ink. Meanwhile, the starting point, ending point, direction, and other data were used to guess the letter being drawn. Recognition was obtained by comparing the series of captured points along with direction and speed of the pen to a library of pre-collected samples. This was done letter by letter, building up recognition based on pairs or triads of letters commonly occurring together. Then when a collection of letters was detected, something like spellcheck was used to recognize an entire word. It was rocket science, the kind of rocket science BillG loved because no one could possibly duplicate the effort to develop the technology. The researchers managed to attain some almost useful level of accuracy, perhaps 90 to 95 percent, enabling ink to be searched as though it were plain text or to be selected and pasted into Word as plain text. This physics-based approach was used for decades with slow progress, but state of the art in 2001.

Fast-forward 10 years and handwriting recognition was upended by an ingenious use of machine-learning image recognition advanced by research at AT&T Bell Labs in 1989 led by Yann LeCun. In a heartbeat 50-odd years of attempts turned into something that worked 99 percent (or more) of the time and was vastly easier to implement. The advances in machine learning represent the most fundamental improvement in computer science I’ve seen in my career.

A most exciting step with a new Windows release are new form factors. An even more (super) exciting hardware innovation was dubbed the “convertible,” which was a laptop that looked at first glance like a normal clamshell notebook, though smaller and thinner than most available at the time. Through a presto-change-o flip, the screen rotated and covered the keyboard to become a full-fledged tablet that resembled what Captain Kirk used on Star Trek (likely in size and weight too as the 8.5x11x0.8” device weighed 4lbs/1.8kg). In tablet converted mode, using a pen became the primary way of interacting, instead of a keyboard and mouse or integrated pointer. Techies have always loved and continue to love transformer PCs—presto-change-o is always a crowd pleaser.

The convertible form factor was particularly attractive to typical Office customers who craved mobility and could opt to use a keyboard and mouse when required for “full productivity”. This contrasts with a slate form factor, which (like an iPad today) is a screen-only computer, requiring a pen for all input and manipulation. Perhaps surprising, the idea of using a touch interface was not pondered primarily because the existing screen technology did not work with a finger, nor did handwriting for input. As we will see, even when rumors of Apple building a tablet surfaced (a pun!) the biggest question on BillG’s mind was how they acquired handwriting technology, or did they build their own solution which was bound to be inferior.

The dual personality modality was a significant source of tension across JeffR’s Information Worker division—does the design assume a convertible in which case Office was fine as it was, or do you design for a pen user interface? How productive did it need to be relative to how frequently the pen would be used. Every demo of a Tablet PC created questions (or concerns) about whether Office was participating in this future. There was no using Office without a keyboard and a mouse. Full stop. Microsoft’s DNA was such that a new OS required apps to push the OS to succeed, and the lack of Office was readily apparent. Worse, Office did not commit to “full support,” whatever that might imply.

Program managers across Tablet PC, Office, and Office applications spent months of meetings, prototypes, and discussions trying to understand each other. What did full support look like? In the best case, how should Excel work with a pen? Where and how would one input numbers and formulae? Did the Office user-interface work well when navigated with a pen instead of a mouse? We were in a circular platform-apps debate—the platform said it needed input from apps to finish the platform, while apps said it needed guidance on what the platform was enabling. The dividing line between platform and app is always tested when the organization represents that split (the same dynamic happens with front-end and back-end in web applications).

The platform believed it was enabling a particular scenario while the apps don’t value the scenario or had a thousand reasons why the scenario is way more complicated, and the platform should go back to the drawing board so to speak. In the case of supporting a pen as a replacement for keyboard and mouse, the list of what was impossible to do in a standard Windows app seemed impossibly long. There was a seemingly irrational insistence that every place one could type could also accept ink input, converting that to text. Being able to ink into the Excel formula bar was both awkward and a technical nightmare, with little benefit.

The only way to have pen support, I believed, was to build a pen-capable app from scratch. Unfortunately, the implication of that was that this new platform did not get Excel and there can’t be a new platform without Excel. Except this new platform was also just plain Windows and ran Excel perfectly, so long as there was a mouse and keyboard. Though requiring a convertible PC was out of the question because of the svelte attractiveness of the screen-only slate form factor.

Regretfully, the perception became that Office was stuck in the mud or resistant to change or influence. This was at least equally, if not more so, a problem of a platform searching for validation from Office without clarity for how apps should work. There seemed to be a great deal more work to do on the very basics of user-interaction before validating that with the most complex applications around. As would prove to be the case for a host of innovations around Windows, adding something on top of, or on the side of, Windows was not a sound method of creating either a new product or market, no matter how much we wanted the new market to be based on Windows, and more importantly to have compatibility with existing Windows applications, especially Office.

Beyond the technical integration was the ever-present go to market challenge. Was the new version of Windows for tablets a separate SKU and if so, was it more expensive, or were the tablet features simply extra features that would light up if the hardware supported them and likewise was there a special version of Office or did Office just light up with new features. We should not forget the ever-present tension over putting everything in the enterprise bundle versus monetizing new innovations.

The desire for optionality, both for Microsoft and OEMs, almost always pulled the product towards a strategy where features would be active if hardware supported them. That way third party developers could always assume the APIs were available on any Windows PC, making it safe to use without concern for system requirements. On the other hand, this also reduced the incentive to use those features (APIs) because doing so introduced complexity into a product where it had to test if features were available or not and behave appropriately. These challenges are why BillG always believed in the magic solution where developers used one and only one API and the conditional or variable implementation was hidden away in the API. Making this concrete it might mean a place in a product expecting typed input would magically transform into a place where a pen could be used for input. No one knew how to accomplish this in practice except for extremely limited scenarios that were more demos than reliable approaches. This was reflected in another classic tension point, which is how much of an application is simply a repackaging or use of Windows capabilities versus creating new capabilities in the application code? Recall earlier discussions over the role of text input and creation where Windows was woefully deficient which pushed Office to build significant capability in how text was entered. This would be repeated across every major component of the user experience—Office simply did not use much of what Windows had added over the years. The implication was that even if such magical transforming APIs were invented in Windows, Office would need to reinvent them for much more sophisticated and capable features that existed only in Office, including text input.

The disappointing truth would prove to be that innovation didn’t move from the platform to the applications, at least when it came to Office. Innovation was flowing from Office to Windows, while Office was no longer looking to Windows for direction. The dynamic of leading applications scaling to a level where they are both dependent on but separate from the platform was a sign of platform and app maturity. It would be a while before we’d learn how problematic that was for both Windows and Office. Right now it was a Windows problem.

Collectively, these lessons failed to contribute to evolving Windows for other markets including mobile phones and home entertainment. It would prove to be an amazing struggle for me in a few years when I worked on Windows.

In this case, Office, at the core, used a mouse and keyboard and did so in every single facet of design. Equally at the core, the pen was designed as an alternative to a mouse not as a reimagined interaction model. It was a pointer, like a mouse, and the fact that it also wrote on the screen was added to the side. In any existing Windows software, writing was done in a small window that popped up and allowed for a few short words to be written at a time. Those words were converted to typed text and inserted into the application. That’s how ink worked in all existing Windows products. Switching between ink for text input and typing was awkward, while ink remained inefficient.

The question was how to make the pen when used with apps like Excel work more like ink on paper. No one really knew because the first requirement was to shoehorn pen computing so as to require as few changes as possible to the existing code base. The theory was, and BillG strongly believed this to be the case, that the pen should just work. If this sounds familiar it is because “should just work” was a common refrain for Bill (This contrasts subtlety with Steve Jobs saying “it just works.”). The right architecture and abstractions should enable whole new implementations to appear above or below a given bit of code and like magic new capabilities appear. Programmers know this is great in theory but almost never works in practice. My rule for this type of capability is that unless the operating system ships having tested a particular type of replaceable layer then it doesn’t exist and if one attempts to use it all the problems will eventually surface. Outlook connecting to internet mail, Word converting to/from WordPerfect, Excel/Access connecting to Oracle database, Windows replacing the file system, and on and on there are too many examples to list.

There were so many challenges, we simply did not know where to start. Some of the problems were hardware related, such as while a typical screen might be 60 or more typed characters across, handwriting was more like eight to ten. All the on-screen places one might type characters, from simple numbers in a date to file names to formulas in Excel, all the way to full pages of text in Word, were too small for ink. Making them all larger was simply the first step in an entire redesign of the product.

While we were debating how to make the pen work, keyboarding was becoming a native skill replacing handwriting in schools. Kids were learning to type at the earliest ages, and handwriting was viewed as optional. Smartphones were not yet ubiquitous but sending SMS by triple-tap captured the imagination of teens around the world and replaced the proverbial handwritten note slipped under a desk. Maybe the opportunity for pen computing was generational. . .a boomer scenario?

Bigtime bosses were very excited by the prospect of pen input. In the EBC and with execs in general, taking an existing typed document and marking it up with ink annotations captured their imagination. They loved this. In fact, I loved it. I reviewed significant memos this way—printed them out and wrote on them in red like a teacher. I took notes at meetings on printed out PowerPoint decks. Yet even I was skeptical that such a scenario justified an entirely new computer. It did not even need a new version of Office. The easy solution could take an image of the document (a PDF!) and support ink on top, exactly what the Tablet PC team’s notetaking app, called Journal, did. It was a fantastic solution. There were still limitations, such as that the ink writing was huge compared to what was easy to read text. In fact, about all that could be done effectively compared to a real pen on real paper were gross annotations like arrows, circles, or crossing out with an occasional “bad idea” scrawled. The technology was not a replacement for the commonly used paper markup scenario. Not even close. It did not help that using a PDF-based solution was completely off the table as far as Bill was concerned. His feelings about PDF had not changed in the intervening 7 years since I first confronted him about the advantages of the format.

Even with those obvious limitations, BillG wanted those annotations and comments to use the semantically rich comment and annotation features that were part of Word, Excel, and PowerPoint—the track changes features used by lawyers. There were many problems with this including training people to use proofreading marks to change text versus typing using the existing keyboard features. The screens weren’t big enough, digitizers weren’t accurate enough, and handwriting recognition not good enough for these features to work.

The Journal app remained the closest we had to a killer app within the Tablet PC team—simply using ink as ink, with occasional translation to text. They made a cool feature where you could print a document to Journal and then mark up on top of it as though there was an acetate layer over a document, spreadsheet, or slide. It had all the limitations above, but the demo was perfect for executives.

Several Microsoft executives were early adopters of the new tablets. While they were effusive about the benefits, there was an aspect of them was difficult to escape. The amount of focus and attention it took to take notes with Journal was excessive. It was a head down, blinders on sort of focus. In meetings with people using the tablet maybe the notes were good, but it was a strain on engagement. As if to emphasize the limitations, executives that liked to print out their notes and file them soon discovered that a full screen of notes in Journal printed out cartoonishly large on standard paper due to the relatively low resolution of screens.

In early tests with the tablet across the company the feedback was uniformly positive, surprisingly so. As we kept digging into it, what was clear was that despite the heft of the early devices they were much lighter than the typical Microsoft issued laptop, which came in at 6lbs or more. It wasn’t necessarily the use of a tablet that people were positive about, but simply having a 4lb laptop. The early tablets were designed as premium PCs, which meant they were light, thin, and very expensive. It wasn’t merely the extra hardware for the pen that made them expensive, or the fancy hinges. The PCs used the latest in chips and displays too.

No matter what limitations, or frankly impossibilities, were raised, it always came back to Office being stubborn or resistant to features from other groups. Microsoft’s inherent bias was always to suggest that the new group with the product that wasn’t done yet was in the right and the existing group was resisting—in many ways this was a correct diagnosis and the right bias to avoid stifling innovation. Such a bias left little room for acknowledging that something new might not yet, or ever, work as intended.

It was clear, by collective body language and explicit direction, that Office was on the hook for something. Aside from adding ink to Word and Excel, what we needed was an Office version of Journal. The idea for a free Journal that came with Windows and a fancy version that was part of Office was exactly like the original strategy of having the mini word processor, Write, with Windows and Word in Office. Could we take a pen-centric approach like Journal and create a new category of productivity app, designed for ink but integrated with Office? Perhaps a Journal that also worked with Word and Excel? Or Word and Excel that worked just like Journal? Should Office build a product specifically for one kind of hardware that would likely sell in small units at first? Would such a product make defining SKUs challenging? We already had a half dozen SKUs and customers routinely expressed frustration with the complexity even though the bulk of our business transitioned to enterprise agreements where SKUs don’t matter much. So many questions about what seemed such a simple request. . .this type of routine program management was difficult and not particularly suited to executive-level strategy discussions.

There were many potential categories for Office to enter as we understood from JeffR’s opportunity map, but none seemed uniquely suited to tablet or convertible devices. Notetaking, however, was perennially on the minds of journalists and reviewers, implying anything we did would get a lot of personally motivated (though potentially nitpicking) coverage. Press encounters were also an opportunity to do research on information work. How did the reporter take notes? What tools were used to organize stories? How did they structure the writing process? By 2000, reporters were mostly using a Windows XP luggable with a big power brick in tow, while using Word to take notes during discussions. At most press events we often set up elaborate strips of outlets (and dangling network cables) attached to tables so the power-draining laptops of the era could plug in and file real-time stories. Invariably, reporters bemoaned the inadequacy of Word and Windows for the sort of juggling they did, working with notes, interviews, emails, documents, and later photos. Office didn’t offer a tool to work with these in one place.

In the old days, this category of software was sometimes called personal information managers, brainstorming tools, or outliners. It was never a big category and fragmented among the many small players and metaphors. It was almost exactly the kind of software we tended to avoid. There didn’t seem to be a winner-take-all strategy, nor did there seem to be a ton of revenue. On the other hand, if we could somehow develop an innovative product that caused people to rethink the category there was potentially a broad and horizontal product that could yield much-coveted organic growth. We discussed the idea that all the Office tools were about producing final and permanent documents, but we lacked a tool for ephemeral information. This seemed to be a potential anchor for a new product. I was under a good deal of pressure to provide innovation in a new category that might lead to new revenue.

Notetaking was definitely worth a try. What’s old was new again.

Trying to navigate the urgency to engage on a pen application and have something consistent with Office, I sent an email to Chris Pratley (ChrisPr), the leader of Word program management, to frame the need for a solution to notetaking. Chris was a Waterloo graduate hired to work on Word products who had previous experience living and working in Japan. He was instrumental in the transformation of Office to an extremely successful worldwide product, especially in Japan. Chris was also one of Microsoft’s earliest contributors to UNICODE standards. Aside from his East Asia experience, Chris was an exemplar of Office program management when it came to defining products and executing.

Our biggest concern was that we would embark on notetaking only to end up with a subset of Word, re-creating the problem of Outlook and Outlook Express, but with the anchor tenant and most used Office app. We wanted to innovate without developing a confusing subset of Word. Customers were already using Word for notetaking but adding a notetaking mode to Word to address missing features would have been a horrible mess and bloat for most customers.

Innovator’s Dilemma would say to create a new team to target new customers, but that almost guarantees a collision with Word (as we saw with Publisher). In our world, any time a new team was chartered they will invariably spend 90% of their initial time revisiting basic user interaction models and duplicating basic infrastructure of the main competing product—such a dynamic was rampant at the company in the early 2000s with every new team creating their own variant of menus and toolbars with a web-like twist under the guise of being easier to use and innovative.

The other option was to ask the Word team itself to develop the product as they would be most sensitive to colliding or overlapping. But would that impossibly constrain the team and create an odd product that spent too much energy not duplicating Word, even if it made sense? Again, so many questions . . .

Most products dedicated to taking notes proved to be subsets of Word, where using Word bullets, numbering, and outlining would suffice. Scenarios were changing, however, and notetaking was expanding to include collecting snippets from the web, links, photos, and even audio and video from new laptops incorporating cameras and microphones. To differentiate notetaking from Word, we needed a novel approach to the problem that went beyond typing (and inking) and basic text entry. Tailor-made for user research, notetaking was the kind of thing researchers loved to study. Suddenly, the hallways were filled with examples of notes, the flow of notes for different authors using different tools of Office, notebooks and ways people organized them, notes for students in classrooms, notes for home and work, and more.

Examples from the Office hallway in building 17 showing notes and notebooks collected from a field study. (Source: Personal)

The team was excited and quickly converged on prototypes and an approach that was ink-centric yet also text-centric and highly differentiated from Word—in other words they took on all the work to design a product that seamlessly worked with ink or with a mouse and keyboard, or both. Peter Engrav (PeterEn) joined to lead software development. PeterEn, a rare Bellevue, Washington, native, was one of the most thoughtful development leaders on the team—he was also a founding member of JonDe’s Office development team working on Escher graphics. Our offices were next to each other during the Office11 project and he and I often discussed the choices he was making into the late hours of the evening. The team picked a code name even though Office tended to shun code names, Scribbler.

ChrisPr took the team through a planning and vision process just for Scribbler. The team had sketches, prototypes, and a vision, Scribbler.doc. Perhaps a most impressive aspect of this process was how closely the concepts and details outlined in the original vision made their way to the final product.

From the outset, Scribbler intentionally did many things differently, as expected. We viewed it as a chance to pioneer some new approaches. While not as freewheeling as it might sound, the team would definitely say they would bump up against the culture of Office more than once—ironic given that PeterEn was a founding member of the Office development culture.

Scribbler built a native XML file format with next-level robustness, as one of those new approaches. Scribbler’s files could have multiple people edit a file at the same time and almost immediately see the changes made by others. Editing by multiple people seemed crazy for a personal notetaking product, but early on the idea of shared notes or group notes became a hallmark of the innovation. To enable shared editing, Scribbler would eventually be able to use SharePoint and, for one of the first times in a Microsoft product, data was stored on the internet (what eventually came to be the cloud). While we abandoned many of the MyOffice internet experiences, Scribbler eventually offered a key demonstration of native internet services.

Scribbler was able to focus on truly differentiated features because it was the first new product to make use of the MSO.DLL, or the Microsoft Office library of shared code. For the five previous years, Office engineered a platform of shared code for Word, Excel, PowerPoint, Outlook, and others, but no new product tried to use this code starting from a clean slate. Remarkably, PeterEn and the development team were up and running in short order by using this code—normally it would take months of work for a new application to take shape. With minimal effort, Scribbler inherited all the basic capabilities of an Office application, such as menus, toolbars, localization, Watson recovery, fancy graphics, enterprise deployment and management, plus engineering and test tools, and much more. This let the team focus on the core task of taking notes. It was exciting to see MSO in action and, most importantly, to show that in middle-age Office reached a significant level of operational maturity. InfoPath, discussed previously, also used MSO.DLL.

The novel experience of Scribbler and the key differentiator for users was the ability to write or type anything anywhere on a page. Just like on paper, one could simply tap the screen with the pen and start writing or click the mouse and type in that spot on the screen—delivering on the promise of the NetDocs universal canvas demo from Forum 2000. If one thinks about each of the apps, Word documents are bottomless, starting at the top and continuing down with a fixed page width. Excel is an endless two-dimensional grid. PowerPoint is a fixed-sized rectangle that allows anything to be put anywhere. Scribbler was bottomless, two-dimensional, and it also let users put anything anywhere simply by clicking and typing or tapping with a pen and writing. Ink and text were seamlessly and effortlessly mixed. Content like photos, videos, and audio could be added anywhere on a page. In a hint at the future of all applications, Scribbler also let users mostly ignore files and the tension-filled process of saving data and simply organize thoughts as one did with a paper notebook, with tabs, but with the advantage of software. Reorganizing and quickly searching across all the notes brought the power of software to note taking.

One area where Scribbler diverged from the way the Tablet group thought was integrating handwriting recognition. ChrisPr and team found in working with early adopters that recognizing ink as text was of little utility—people rarely wanted to convert their ink to text. In fact, people loved leaving ink as ink. Where recognized text was most valuable was in searching through the ink notes. Scribbler constantly recognized the ink converting it to text for search, but rarely did that ink get used in other places. Journal had taken the lead from BillG who was literally obsessed with converting ink to text and was generally against leaving ink as ink. It was a debate he and I had many times when looking to expand the use of ink in Word and Excel.

There were many seemingly small but novel touches in the product such as the ability to create a table by typing, hitting tab, typing, tab, typing, return, and poof, a table appeared. Scribbler also created checklists—list items that could be marked as to-do items, checked when completed, for shared or personal use. Scribbler supported photos, drawing shapes, and a whole range of outlining features.

The most eye-popping demo was when taking notes on a new Tablet PC, whether typing or using a pen, Scribbler could record the audio of a meeting and keep track of what notes were taken during the recording. One could easily hop from a note to the full recording of the meeting or vice versa across pages of notes. In another demonstration, easily drawing diagrams using a pen on a PC with the same ease as on paper was unimaginably cool.

Despite all that it offered, and as important as I thought it could be to the Office franchise as a growth opportunity, Scribbler would become the next innovation to get caught up in the challenges of bringing new revenue-generating capabilities to market with Office. Should Scribbler be a new category of software with dedicated marketing and sales yielding new organic revenue, or should it be added to the Office product enhancing the suite for every user? We faced this challenging decision so many times: Outlook, FrontPage, SharePoint, and now in Office11 with Scribbler and InfoPath.

Scribbler was designed to be a core part of the Office suite, a broadly horizontal product, not for a small or specific segment or narrow selling proposition as we saw with InfoPath, Access, Visio, Project, or Publisher. Yet, in an ironic twist, Scribbler did not make it into the suite and was destined to be a new category.

Normally this would be a great idea. A new category meant a real revenue opportunity. That opportunity was only realized with a dedicated sales effort. A dedicated sales effort for a broad, horizontal product would be nearly impossible because those same resources would be selling the Office suite and upselling to EAs or more expensive suites. Recall, however, that the notetaking category was known to be fragmented and small. Such a category has a low return on investment. Customers are hard to find and the efforts at reaching them don’t scale well. When you do find those customers, because there are so many alternatives, there is little pricing power.

Adding Scribbler to an existing suite would make the product available to everyone, which would be great, but would not alter the sales motion unless it became the key reason to upgrade or sign an EA. There were no such plans. In fact, the formal Office 2003 product guide mentions the new product exactly twice in 170 pages. One mention is a trademark footnote and the other in the SKU table, whereas Outlook is mentioned almost 200 times.

Scribbler was a product for everyone but marketed and sold to no one. The only suite Scribbler was added to was Office for Students and Teachers, used as a way of communicating that the low-priced suite was poorly suited for business enterprises because it included a notetaking product. In fairness to marketing, Scribbler had done some pioneering work with students at the University of Washington to support notetaking in college courses. Students loved Scribbler, which was also a testament to the product design for a version one product.

It would be reasonable to ask why I did not force the issue with marketing. Primarily, my view was that SKUs were entirely a marketing decision and accountability. With a dozen individual applications to mix and match, marketing spent the better part of a year picking and choosing combinations. The development team invested in features to make the production of different suites easy. I would be remiss if I didn’t mention that to consolidate marketing across the entire information worker business, JeffR took on marketing as a direct report as well. Packaging literally wasn’t my job or accountability.

I have exciting news to share: You can now read Hardcore Software by Steven Sinofsky in the new Substack app for iPhone.

With the app, you’ll have a dedicated Inbox for my Substack and any others you subscribe to. New posts will never get lost in your email filters, or stuck in spam. Longer posts will never cut-off by your email app. Comments and rich media will all work seamlessly. Overall, it’s a big upgrade to the reading experience.

Right up until the last minute, we had trouble coming up with the commercial name for the product. Scribbler was a good name the team loved, but we were unable to secure the rights. Eventually, the marketing team settled on OneNote, a perfectly good name but the one that left the product team somewhat bummed. Over the course of the product cycle, Scribbler really grew on the team and came to mean a great deal to them. Most (including the press) had a first reaction when hearing OneNote as it reflected the common expression “one note wonder” as in lacking range. It was a name where common usage reflected poorly, shades of DIM Outlook. In a small form of passive protest, some on the team mockingly referred to the official name as Onay-No-Tay. Fortunately, this name led to a tagline “One place for all your notes” and that made everyone happy. Like every naming exercise I experienced, eventually everyone warmed to it.

The product went on to be much loved by a core set of customers and received many super positive reviews. Ed Mendelson of PC Magazine, a longtime (very longtime) reviewer of productivity tools, called OneNote “breathtakingly well-designed.” Paul Thurrott, also a longtime Microsoft commentator and often a critic (especially of me), said, “In my mind, OneNote is one of the best applications Microsoft has released in years.” He and other reviews bemoaned the fact that OneNote was not included in the typical Office suites they bought.

The Tablet PC group was both happy and disappointed with OneNote. On its own OneNote showcased the new convertible Tablet PCs. Reviewers who loved OneNote were anxious to get their hands on one of the new devices, and certainly all the device makers were anxious to show off the capabilities using OneNote. At the same time, the existence of OneNote was viewed as some sort of cop-out relative to solving the big problem of using ink as a first-class input in Office apps. Perceptions aside, we invested disproportionate engineering effort to implement ink support in Word, Excel, and PowerPoint.

I viewed that criticism as harsh and a way of dodging the real question, which was whether ink was broadly suited to productivity or simply a way of trying to use software to emulate an old way of working. Was it the equivalent of controlling the first motor cars like a horse or was there something deeper about the benefits of ink? Was using a pen and ink something that seemed natural to a generation that had to learn to type later in life? Was handwriting a skeuomorphic answer to human-computer interaction that long outlived its need as a technology bridge? It might be an ironic twist that finally after decades of research and development handwriting, which was always the next big thing just five years out, improved to the point that it worked but the market that might have existed moved on.

We are 20 years through continuous investment with massive improvements in recognition technology and first-party hardware that supports pen input, yet the usage remains de minimis.

I have such a warm place in my heart for OneNote. The team did such a wonderful job. It was a breakthrough product, taking advantage of the latest operating system, while leveraging the latest hardware. Failing to capitalize on it with the field and business left me feeling that I let the team down. Microsoft couldn’t capitalize on a horizontal, pure-play productivity tool—the sales team and Office bundle wanted IT-centric, and enterprise-focused products like InfoPath. OneNote was a distraction.

The good news: There was no shortage of complicated features for IT professionals.

On to 073. **DO NOT FORWARD**

With the announcement of .NET, Microsoft was overflowing with projects, many not yet products, destined to become the next big thing in one area or another. Everything had a “Net” somewhere in the name and everything was in the press or in an enterprise strategy deck. There was plenty of optimism, but collectively the company was well ahead of itself. There was simply too much going on to have a coherent strategy or roadmap, even though BillG was 100% focused on that, having assumed the role of Chief Software Architect. The push-pull of “be more innovative” and “ship real soon” meant that many of these efforts were at the ends of the spectrum of “architecturally suboptimal in order to finish” or “architecturally correct but can’t possibly finish”. The unwinding of projects like this is incredibly painful for everyone involved, especially when what really happened is so different than perceptions.

If you have not seen part 1, check out 064. The Start of Office v. NetDocs

Back to 070. Office.NOT

Hardcore Software is a reader-supported publication. To receive new posts and support the work, consider becoming a free or paid subscriber.

I was still working through the stages of grief over a product getting killed or at least wounded, considering what happened to Office.NET quickly renamed Office11 at the last minute. Karma was about to come back around and bite me for, ostensibly, doing the same. Since Forum 2000 in June, the NetDocs product continued development. The team expanded, absorbing products, and broadening the mission. BrianMac used the same approach and much of the team that created Outlook.

The team was fired up but going in several different directions. Depending on who you asked on the team, NetDocs might be something different. What originally started as a new style of document creation tool, blending aspects of word processing, spreadsheets, and databases, expanded into a full-blown email program to replace Outlook, a photo editor, and even a web browser. It was also using the latest (unfinished) and most strategic technologies. Sensing the excitement over XML, the product also found itself deep in that strategy and brand new code. NetDocs was also using the latest reusable code from Internet Explorer, which was great for the IE platform but also meant it was not exactly what most customers thought about as a browser-based implementation. Along the way, it created some of its own technologies such as the ability to install updates easily over the internet. There was a lot of excitement over a product that does. . .everything. How could there not be?

On paper, this was quite something. During the early days of MS-DOS, these all-in-one products always struck a chord with techies and regular people alike. The idea of using only one tool to get everything done, including email, was insanely appealing. In demos, everyone, especially BillG, got excited. The idea Microsoft could finally crack the all-in-one category with a professional tool would be huge. ChrisP had a name for a design demo that incorporated “all the best of everything in one easy-to-use app.” It was called Uniprog Deluxe. That’s what we came to call this expansive vision. It wasn’t meant to be cynical as much as it was meant to imply an unachievability.

Importantly, NetDocs was also a key part in the nascent strategy to use XML everywhere. XML was being pushed heavily by BillG. Despite being a simple text file format, Bill had let XML take on the role of providing a proprietary advantage to Microsoft in some way. This was a difficult topic to discuss because it conflated several aspects of implementation (such as where the actual intellectual property or code was) and appeared to assign proprietary value to a simple text file. Much of the excitement around XML (and thus NetDocs) was because of the concerns over the now ubiquitous HTML format and lack of proprietary control Microsoft had over a format. In short, XML was the way to regain a proprietary control over an internet technology. Whereas HTML was viewed as a display format, XML was viewed as a structured data format. I had a difficult time with the magic attributed to XML, especially because Office was already invested in HTML. I was holding on to the notion that HTML would remain human-readable at some level, whereas XML was brand new but already super complex (advocates would say it was never meant to be human readable). We planned on a significant amount of XML work, but viewed it as interoperability more than proprietary advantage. For example, Excel would be able to import XML data files such as those from the Securities Exchange Commission or SQL databases.

There was one big problem. And a lot of little ones. The big problem was creating yet another email program—while NetDocs did try to do a lot of things, everything emanated from being an email and scheduling product. Microsoft went through several years of a comical email client strategy that was confusing and frustrating to customers. Email was literally the most important product the company was building and the most important enterprise product. Not only was it the key server product, but it was also the key new Office module. Perhaps that is why we had so many email products in the market and in the works—something important attracts a lot of attention from development teams looking to do important work. In a world where we were just establishing enterprise credibility, having multiple email programs was a disaster, especially when our flagship one wasn’t so well-received, yet.

When something is hot, however, every project converges to that product. So everything had to do email.

We had Outlook, which was struggling to become a great product for Exchange and enterprise email. After the initial release that just made it into Office 97, there was the split and the creation of Outlook 98, which was either a not-so-great Exchange client or a not-so-great internet mail client, but not both. Then for Outlook 2000 and then again with Outlook 2002 (XP) we failed several times at becoming a more reliable Exchange client with a new storage engine. Finally, with Outlook11 we committed to addressing the problems, come hell or high water.

We also had the new browser-based version of mail, which we named Outlook, technically Outlook Web Access, even though the relationship to Outlook was zero when it came to code and only acceptable when it came to user experience and features. The inability to share code and limited capabilities of rendering all of Outlook in 2000 era web browsers caused this divergence and inefficiency. Customers were extremely enthusiastic for the promise of browser-based email with Outlook Web Access.

In 1996, the Windows team released Internet Mail and News, or IMN, which became a much-loved internet mail program. It was part of Windows and Internet Explorer, made by the same team. IMN was plugging along doing great things for the internet when it became clear to our enterprise sales efforts that we could not have a first-rate internet mail and so-so Exchange mail. The solution was—and I’m not making this up—to rename IMN to Outlook Express.

This was a decree that neither the Outlook team nor the Windows team liked, but the theory was that it clarified the products for customers. The IMN team did not want to be tainted with yucky enterprise Outlook, and the Outlook team didn’t want to be confused with free or, for that matter, the internet. Customers called everything Outlook and were, basically, always confused. Product support was confused. Reviewers were confused. Most of all, normal people were confused. It was a silly, self-inflicted mess that continued for more than a decade, except for the reality that in 2001 work on both Outlook Express and Internet Explorer stopped, and and improvements were dependent on the future Windows Longhorn. There were no plans to update either on Windows XP. Those capabilities were going to exist in some new form on Longhorn.

We had Outlook, Outlook Web Access, and Outlook Express. The branding and naming relationship was much deeper than any technical one.

To complete the mail strategy, we also offered Hotmail, the web-based email acquired in 1998. Hotmail was both a mail “client” and a mail “server” in BillG architectural diagrams. MSN mail was trying to converge to Hotmail, but was also building a client-side application to compete with AOL (and thus a client mail experience). Hailstorm was slated to provide (or connect to?) a set of these email experiences, but it used a different protocol.

If you were to try to build a matrix of mail clients and mail servers and which connected to which, you’d have a matrix with many holes. Our strategy was a mess.

Many reporters (and customers) at the time looked at this mess and thought of teams competing and some sort of bloody “there can be only one” battle within Microsoft. From inside, it was not that at all. In fact, by and large the teams did not care what each other did. In its own way, each team thought they would win out in the way they expected and the others simply wouldn’t be relevant to the battle the way they defined it. Outlook Express was certain they would win against Eudora (the leading classic internet email program) or Netscape Communicator, if for no other reason a bunch of people weren’t going to pay for Outlook (not to mention, that Outlook was in no way competitive with Eudora). They were right, and the Outlook team put little energy into competing with Eudora or Outlook Express. MSN was going to win with their own subscribers and be the best (and only) experience for their dial-up customers. Hotmail was going to become advertising supported and win in browser-based email. Outlook proper anchored itself in the corporate market with Office, and made all the money.

There was a competition and that was for people. Recruiting and hiring was a source of conflict. Often when a new group spun up, recruiting kicked into high gear. There were neither rules nor much of an internal system that managed individuals moving between teams. Most moves happened by word of mouth. Teams would routinely bump up against the norms (not formal rules) by implying the potential for promotion or broader responsibility with a move. More often than not an employee would get caught in the middle of one manager recruiting heavily and another manager trying to hold their team together in the short term.

Such staffing skirmishes uniquely impacted Office where the vast majority of our hires came from college (hundreds per year) and we maintained a strong culture of finishing a release that was started. Luring people away from the team mid-cycle was something we deeply frowned upon at a cultural level. New hires with even a partial release of Office could join a team having gone through valuable training and initiation by Office. At release boundaries, Office proved a strong net exporter of people to other teams, renewing our own teams with even more college hires the next year. Since there was no coordination by HR, more than anything it was this cross-recruiting that introduced friction between teams.

If there was drama it was mostly constrained to the boardroom where the complex matrix of what worked with what, and who was using the latest technology were BillG’s main discussions. Most of the time the problems were not anyone’s fault, as much as the teams thought it unnecessary to implement something because their customers didn’t care.

Yet the strategy from the top of Microsoft was to resolve these architectural “impurities” and to strive towards rationalization and consistency. Still, that did not create competing groups as much as a set of groups that all thought the other groups weren’t doing their part to increase synergy. There wasn’t anger, hostility, competition for resources, or anything substantial. Mostly, it was just eye-rolling and exasperation at a lot of meetings followed by long emails over how impossibly difficult some alignment would be technically.

The post-2000 Microsoft (after Windows XP and Office XP, with the arrival of the enterprise business) was a period of extensive meetings around synergy and strategy. At the extreme, groups could spin out of control on their own by signing up for too much synergy and strategy. At another extreme, groups could stay focused on shipping. Leading the former meant receiving high praise and attention internally while failing to deliver or delivering what was perceived as suboptimal. Groups of the latter type shipped and often received poor marks for lacking strategic alignment while developing a reputation for being difficult to work with. The reader is invited to guess which type Office was closely identified with and I came to personify that. Nothing occupied my psyche more than this reality I lived. Shipping is really difficult, even more so at scale. As ChrisP used to say in his “Shipping Software” talk from the early 1990s, it is like everyone comes to work every day to prevent a team from shipping. “Everyone” can be many people in a big company.

Every once in a while, something would get so visible and so tricky that a decision would have to be made and we could not just let some notion of passive-aggressive Darwinism decide.

NetDocs was another mail program, one that would in theory work for both Exchange and internet mail, and maybe even Hotmail, MSN, or new Hailstorm mail. Over the intervening years, since the NetDocs team was formed, Outlook won over corporate America and gained an enormous number of features—very difficult to code features. Everything from handling attachments to scheduling meetings across time zones, shared mail accounts, recurring events, sharing calendars with coworkers, SPAM protection, security, looking up other employees in the corporate address book, plus to-do and task lists, and personal contacts, and still more. Those features were built in Outlook; in fact, many weren’t even available in the web version of Outlook Web Access (thus adding to the complexity of our mail story).

To software architects, the code implementing the semantics and capabilities of the Microsoft email solution was in Outlook running on the desktop, not running on the server. It was architected in a decidedly old-school manner, mostly out of necessity but also because of history. The problem (the big problem) was that there was no way for NetDocs to implement all those features either on its own or by sharing code with Outlook. It would be like trying to use Word’s code for footnotes in PowerPoint, without dragging along all of the Word code. Code doesn’t work that way. Getting all that right in the new NetDocs code base was a long project. Infinitely long. The team knew this, primarily because it was made up of many members of the original Outlook team. They were not worried. Their intent was to introduce NetDocs and add features over time.

There were nearly countless smaller features and implementation details to worry about. Being built on all the latest and greatest technologies from .NET and Internet Explorer was great in theory, but in practice most of those technologies themselves were far from being complete. In a commercial product for hundreds of millions of customers, they expected the product to handle typing in the world’s languages (left to right, right to left, vertical and switching between)—a particular hot-button for Office given how much work we put into this area. They expected it to understand how dates, time zones, and other locale-specific data worked, which was especially important in calendaring, and they expected it to work with accessibility tools for people who needed assistive devices to read the screen or used alternatives to mice and keyboards. Customers wanted the product to work on the hardware they owned with the amount of memory and processor they already had. These “abilities” as we called them were a long list of requirements to just release a product that carried the Office logo. Many of these might make sense to readers today because the operating system, particularly mobile phones, provide this auto-magically by simply using the platform as intended and this is verified in the App Store submission process.

In a series of meetings and demos to BillG, SteveB, JeffR (who managed both NetDocs and Office), and many across the company, it became clear we were heading for something a big company never wants to happen—a decision meeting with consequences. I often referred to a line from the movie Wall Street when Gekko (Michael Douglas) sighs, “Showdowns bore me, Larry. Nobody wins.” It is never a good thing when there are only two options on a substantial decision and a deadline, forcing one side to walk away a winner and another a loser. Management is all about avoiding these situations in the first place. The Microsoft of this era didn’t make choices early, and for good reason—the original Windows project was exactly the kind of thing that could arise if you let ideas flourish. Windows NT was essentially a side project. Windows 98 (98 SE, and Me) took on the role of side project. The whole company was built on what were rebellious side projects.

It is easy to skip this point or to take the point of view that conflicting side projects are a cultural disaster that eats a company from the inside. It is very easy to say that. In practice, projects that might conflict also create optionality. Great CEOs treasure optionality. BillG was one of those. The risk is not having too many options, but too few. The other risk is that all the options being developed converge on products that look too much like what we already have versus new approaches. That is the mistake Microsoft made with some frequency. Too many photo sharing tools. Too many data access technologies. Too many mail clients. Each of which was similar, but different while not anchored in a scenario that introduced a step function change in the trajectory of a category. The key indicators of potential trouble are usually obvious in hindsight. First, the project plans become especially expansive and generally can’t be scaled back because every feature area is critical. Second, the team size becomes especially large. Rarely do small teams cause big problems.

In this case, NetDocs worked super hard and made a ton of progress. Between two alternatives of fully replacing Outlook in the next release of Office or adding a fourth mail program even one that was potentially exciting to Microsoft’s already confused mail strategy, there was no good answer. Not wanting to decide immediately, a question was how much more time it would take to be a full replacement for Outlook. Brian and team wanted to release a product and grow into the market, rather than wait and wait perhaps suffering from the enemy of the good is the perfect syndrome.

Unfortunately, catching up over time seemed like an unbounded problem as well—Outlook and Exchange were evolving. These products were still early in their lifecycles. For example, the major work to improve reliability was about to start and that could have a broad impact on all the code already written for NetDocs. Across Office, everyone was working to integrate with Outlook. In the competition with Lotus Notes, we continued to try many new features to embrace programmability of mail. It was not simply replacing a static view of email but plugging into an entire collaboration strategy. We already failed twice trying to use the new storage system for Outlook, would NetDocs be able to make it work?

The only thing we could do, and have a rational email strategy, was decide not to ship NetDocs and find a way to create a new product that did not try to replace Outlook. That’s what I wanted to do and advocated. The past few years of trying to stabilize Outlook left an impression on me. I didn’t see a path where NetDocs could ever catch up and was deeply concerned about customers perceiving the need to choose between NetDocs and Outlook, knowing how much of the Office value proposition was built around communication scenarios using Outlook.

For all the good ideas and hard work, a clear decision was needed. We discussed alternatives with the leaders on the team. There were well-deserved mixed feelings and some significant pushback, and honest emotion. The leaders on the team knew the facts and challenges, and so did most of the team.

Brian met numerous times with BillG and SteveB. Along with the NetDocs leaders, JeffR, Brian, and I met with BillG to decide on a plan to ship NetDocs with Office or not, and not shipping probably meant shelving the project. Brian hated this kind of meeting. Showing up with two options always meant debating a third option. When it came to this level of technology and product, however, it was increasingly difficult for Bill to have the best or most informed opinions. The company was made of so many brand-new products and technologies, no one could keep track. The NetDocs team was exhausted. They had worked tirelessly for the weeks leading up to these meeting to see just how much they could get done. Knowing them well, I could sense the resignation.

It was too tall an order to deliver on all the new things while maintaining compatibility with Exchange and Outlook, while advancing in all the ways they intended. It might sound like we could finesse having two products, but not for the Office business, not against Lotus Notes, certainly not for enterprise customers with new Enterprise Agreements, and definitely not for industry analysts and the press. Our credibility as a company was on the line and too much was at stake too soon in the adoption curve.

The team tried to do too much, too soon. Brian agreed with Bill that team should have focused more on XML seeing how important that had become to the strategy, and that it would have been too difficult to have a sort of slow burn email strategy where it took several releases to surpass Outlook. There were better ways to have a bigger impact, and sooner. Bill was clear he should have provided more direction to the team on priorities. There was ample humility and professionalism to go around. As painful as this transition could have been, much of the difficulty was mitigated by the level of accountability Brian and Bill demonstrated.

Brian pushed to have the refocusing of the product to XML scenarios happen within the Office team.

We held an all-hands meeting with the NetDocs team in the cafeteria, led by JeffR. While the decision was made between BillG and BrianMac, there was no escaping that some perceptions of this were about how I held control over the Office “box” and thus I ended up bearing the brunt of it, especially for those who thought NetDocs was closer to realization than not. Any meeting like this was going to be tough. Still, cancelled and redirected projects are a part of engineering and often turn out to be important lessons for many. I had just gone through a last-minute reset as well.

Few engineers make it far into a career without enduring at least one major project reset.

I was caught off guard by how much the press had continued to portray this as a battle, my battle. There were so many difficult situations, differences of opinion, and product challenges, but this wasn’t one of mine. I experienced a friction between teams, primarily over hiring, and some regarding product claims when it came to working with Exchange. The irony of the situation was the friction was mostly rooted in the history and connections so many of the engineers on the team shared. It was as if members of the old Outlook team started building a new Outlook to take on their earlier creation—perhaps a second-system syndrome as detailed in Mythical Man-Month.

When a project goes through a big change or reset, the feelings come out. When a project is in the press too early in its life, then these feelings make it to the press too. I knew enough to understand that people want to find a clear point of responsibility, even blame. I was an easy target. It would not be the first time.

It was also ill-advised to engage the press on these stories, leaving them to be based on whatever perspective was tipped to one of the Microsoft beat reporters. I understood it was clearly part of the job for me to take on accountability for things that don’t go well, even when it feels like a stretch to call something my fault. I watched every manager or mentor I had (BillG, JeffH, ChrisP, MikeMap, PeteH) do that more times than I could count. Like so many difficult situations, the NetDocs transition proved a valuable learning experience.

Many on the NetDocs team used the project reset as a chance to stick their heads up and see what other opportunities were going on around the company and beyond. More specifically, there was a noticeable exodus of middle pyramid people in this era. The core group that remained earned a unique opportunity to create an entirely new product for Office11 focused on maximizing the value of XML. That was the constraint. My view was that if they were close enough to spend all this energy on NetDocs shipping in this timeframe, then they could ship the less complex product (without email) while still having the full Office11 schedule to work. They would be able to use the Office shared code to bootstrap the entire app, which would save a huge amount of time and also make consistency and synergy much easier.

During the project, NetDocs had expanded scope broadly so as to include the universal canvas, XML editing, XML data transformation, new user interface, a mail and calendaring client supporting both old and new protocols, and many more. To support these the team grew to a significant size—over 500 people. To put that in perspective, the entire Office team was about 2,000 people including everything sold under the Office umbrella. Office maintained a long history of letting people move around the different teams (or, staying put if they chose) at the break between releases. That is exactly where we were which enabled many to easily move to other parts of Office (or other teams). Don Gagne (DonGa) who previously led Outlook and then moved to NetDocs would soon find a huge role in Office, so it was rather fortunate he stayed on. In writing this, I know that all these names can sometimes seem to be overdoing it but having read many accounts of how things happen in big companies I always feel that too many key contributors and their work are left out. There won’t be a quiz at the end.

From NetDocs, Don Gagne (previously from Outlook) would lead a newly formed team called XDocs, short for XML documents, along with Rajesh Jha (RajeshJ) leading program management. XDocs was NetDocs repurposed to an end-user tool using the XML technology using the core NetDocs code base—at a high level NetDocs without email and calendaring. There was much work to be done in that regard, including the difficult work of right-sizing the team for the task at hand. PPathe would step up as a VP to provide additional leadership in helping to integrate and shape XDocs. He brought with him a deep understanding of the history of SGML (the predecessor of HTML) and the way Word embraced HTML, which would come in handy when it came to XDocs integrated across Office.

The team went through a fast process to identify where XML technology in NetDocs could be reused. XML generated a ton of buzz in the industry as a way of exchanging data between applications. We increased support for XML in Excel (for example, the SEC began requiring companies to release quarterly earnings in an XML format, making it easier to import into spreadsheets or databases for analysis). BillG was now actually excited about XML in Office11.

The Infopath team under RajeshJ’s leadership was one that appreciated that diversity of the team helped to build a better team and better products. Early in the product cycle the team made this video introducing members of the team.

Leading the effort to create a vision for XDocs was Judy Lew (JudyLew). Judy joined Microsoft about five years earlier out of the University of Michigan MBA program. She attended Columbia University as an undergraduate and her pace in words and action was more New York than her Utah upbringing. She was thoughtful, analytical, and persistent, traits which served the team well in pivoting to an entirely new product.

Her research identified a tool for companies to create forms—expense reports, invoices, surveys, and more. She envisioned enabling a much more elaborate experience and including programmable logic, data validation, and connectivity to other data sources to make it easier to fill out forms—a significant benefit, it could function without being connected to a network using offline email, which was a huge win at a time when getting online was incredibly difficult. Such a product could help in competing with Notes.

XDocs showcased SharePoint to share forms and store the results of the data collected. Competitively, IT developers were starting to use web browsers for many applications and were often seeing limitations of HTML compared to how these problems might have been solved with tools like Visual Basic.

To put XDocs in today’s context, it was designed to solve many of the problems solved by DocuSign today. Before web browsers were as capable as today, having a desktop application where the form to be signed and manipulated came together was a good idea. As it would turn out, leading customers were perfectly happy dealing with the limitations of browsers and HTML if it meant not deploying a desktop application. There was an extremely important lesson in there. The era of looking to solve new problems with a new Windows application was over. I was increasingly convinced of this fact. Not only was this an unpopular opinion inside the company, but the company strategy also assumed this was decidedly not the case. The problem for me was the Microsoft bubble with influential enterprise customers and the strategy bubble inside the company were protective enough that it would be years before the reality of our situation would be shared.

If having to outright cancel projects was rare, rarer still was the opportunity (or ability) to pull from the ashes of a cancelled project an entirely new product that, at least at the time seemed strategic and viable. The team, and the broader Office team, were excited by the work. Judy Lew’s efforts were remarkable as was the execution for the remainder of the team. It was not our best product (in fact, it was a failure in hindsight, the right problem to solve but the wrong technology approach) nor was it the most exciting to work on but going from a long trek of not shipping to creating a credible product so elegantly was a noteworthy accomplishment. The team left behind a consumer subscription product for email to build an enterprise business process tool using XML. They delivered and that was a huge accomplishment in this era—so many new ideas failed to gain escape velocity. As Brian said in his mail to the team announcing the changes, organizing in Office would be a huge opportunity to ship on time and to maximize the potential impact of the product.

InfoPath, the final product name, shipped with Office11 as a full-fledged module in a business SKU. It showed off a strategic new technology, XML, along with SharePoint and Outlook, and it helped to compete with Notes. It provided the kind of strategic demo of business value that the salesforce appreciated. It was the kind of product that Microsoft Press, Microsoft’s book publishing subsidiary, pursued aggressively resulting in a book even before the product released. I fondly recall stopping by Rajesh’s office when he showed me the book, beaming with pride.

InfoPath was bundled in an Office enterprise SKU. Doing so brought great distribution but made it difficult to realize the true value. As with Outlook, the desire to support the bundle was greater than any incentive or perceived opportunity to create a new business. JudyLew’s work clearly identified the revenue opportunity and specialized customers for this type of product. Reaching them, as is often the case, required an investment in new sales and marketing people and programs.

Sales and marketing did not share those views—their priorities there were to increase the perceived value of Office, particularly signing new and renewing enterprise agreements. XDocs had the beauty of being a high-end tool for IT while being useful to every desktop in an organization, which fit in well with the EA.

From my perspective, I faced another round of being on the hook to deliver organic innovation that expanded to new categories, only to see the work turned into incremental innovation to support the existing Office bundle. The pressure to drive upgrades was greater than the need for more organic growth, yet it was clear no one was going to upgrade for InfoPath more (or less) than for any other feature in the bundle. The difficulties in upgrading were unrelated to the value proposition of any part of the suite. The complexity of the overall platform of Windows and Office cemented a view that any change introduced upgrade friction. As we saw with browsers, if something interesting came along that was entirely new rather than simply an upgrade, customers were more than happy to consider adding to their standard deployment. We never got the chance to see if InfoPath was interesting enough to consider as a new addition to the enterprise platform. It was just more bloat.

I was disappointed that we chose to simply add more bloat to the perception of Office, as reviews would say, rather than strive for new business opportunities. The revenue for Office kept going up, either demonstrating I was wrong or perhaps proving that with the product-market fit we achieved for the core suite, nothing else we did could impact the suite business.

Still, this was difficult for me. Clearly, I was responsible for what ultimately transpired in the NetDocs to InfoPath transition, at least to the degree that I advocated for the only rational choice technically and in the context of EAs and the business. On the other hand, I was not the one who let the product go on for a couple of years nor was I the one who insisted on the demo at Forum 2000 (and numerous other demos to all sorts of industry people). NetDocs had enough external exposure that it was clearly perceived as a super cool product under development—at least based on that cool demo at Forum 2000 (why else demo it?). Would it have been better if it were permitted a slow burn over several years? I have my doubts, as the technology seeds that it contained were inside the Microsoft bubble, not where the industry was strongly heading. Instead of a Win32 app and proprietary XML, Office would double-down on browser-based tools starting in the next release of Office. Ultimately, the product just was neither different enough from everything going on nor did it take a radically different approach that could come from a new technology.

Thanks to me, I suppose, NetDocs was one of several products on every list of legendary Microsoft products that never made it to market. Much later, another one of those products caused me and the company a considerable amount of grief.

Stay tuned.

InfoPath was not the only new product in Office11…

On to 072. Notes on Tablet PC Innovation

Welcome to the only project I worked on that had the plans upended at the last minute after one executive meeting. This is a journey that starts back at the 1999 Company Meeting and the unveiling of “Software As A Service” bet the company strategy. With many excerpts and artifacts, we will go through planning Office.NET where you’ll really get to experience the product planning process in Office. Followed by a last minute change putting all that work at risk.

Back to 069. Mega-Scale, Mega-Complexity

In the fall of 1999 Microsoft held its annual Company Meeting at the old Kingdome (a stage was set up over second base). While most of the world was fixated on the rise of internet sites or more likely the looming Y2K crisis, both SteveB and BillG used their time to begin a transformation of Microsoft—the transformation to a software services company (this would later be called cloud computing). Few even in the industry knew what this meant. Pioneer Salesforce.com was just months old and the original cloud infrastructure company Loudcloud started by web browser pioneer Marc Andreessen and former Netscape executive Ben Horowitz was incorporated just a week before the Company Meeting. This was very early, but it was also very big. Even though Microsoft was at the peak of success and the most valuable company in the world, the company was going to be reinvented. It was powerful.

BillG spoke first. His opening was dramatic—a reinvention of the core mission statement for Microsoft—the title slide was “Changing the World of Software”. From the meeting transcript:

The vision statement that many of you have heard, year after year after year, we actually decided to change. That statement, a PC on every desk and in every home, running Microsoft software, is still true. It’s a great vision. It really drove the company for the twenty-four years that we’ve been in business. But in some ways it’s outdated. Not outdated because it’s wrong. But outdated because it’s not revolutionary. When you hear that statement today, you say yeah, of course, what else is new. PC’s are in sixty percent of U.S. homes already. The prices are coming down to a point where increased penetration is very, very easy to predict.

But Microsoft is a change agent. We’re not just about taking the software we’ve done and making it a little bit better. We’re about changing the platform. Taking the kind of risks we took when we bet the company on graphical interface or bet on a Windows NT. We’re embarking now as big a bet, or I would say, a bigger bet than any of those. It’s captured in this new vision statement. Empower people through great Microsoft, internally we say Microsoft, externally we just leave that as implicit thought, great Microsoft software, any time, any place and on any device.

Now when some people in the company heard that they thought is that all really that much different? Is it something completely new? And just in the last month, Steve and I with a lot of help, from other people, have come up with a way of taking this vision and explaining what it means to our software in a way that is quite revolutionary. And that is by saying that from 1975 to 1998 the whole vision centered around the PC. It said the PC is getting more powerful, there is more and more things people are doing with it, just get the applications on to that PC and we’ll continue to lead.

Well, now we’re saying that although the PC will continue to be important that it’s actually the capabilities that are delivered through the internet, the services across the Internet that people will be thinking about.. They won’t be thinking about managing their files on an individual machine. They’ll want all their information stored in the network in such ways that any device that they pick up, a PC, a phone, a TV, a small screen device, they have access to the information they care about. That takes storage of file system that was purely PC-centric and makes it much more internet-centric.

This was classic Bill. There was a bold statement. An assumption that the company was willing to take on huge risk. Embracing the success while saying we could do much better. Then pivoting to a very specific technical scenario, and no surprise it was data storage. He did this exact pivot when celebrating the Office XP launch with the team—great job, now about unified storage. There were demonstrations of web scalability on Windows, the new collaboration features in Exchange (including the Web Store discussed in previous sections). In something unusual for Bill, he ended his keynote by going through the newly created Microsoft Values, talking to Innovation, The Customer, Partners, Integrity, Diversity, Community, Entrepreneurial Culture, and People. A memo was authored describing these values, distributed to the company, and leaked to the local press (who often hung outside the Kingdome listening to the meeting anyway).

These ideas did not spring up for the meeting. A couple of years earlier Bill wrote a memo where the concept of a WinTone was put forth—something akin to a dial tone where your computer was always connected to a Microsoft server (actually called a MegaServer in the memo) where files would be stored and where PC updates could be distributed. Technically this sounded a good deal like a typical Unix workstation and was similar to ideas being espoused by Sun and NeXT.  By the time the Company meeting rolled around, these ideas had been much discussed and the Orwellian nature of them toned down. It is interesting to note that these perceptions would change dramatically, and the same ideas introduced today are not only typical, but expected.

SteveB came next. Going from Bill’s almost monotone delivery to Steve’s energy filled enthusiasm was always fun. Steve’s keynote was titled “The Power to Be Strong: The Wisdom To Be Wise”. Where Bill was describing what we should aspire to, Steve was providing the emotional call to action, the aircover to go and act on what Bill said, while also taking us through the detailed business reasoning. Steve came bounding on stage to some song that meant a lot to him that he carefully picked to get him in the perfect mood. Where Bill was measured and deliberate, diving deeply into technology, Steve pounded on “services”. He said the word almost 200 times in the keynote. The key slide was “Reinventing Microsoft: Software As A Service”. Like Bill he started off describing our success, though Steve was even more hardcore from a business perspective:

As Bill said, the PC is not new to the revolution anymore.  People wanted to know in some senses, what is it?  The PC has been it for us for twenty-five years, and we have exploited it, and we have built it, and we have designed it and we did it better than any company in the history of the world! One vision, one technology model, one revenue model, one partner model, and we just went, and we went, and we went, and we went after it!  And you know what?  Here is the good news, it’s still got some mileage left in it!  And I like that a lot.  But it doesn’t have as much mileage to come, perhaps as the mileage it has brought to us in the past.  And so when we talked about a new vision, people kept asking --but what is the new it?--  The PC has been it, and the PC will remain it, but what’s the new it?

I don’t really think people expected that at all. Here we were on top of the world and Steve was telling everyone the party was over. This was Steve and he was going to take us on the emotional journey and was working towards showing us all the opportunity that was ahead. Steve pitched the company on the why of both services and PCs (an echo to “software and services” that would follow). He explained that Applications Service Providers (ASPs) were the new developers to focus on. Then using the model, he was most comfortable with, he went through each Microsoft customer segment—enterprise, small business, consumer—and described the value proposition and how we would approach the opportunity. Who are the competitors and how would Microsoft compete? Steve had a list and made sure even in the face of regulation challenges, it was OK to compete vigorously. He even had a pro-forma P&L describing the way revenue would transition to services. Like Bill, Steve also concluded emphasizing the new company values.

It was a remarkable presentation and strategy. The presentation and details were the first draft what would become the months of meetings for the Next Generation Windows Services (NGWS) task force and presaged the Forum 2000 strategy day the following June. The 2000 wave of products (Windows, Office, Exchange, SharePoint, and many more) were announced at COMDEX just two months after the company meeting to over 340,000 people and created the product foundation for the company that would carry us forward as Steve described. These new products—the foundation of Microsoft for a decade—were positioned as old news before they even shipped. I loved it.

Unlike the internet strategy, especially the Internet Tidal Wave memo, this services strategy was ahead of the market. Microsoft was leading and no big company was heading there yet. It was, at best, a Silicon Valley startup strategy. When it came to services, Microsoft was incredibly early. Were we too early?

Windows and Office both created the XP products over the next 18-24 months while theoretically the new services infrastructure was built up. That wasn’t quite the plan, as really both teams were polishing/finishing the 2000 wave, but it worked out that way. There would be an absolute ton of meetings about Services over the next two years. The big project being worked on was Hailstorm, also known as .NET MyServices. The services topic and getting more done and sooner was top of mind.

In Office we had already spent a couple of years on SharePoint and FrontPage and were more than convinced that services were the future for us—so many of the scenarios described by Bill and Steve were easily enabled by using a browser, HTML, and a web server. It was abundantly clear that any remnants of the old way of working were in the rear-view mirror (file servers, “net use” to share files, directly connecting to databases from Win32 apps, having all your files on one PC, even obscure features like roaming settings and customizations were better suited to a web way of thinking).

We had many difficult balancing acts in front of us such as how much could work in a browser (very little in 2001) or who would buy services from us (we had no idea) or how much would a service cost (would it cost more or less than a box of Office). We had been talking for the whole of the XP product cycle about a mythical product “FrontPage.NET” (every next version product or code name had a .NET suffix by summer 2000) which would be an app-less app. Simply go to a web site and sign in and start creating a new web site. We’d seen self-service collaboration sites take off with SharePoint Team Services. I compiled a list of a dozen or more competitors who were making browser-based products for sharing and collaboration. No one was really doing anything significant for document creation, yet. Outlook was achieving a huge level of interest in the browser version being done by the Exchange team (so much we’d move that team to Office to better align Outlook in the browser and Outlook on the desktop). We were ready for services.

In the spring of 2001 after Office XP released with the rise of the new .NET developer platform inside of Microsoft, Office shifted its gears to deliver what BillG referred to in an earlier memo, Office as a Service. Customers loved the idea of infinite clip art, endless templates, ever-expanding online help, even sending Microsoft bug reports. We had so many more ideas.

As Steve and Bill set the stage to transform the company, it was my turn to transform the Office team. We had almost 2000 people on the Office team. That’s a huge management challenge, even with the air cover from the company meeting two years earlier. There’s only so much a few hours in a stadium can do. My job was where the strategy and words needed to start turning into code and product.

To get there as a team, we needed to scale our planning process. Our mantra for planning had become “the best of top-down, bottom-up, and middle-out”, but in truth we were far more tilted in the direction of middle-out, meaning gaining alignment across the various app and shared teams, and bottom-up where everyone contributed to feature ideation and prioritization. The top-down planning we did was around resource allocation and the big shifts to the suite and enterprise. The transition we’re talking about here needed a much more prescriptive top-down effort. Somehow, I needed to find a way to do so without being rejected out of hand or worse being called “too much like Windows”. Finding an enhanced way of planning that allowed for more senior management coordination and, yes, control, was hugely stressful.

I settled on a process of memos over a course of months that would lead to increasingly detailed priorities and ultimately an organization (aka a re-org) to execute on the plan. Along the way there would be countless 1:1s, skip-level 1:1s, group meeting presentations and Q&A, email threads, and hallway chats. Drafts were shared. Changes were made. The idea was that even the top-down was a product of bottom-up and middle-out. I admit that is an idealized view and some would disagree, but the goal and the work put in was intended to do that. At the very least we were running a version 1.0 process.

The process would take a bit more than 12 months from the first memo to the team meeting rolling out the vision (the plan), starting well before the current release even shipped. That seems like an insufferably long time in today’s environment. Aside from the obvious notion of “boxed” software versus an ever-changing service, there was a crucial difference with today. Office was a single product, with a single strategy, which would all be made available on the same day, spanning the work of some 2000 people each of whom would deliver their contribution on that day, complete and working. There are many enormous, far bigger, projects today, but they are rarely delivered in this manner. Even today Office itself no longer delivers products this way. Today, a single new feature in Office might roll out over the course of a year even in one module, and the same feature might come later in another part of Office (for example, dark mode). It isn’t just that the feature is released before it is done, but even after it is done there is a long tail of delivery.

In April 2000, 11 months before Office XP shipped, I sent out the first memo in the series, Next Generation Office, or NGO. Essentially on the heels of the Company Meeting and just before Forum 2000, I wanted to offer the Office analog to NGWS. The fact that this was just after the dot com bubble was important context. While the stock dropped precipitously, it was nothing compared to most of the tech world. The introduction set the stage for a big change:

Office is at a crossroads—we are on the brink of shocking changes in the technology priorities of our customers and are facing a substantial disconnect between our product and what customers want. For two releases customers have been telling us that they don’t have the need for upgrades and can’t imagine what else is left to do with Office. At the same time we have continued to innovate roughly along the same path started back in 1992 with Office 4.x—improving the basic document process. As we close upon the development of Office10, the signs are upon us that we are truly at the end of one era and at the start of another, and if we don’t act deliberately and precisely we run the very real risk of missing the transition. We have accomplished amazing things with Office, especially Office10. Over the years we have developed a product that is in daily use by perhaps 200 million people and each one of those customers gets tremendous value from our work.

It went on to describe what I called “The Big Bet” which was about developing an “internet user experience” for Office:

The Next Generation of Office is not just an incremental addition to our “client-side” code, nor is it about developing stand alone server applications, or isolated “free services” [This is a vague but pointed reference to the dot-com crash and all the companies doing free software and planning on making it up in volume]. The Next Generation of Office is about creating a compelling Internet User Experience built on top of the Next Generation Windows Services (NGWS, an early document from SteveB). NGO is a product that is the seamless integration of our client, our server software, and our services. When we speak of “Office as a service” we mean that Office is the combination of a Windows application (like the world knows and loves) plus a wide variety of hosted services (extrapolate from Office Update) plus a range of significant server software (such as OWS or mail boxes). Although we might also include some element of support or custom engineering, “consulting”, or other people-based services, our bet does not explicitly require that—we are a software company through and through. We will fail if we do not deliver on that powerful combination.

The memo paints a complete picture of the many challenges Office 2000 faced in the market. I referred to this as the innovation disconnect. The perceived cost to deploying, training, absorbing new features continued to rise, while the perceived value of those features declined. In other words, we were digging a deeper and deeper hole for ourselves by simply doing what we were doing by adding features. The bottom-line on this observation was a dramatic number I placed on what were termed traditional innovation, or features in the desktop apps, which was only 20% would go to “guarding the core enterprise agreement”. Such a statement proved to be enormously controversial with our team and as the marketing team (at the time they reported to me!) As we’ll see the controversy did not end there.

As I came to learn, in a big company (and especially Microsoft) when people read memos from executives there’s an ever-present expectation of a reorg. In Office our re-orgs had become routine and predictable. After a release we’d realign resources, shuffle the shared feature teams in Office proper, and make sure everyone had a chance to do something new or sit tight. It wasn’t stress-free, but it wasn’t a scary free for all. In reading NGO, many suspected a much bigger change. There was not. Instead, what we really needed was to create a whole new type of job. Our historic reliance of the magical trio of dev, test, and pm (software design engineering, software design in test, and program management) could not account for the important role of operations (the contemporary title of devops was a decade away). Part of writing this memo was to have guest speakers come to group manager meetings and to share industry practices from some of the hot startups. For example, Tim Brady, the first non-founding employee at Yahoo spoke about prioritization, keeping services running, and the like (I met him at a Harvard Business School event when I was there on sabbatical teaching). In many ways the biggest change in NGO would be creating not only an operations team, but an operations mindset.

The real purpose of NGO was not to provide answers to what the product was, but to tee up the questions or to frame how the release should look. In the next iteration we’d call the memo at this stage the framing memo, because it framed the release. It wasn’t nearly as prescriptive as BillG would have written because it was more of a management tool than a bulleted list of features that he tended to favor. In that sense, sending these memos up the chain was often frustrating for the recipients and a bunch of work for me. I had to learn how to use the memo to gather their feedback on the framing, not features.

Over the next months there would be any number of offsites and discussions about what should come next. Teams were using many new startup products out on the market, reading a great deal, and learning new technologies (like .NET). This enabled the next turn of the crank and many more specifics. Rather than putting forth a framing, the next memo said at a high level what we would build. It was still not features, but themes. I called it Creating Office.NET: Next Steps in Creating a Vision for Productivity. It was clear that the vision, the actual plan would follow, and this was not the plan. The goal, however, was to be something of a rough draft of the vision. The team would begin to fill in the details and thus own the actual plan. Again, this is solving for the lack of accountability that comes from simply telling people what to do. Plus, I had no idea what every feature should or could be.

This memo is about creating the next generation of Office.  Not a vision statement, this memo outlines the business situation and the clear direction we are taking the Office product, and the bets we are making (a vision statement will follow soon).  This memo is also about creating a new product—one that takes the enormous success of Office and melds it with new functionality and new technologies to create an exciting new product.  We will call this product Office.NET.  Office.NET is the essential set of tools and services that empower individuals to get their work done with a personal computer.

Without saying what the product did, the memo defined what success looked like. Again, this was either empowering or frustrating depending on the mindset of the reader. It is easy to lose sight of the work going on to change mindsets, not just accounting for what features to do. Office had almost no developers working on .NET, HTML, XML, and other new technologies. The memo continued:

• Customers move beyond the view that Office is “just” a word processor, spreadsheet, email client, graphics, web authoring, and database. Office.NET adds whole new services and applications to the toolset that we build and sell as Office.  Think of the service and services elements of Office.NET as “puzzle pieces.” When we release Office.NET people will use our product to get work done in new ways that they might not have thought of and certainly did not think of using Office.  Office.NET is not “Office 11.”• Customers not only use our new suite of hosted services but customers come to rely on Office.NET services as a critical element of getting their work done.  Office.NET services are not about gimmicks or “dumb PC/internet tricks” but about being simple, elegant, and useful additions to getting work done.  For customers, Office.NET is about saving hours, not mere seconds.• The glue that holds Office.NET together is integration and integration is what makes the value of our product greater than the sum of the pieces.  Customers using Office.NET see an unprecedented integration between their tasks—whether those tasks are Office.NET services, desktop productivity tasks, browser-based services, third-party services affiliated with Office.NET, or Microsoft’s own MSN services.  Integration is the key that allows a customer to solve real-life problems, such as sharing a document with a partner outside the firewall or merging a work calendar and a private calendar.  Many would say that one beauty of the internet is the elegance at which a large number of valuable tools interoperate saving time and effort—we will bring that elegance to Office.NET’s services.• Office.NET provides a new level of “customer service” by keeping the software updated, enriched, and “running” for customers.  No longer will customers feel like they are “cut off” from Microsoft after they buy the product or feel like they have to wait a year for a 30MB patch to fix things.  Of course, Office.NET doesn’t change this from the first day a customer gets the product, but we will over time build up the service relationship.  Customers no longer view buying Office as a one-time transaction, but rather customers subscribe to Office.NET because Microsoft is making a commitment to back our software and services with the highest level of support possible.• Customers who use Office.NET can do so with full faith and confidence that Office.NET provides a safe, secure, private, and reliable service. We will go to extremes to insure that customers can trust their important work to the tools and services offered by Microsoft. Everyday one hundred million people trust their work to Office, so we’re in a good position to extend this trust to a new level of support. This will not come easy, but we will make it so by making it the highest priority in everything we do.• Office.NET is good for business.  The great American philosopher, Steve Martin, once had a moment of enlightenment when he realized “it’s a profit game.”[OMG this should be “profit deal”  a mistake 20 years old.] For most of the history of Office, it has been more than good enough to maintain a clear focus on improving our engineering and building products that more often than not continued along the path of incremental improvement and that led to an amazing business. Office.NET is about building a new product and selling this product in new ways.  We are making these choices because everything we know says that they will be good for business—just as we thought building Windows applications was going to be good for business. We will run a service business with the same focus on efficiency and cost that we have had in building our packaged product business.

The text is rather self-explanatory today. It reads like common sense. At the time, each one of these points had controversies. Even the mundane such as providing software updates was broadly unacceptable to enterprise customers that wanted full control over what changed and when (and they still do). While writing the memo and talking (and talking) I could sense an increasing level of excitement. Bringing the excitement of the rise of the internet home to what we work on and how we work in Office was motivating. To put things in the era, many people were just starting to order books from Amazon and track stock quotes and news on Yahoo, though we were still 5 years from the rise of Cyber Monday.

Important to this memo was setting a bounding box around some important project attributes. This is the pure top-down aspect of the plan. This included setting time frames for the release, the number of milestones, system requirements, and more. The real deliverable (as with the operations team from the previous memo) are a set of carefully worded and coordinated “Focus Areas” which would be used by program management. These will anchor the process of feature ideation, prototypes, and scenarios. The memo outlined the following planning focus areas. These came with brief descriptions to answer the why, but were designed to ask the question how, not define the specifics of what we would do:

• Accessing My Information from Anywhere, Any Time • Creating a Personalized Office Experience• Building Effective Communities and Teams• Growing New Opportunities for Office• A Note About “Traditional” Features

The framing memo went out to the team in October 2000, about 5 months before most everyone was done with Office XP. A few weeks after that, the third memo in the series went out which was the adjustments to the organization. I like to remember this as relatively uneventful, though no org changes ever are for anyone who gets a new manager. In fact, the team had gotten so good at this re-shuffling after the release that it became somewhat of a game to go from the framing memo to the new org—clever people could guess the new shared teams or realignments that would happen from the way the focus areas were lined up and how the ideation progressed.

Program management created working teams based on these themes, and smaller groups based on specific scenarios. The features would emerge from these efforts—this is the bottom-up and middle-out planning work. PM led by HeikkiK drove this process, working across teams. If there is one magical step in all of Office, it was this particular part of our elaborate process that I came to value the most—we came to call it participatory design. It wasn’t just that features and scenarios seemed to emerge as if by magic, but the scale and alignment that came with those features. Anyone can (and did) have great lists of features they planned on doing. In Office when we published a list or specifications, we viewed them as team commitments. Heikki was coordinating a couple hundred PMs, designers, product planners, who in turn were partnering with developers to make sure that what was being talked about could get built. Everyone above mostly just watched. I’m not exaggerating. I will learn just how special this process was when I try to import it to Windows in a few years.

By May 2001 we had a full product vision—a product plan—for Office.NET. This whole time I had been sending the memos and talking with BillG and SteveB. In the middle of this process the executive VP leading Office changed from BobMu to JeffR and I walked through this process and all these memos with him. I realize now that must have been like sitting down and trying to untangle the true meaning behind the sales Mid-Year Review (MYR) process in a few meetings and by looking at 100 country and segment-specific slide decks. This oversight on my part will reveal itself shortly.

The pillars of Office.NET included:

* My Office

* Team And Corporate Productivity

* Keeping in Touch

* No-Brainer Upgrade

* Unlocking Information via XML

Phew. We were getting close.

A side note on the process described above is warranted. In talking about what we did I have always struggled to express the iterative nature of the ongoing work. Almost universally, the process is viewed through the artifacts (the memos) and that has the unintended effect of making the whole of the process seem like a traditional, and loathed, waterfall (as described in Chapter VII). When the process is illustrated in PowerPoint, I tended to use a lot of arrows to show off the constant state of iteration. The memos are not the work, they summarize the work. The work is best thought of as the communication, alignment, and learning constantly taking place.

The other concern often expressed by taking an artifact view is that there is so much planning time, or even dead time while people wait for the plans. In reality, the process came about to avoid any dead time at all. Many in PM are able to peel off while dev and test are finishing the product (in the above case a year before). From the end of Office XP until the vision is in place was only two months, and two more months until coding the project started. During even that four months, the engineering tooling is updated, the codebase is cleaned up (the removal of so-called technical debt), and because of Watson we initiated a mini-milestone devoted to addressing top issues. The waterfall versus agile debate would follow me around for many years, an irony for sure given the ability for the Office team to promise and deliver, compared to so much overpromising going on. I even created a slide that attempted to convey the iterative natures of the process and what we felt was unique. I used this slide for many years.

After a decade of offsites and memos about subscriptions and annuity, we finally worked our way to a product that could truly be offered as a subscription. Quoting from our vision, “Office.NET is a software service consisting of the best combination of software and services that provides a personal experience in creating, communicating and collaborating anywhere and anytime.”

The learning from the Office XP services emboldened us to embark on plans to host a broad set of productivity capabilities on the internet. We assumed if the MSN team could do it, then we could as well. We set out to define a new role on the team, on par with development, testing, program management, and design, called operations and led by Arthur de Haan (ArthurdH) as described months earlier in the original NGO memo. Arthur was leading the testing of enterprise cost of ownership shared team in Office and was one of Office’s most senior test leaders with many years on Excel previously and international. He brought with him a calm demeanor and the attention to detail required to grow a new job function for Office. He was eager to learn and the mental model of testing and operations were, we believed, a great match. We were all learning.

SharePoint Team Services anchored Office.NET. Every subscriber to Office received his or her own team site, much the same way IT enabled a self-service setup to create new sites on demand in our enterprise product (for a new project or something). We called this site My Office. From My Office, a subscriber received the features of SharePoint (a place to store documents, calendars, surveys, to-do lists, and more), all accessible from any web browser. In addition, subscribers could download Office (Word, Excel, and PowerPoint) and “activate” it with their subscription. Hotmail offered email. Imagine how cool it would be if files were stored in a website, available from any PC with a browser (if Office was needed it could be installed). In 2002, when we were dreaming this up, it was entirely workable but seemed like science fiction to customers.

We thought we were on top of these new challenges for the business and customers. We were naïve.

The first and marquee pillar of the vision was My Office, a home page for every Office customer available in a browser integrated all the information relevant to their Office experience (documents, mail, calendar, SharePoint lists, and more). From the start the intent was to support analogous features for enterprise customers installing and managing their own Windows Servers. Today we would say this is having both cloud and on-premises offerings. IT could set up SharePoint servers, could distribute Office via browsers, and, in addition, have much improved email with major improvements planned for Outlook. My Office was a gateway to all the communication and collaboration features in the product. The adoption of hosted services by enterprise customers was so early as to not even be in consideration yet.

The plan was great. We were days away from our all-hands vision meeting that HeikkiK owned. We created the vision document (all posted online), a one-page summary everyone received at the meeting, a mock press release, and design built elaborate full-motion demo scenarios to illustrate each of the main themes.

Throughout the process, I sent drafts of the documents and status updates to JeffR, BillG and others. I met 1:1, requested feedback, sent mail, and so on. JeffR told me that it was critical that we schedule a review meeting to again go through the vision with SteveB. This made me uncomfortable because I had already learned the difficulty of reviewing an entire product plan in one meeting. I watched Windows fail at this many times going all the way back to working for BillG as technical assistant. This was nothing like reviewing the goals of an entire subsidiary in 8 hours. It would be more like reviewing every account manager’s plan for their accounts and how it mapped to the subsidiary marketing plans and then to those goals—in 2 hours. Navigating a meeting of this scope—the work of 2000 people on a creative endeavor with a ton of unknowns that would be resolved over the next 18-24 months was, at least in my view, impossible.

While we were incredibly comfortable with our plan and the team was marching almost on autopilot, I wildly misunderstood my job description and accountability. We were planning this product since long before RTM of Office XP, with the elaborate process of memos and public milestones I discussed with JeffR 1:1. Reviewing a whole vision in one meeting at the end is an impossible task—the document was a work product of the team with nothing surprising by the time we rolled it out. Any changes this late, however, would be a surprise to the team. The empowerment that came with our participatory design process meant that management was not allowed to spring things on the team. Any big changes that the team did not participate in would be, um, poorly received.

Jeff and I took the shuttle over to SteveB’s office, the other big office next to BillG. Once the discussion got underway, I quickly realized this was not a casual check-in.

I began to run through the vision slide deck and the demos—the materials that would be used at the team meeting in just a few weeks. The first demo was My Office. There was enormous tension in the room. All I heard was, “We can’t do this product. . .it will put us out of business.” The rest of the meeting remains a cloudy memory.

I was perplexed. This was not simply a feature, but it was the core of Office.NET delivering Office as a service, as planned and described for months. It was just what both Bill and Steve described at the Company Meeting over 18 months ago. Our capabilities were not being doubted, rather it was the strategy. Was it a statement about subscriptions? Or was it a bet against SharePoint services? Did we not even want to do an internet user experience?

It was clear that a collective mind was made up, and perhaps had been long ago. The idea of offering internet-dependent Office was deemed simply too big a risk to the enterprise business. Essentially, they were concerned about what might happen if an individual started using this and then it was appealing to enterprises but not sold or supported by our enterprise sales force. It could even undermine Enterprise Agreement growth. It could cause customers to question the role of enterprise servers and cause troubles for the new and fast-growing Windows 2000 business.

I tried to craft answers explaining how I was certain that enterprises were not ready for this sort of service, and that our sales and marketing effort was aimed at small businesses and individuals—a long underserved market. The idea of internet hosting SharePoint offering downloadable Office was exactly what we had communicated earlier as a long-term goal for what was branded bCentral (an internet product for small businesses that included among other things email and communication), only adding productivity tools, Office code, and data center that could deliver that—done by the Office team as a core business bet, not a separate offering off to the side attempting to build new capabilities around Office rather than into it.

Could this moment have been avoided? I don’t think so. In hindsight, SteveB and JeffR were both focused on the enterprise sales motion—big accounts needing to close deals, enterprise thought leaders from Gartner, and most of all the field leaders. By their accounts, Office needed more “enterprise value” not what the IT industry had dubbed consumer services on the internet. And Office needed to reduce bloat. There was great love for the XML features, so more of that.

Should they have raised these points sooner? I incorrectly gauged their need to have more in person discussions. Their expectation from the field was that the process of planning and getting approval was a series of meetings. My expectations were based on writing (“writing is thinking”), and I found it ineffective to use a process that tried to agree on vast plans of thousands of people in person, with uneven engagement and unpredictable focus. My history, and that of BillG and MikeMap, was writing and communicating with strategy documents, detailed status reports, and transparency of process. But that wasn’t the field’s preferred method of engagement.

I failed to understand how much I was supposed to be managing up. This was my fault entirely.

At scale, a field organization is a much more top-down and prescriptive process than a product team. While a product team needs to scale execution (shipping quality code on time), defining what code to write is a different type of creativity than account planning or sales resource allocation. Field organizations tend to scale with HQ-centric strategy and planning teams that are there to work directly with executives—generally a clear separation between strategy and execution. Development organizations generally avoid distinct roles—those planning the strategy also execute it. As a result, there was a lot less bandwidth and interaction with management. We designed that into our organization, and it was appreciated.

In my case, it meant that I left a big gap in the way I managed the strategy up the organization, especially considering what they were used to.

As the meeting went on, I answered the concerns expressed, but I had mishandled the process. We would address bloat by not adding a bunch of features and keeping the core products the same. In other words, I unintentionally pointed out there would not be many new features in the core apps, except for enterprise capabilities (such as using the new-fangled XML technology). We intended to expand the value of Office with entirely new modules, one for pen and tablets and one for business processing and forms (a deeply enterprise scenario). The enterprise product was a superset of the Office.NET style product that would be deployed and operated by IT.

To be clear, I had said the enterprise product was the product. We were not selling a subscription, but we endeavored to beef up the free services offered with Office. I said the right words about the right priorities, and it was made clear that there was no subscription for Office that competed in the enterprise. But discussing that was not in the cards. Never had a product feature or strategy received a straight verboten before, so I left the meeting saying I was on top of it.

The vision for “Office.NET” reads well even today. In hindsight I should have seen this as a lesson in moving too soon or being early in May 2001.

Office.NET represents a major new vision for Office: integrating web services with the rich client to deliver unprecedented value to our customers. Office.NET also represents a major shift in how the product team approaches the Office product development cycle. Office.NET is not “the next version of Office.” It is an entirely new focus for Office where we will start fresh and extend our software into new and unexplored areas—software services. Office.NET will introduce a new business model, integrate with other strategic Microsoft technologies, and make much of the company-wide .NET vision real.

As of this writing, I still find the time the most puzzling few days in my career. I was too worried about the team and my constant fear of unraveling (as the Windows team was doing) to spend any effort on figuring out if there was a gap in understanding. I viewed this as an edict from above and executed as such.

I came back to the office and discussed these changes with Heikki. My state of mind was such that I did an exceptionally poor job of explaining what transpired. He was as puzzled as I was.

Since everything was essentially baked, we changed the body language of what we were doing. Where once again we started by planning the release not building the next Office, we ended up feeling incremental again. The step-function changes in the product—a subscription and internet offering—were scaled back, and our focus was back on IT and strategic enterprise value, to the exclusion of other work. Most everything we planned on doing as a hosted service we kept on doing, only as a server product using SharePoint. We would have many services as part of the core experience of the product (as previously described, such as templates, assistance materials, bug reporting, updates) and we would develop many new services along the way that would get us ready for a future.

For now, the snazzy sign up for a subscription with a credit card service was going to be the job of the bCentral team creating services exclusively on small business customers. Ironically this team, and its descendants, would spend the next 10 or more years working to scale SharePoint, Exchange, and various telephony products to work first in Microsoft hosted servers (essentially as an application service provider) first in a product called EHS, Exchange Hosted Services offering security and reliability services for a customer’s Exchange servers, and then a suite called BPOS, Business Productivity Online Service. By the end of 2008 there were about 500,000 mailboxes protected by EHS, with some big names driving a large set of those. Then by 2010 there were about 1,000 paying companies on BPOS with 2 million mailboxes (again, highly concentrated).

Therein lie the roots of today’s Office 365 offering Exchange and SharePoint services. The browser-based implementations of the Office apps would come with the next full release of Office.

Hindsight is super clear for this issue. The timeframe for enterprise customers to be ready for Office.NET was not early 2000’s. It would not even be 2010 or even 2015. Running essentially the same enterprise products but on Microsoft servers, the cloud as we call it today, would have in fact been insane in 2000. The killer application for the enterprise cloud was…simply scaling and running Exchange email for large customers. The product had become so complex and yet so mission critical that essentially only Microsoft could effectively operate it. It would take about a decade to build a product that customers would even begin to evaluate.

But in 2001 sitting in SteveB’s office, the enterprise was in no way ready for the cloud model—not even close. In fact they were uniformly against the model. That’s how early we were. Would it have put us out of business? Probably not as most customers would have ignored the offering and thought we were crazy. That’s how most felt even after 2010, and BPOS was essentially running dedicated servers for each customer. Steve was right, however, in that it would have been confusing to customers just as BPOS was in 2010.

The immediately visible change was that we re-codenamed the project Office11 instead of Office.NET. For the moment, at least the corporate branding people were relieved. We presented the vision, only finessing the idea that the design sketches needed to be representative of an enterprise aesthetic.

Office.NET as an internet experience for consumers was essentially dead.

Personally, this was a really tough few weeks in early 2001. Around the same time, Steve was pondering making changes to the Windows CE/Mobile group. He spoke to a lot of people as he always did. Among those, he spoke to me and two other good friends that were also “product leaders”. We also spoke to each other, that’s how we know we all had basically the same input on what to do. We were getting killed by the new Blackberry and our phones were nowhere near credible even though we’d been at it for almost 10 years. Unknowingly, we all said the same thing to Steve—we need to build our own phone and completely reset the operating system for that hardware. That was not the answer the company wanted then as we were totally committed to building out phones as we did the PC ecosystem. That meant no first party hardware and a software-only business selling the operating system to many phone makers. That also meant none of us would have been welcome additions to the team.

As a postmortem, I met up with one of my friends for dinner to talk about the situation and the state of the products, especially the phone situation we found ourselves in the middle of. I managed to inhale an entire slice of Metropolitan Grill 9-layer chocolate cake. Yeah, I was in a bad spot. I managed to inhale an entire slice of Metropolitan Grill 9-layer chocolate cake. Yeah, I was in a bad spot.

A few years earlier I had a wonderful and enriching sabbatical teaching on the east coast. I gave a lot of thought to the idea of switching gears. It didn’t get to the point of discussing it. I’m glad I kept quiet, but that didn’t make it any easier.

We had a slightly different product to build.

On to 071. Resolving NetDocs v. Office

Welcome to Chapter X!

The turn of a new century and survival of “Y2K” begins a massive expansion of the Office product line, a dramatic change in the products we built, and a reinvention of how we market Office, while simultaneously tripling and quadrupling down on enterprise customers. The result of this transformation sets the stage for the most formative years culturally for the Microsoft that takes us to today’s products (365, Azure), but unknowingly constrained us going forward.

Back to 068. The XP eXPerience

One early company meeting as the CFO Mike Brown (MikeBro) was going over the numbers he had a chart of the Fortune 500 showing that Microsoft finally made it into the rankings. He showed the top 5 companies or so, which dwarfed Microsoft then just barely in the top half. Sitting next to my first Microsoft friend KirkG, I recall asking him if he thought there would ever be a software company the size of AT&T or General Motors. His answer, “hell yes.”

Though Microsoft was number 84 by sales, it had achieved the unimaginable as the largest company by market capitalization. Thinking about that even today is still difficult to fathom—bigger than the oil companies, bigger than the entire auto industry, bigger than the phone company. It was obviously more than humbling. It was terrifying.

There was, nevertheless, a swagger across the company. Sure, the trial and settlement were still going on but the worst seemed over. There was such an incredible wave of success from the new enterprise business, both the licensing of enterprise agreements and the product offerings on the Windows/Office 2000 platform, along with Exchange and several other key products. For product people these were the magical product releases. There were “investments” as SteveB called them across every imaginable product category. The combination of Microsoft pivoting to internet technologies, the dot com crash, and simply winning against competitors is what I believe really caused a change in how we thought about ourselves, by rising to the moment and vanquishing competitors: Netscape, Sun, and Novel on servers, Apple on desktops, Borland on tools, Lotus on email, and so many other smaller companies. We saw success in everything we were doing. It became difficult even to find competitive products to get the team sincerely fired up. The biggest competitor was no one company but alliances such as anyone using Java or open source, but these were diffused and fragmented battles. Microsoft’s oxygen came from competing and winning and we’d sucked all the oxygen out of the market by winning so soundly. The market capitalization was a realization of that.

It would be a mistake to think success would not change how we built products. When you chase a competitor, even if you’ve got better ideas for how to express, implement, or sell a product as we did for Excel versus 1-2-3, the idea for the product in the first place came from the competitor. Microsoft didn’t invent from whole cloth many products. Most every product has a lineage of some form, so this is never an entirely fair way to judge. Most every successful product could be traced to a direct competitor with scale. On the other hand, many of our biggest failures were products that lacked a competitor where we would often get lost on a meandering journey trying to figure out what to even build. The Blackbird internet authoring tool previously described was a good example of this.

We had competitors of course, and some were spectacularly good. Oracle would forever remain the top SQL database company. Linux and open source were clearly a huge issue, but as should have been anticipated they would not win head-to-head but would only win when a paradigm shift—cloud and mobile—enabled them to flourish in business software. SAP and the whole space of software that ran the back office of enterprise and CRM software escaped us even with their deep connections to Office and email.

Increasingly Microsoft’s strategies became so daunting and all-encompassing it was nearly impossible to imagine a single competitor that could offer anything close to our strategy slides, and equally impossible for any single person to track. We were in a constant state of tuning the message and product line. Platforms lurched from Distributed interNet Architecture (DNA), to Next Generation Windows Services (NGWS), to .NET to .NET MyServices (aka Hailstorm), with stops along the way such as putting “+” on the name of every new endeavor, for example COM+, or adding XML to expand an existing strategy. At each iteration, everything was rebranded, expanded, and re-factored. An area like accessing data stored in a database cycled through acronyms representing increased capability and complexity, and varying compatibility and tools support: ODBC, OLEDB, DAO, ADO, ADO.NET, RDO, and more. The complexity of naming was only matched by the increasing complexity of software. The original Windows 3.0 APIs numbering about 350 had expanded to a literally uncountable breadth of platform services. No single developer could comprehend this. Definitely no one in Office and we began to feel distant from the very platform strategy we depended upon. Office had historically been the source of killer apps for platform strategies, but now the platform team looked to the biggest consumer web sites and largest commercial web applications as the desktop and client were deprioritized.

The evolution of the much beloved Visual Basic provided a lesson in this divergence. Office had just managed to add VB to all the products with solid performance, a major cross-company success. VB was in the process of being updated, really replaced, by a newly rearchitected product called Visual Basic .NET or VB.NET, which gained synergy with the .NET strategy and new iteration of the language for use on servers. This product was so different from the classic and wildly popular Visual Basic that one of Microsoft’s own and much-loved MVPs (the leaders in the community carefully selected to offer the best knowledge and support for products) dubbed the new product Visual Fred in an infamous blog post that rallied the community but divided it from Microsoft. Other posts began to meticulously track the differences in the new product and the time and effort required to migrate existing projects.

Office could not possibly retrofit this incompatible tool into the product—customers would have lost their minds as we had just completed migrating from the legacy programming languages—leaving the carefully crafted cross-group collaboration in somewhat of a Cold War. The VB team’s best response to the trade press asking about VB.NET was that we had “some difficult choices to make, as it's tough to move from the PC-centric computing model to the Web-centric .Net model.”

Were we losing touch or were we trying to do bigger and better things that would naturally and unfortunately alienate our best fans? Were we growing our ability to create strategic enterprise products or were we over-reaching on what we could (or even should) deliver? Was disruptive innovation happening in real time like it should, or were we just being disruptive?

Broadly, we began the decade far more inwardly focused than ever before. An expression that was often used was “smoking our own supply” or I might have said, “Microsoft was creating our own bubble”. Everything we did was relative to everything else we did which was relative to the feedback we got from the enterprise customers we already won who were champions for anything we did. I thought often about the very first technical conference I attended which happened to be the last global DECWorld on a cruise ship in Boston in 1987. Digital Equipment Corporation, DEC, was the famed makers of the VAX and VMS operating systems I used in college. I was a new graduate student and drove to Boston for the day.

The conference felt like the most grownup event I’d ever seen—everyone was twice my age. It seemed like everyone wore a suit and all they talked about was DEC. What I recall vividly, however, was that the sessions I went to were so advanced and so deep into the specifics of DEC and never mentioned anything else—in particular, I didn’t understand how they only talked about VMS and not Ultrix (DECs Unix variant) which was what we were moving to at UMass—I went to learn about Ultrix. I realize now both how naïve I was to the idea of an industry conference, but also how much of a bubble that conference was. Not long after, DEC began a rapid decline and about 10 years later was no longer a standalone company. It was no surprise that shortly after DEC collapsed the book DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital Equipment Corporation, was widely read across Microsoft. Being on top of the world in technology can be so fleeting and the descent so rapid, even if the products are loved—if only regulators could understand that point. BillG knew that. The competitive nature at the core of Microsoft existed for that reason. But what happens without a competitor? That’s how DEC acted—it built products as though there were no competitors, or more precisely that the customer saw the world only through DEC products.

A company that was on top of the world in 2000 was Sun Microsystems, but it was also starting to struggle post the dot com crash that impacted so many of their customers. There was no cloud computing, so starting a company meant buying a lot of Sun computers, but the crash stifled the creation of new companies and those purchases. Scott McNealy, the outspoken cofounder and CEO had said that people bought more Sun computers when the economy was good so they could grow and more when the economy was bad so they could be more efficient. He did not anticipate what Windows NT would do to those expensive computers though. McNealy never held back in his commentary on Microsoft. He reserved his harshest critiques for BillG or SteveB. McNealy’s rivalry with SteveB seemed a bit personal, perhaps because they attended rival private schools in the suburbs of Detroit. As Office XP was making its way to customers, McNealy unloaded on Office, taking aim at the ever-present topic of bloat when it came to, apparently, banning the use of Office at Sun.

Why did we ban it? Let me put it this way: If I want to tell my forty thousand employees to attack, the word “attack” in ASCII is forty-eight bits. As a Microsoft Word document, it’s 90,112 bits. Put that same word in a PowerPoint slide and it becomes 458,048 bits. That’s a pig through the python when you try to send it over the Net.

Nevertheless Sun continued to use Office in finance, presentations, and more. Sun was still a strong company, though that would change in due time, coincidently as their use of Office declined. McNealy held an influential position, particularly when it came to internet technologies. Like Microsoft, Linux also took its toll on Sun.

To bolster his anti-Office stance, in 1999 Sun acquired a maker of a clone of Microsoft Office, a German company, Star Division GmbH. The rumors were that it was cheaper to buy the company and attempt to standardize on its software than it was to buy Microsoft Office. Star Office was working to be fully compatible with Office and available on all platforms, especially Sun’s Java which had consistently shown that it was not up to the task.

The engineers on the product were adamant that it was a “perfect copy” of Office, copyrights, trademarks, and patents aside. At a trade show, when they were still an independent company, I saw a demonstration at their booth. I was younger then and not concerned about the ramifications of obscuring my badge and affiliation. The demonstrator said they were a member of the engineering team while describing the keen attention to cloning Microsoft Office, “even the toolbars”, they said. I pointed out some, um deficiencies. He launched Microsoft Office on their demo machine and shockingly I was correct. He summoned a coworker and after exchanging some thoughts in German told me to come back later in the day to see that they corrected the mistake. I came back and sure enough they did, and I properly introduced myself. Amazing.

With Sun’s ownership and financial support, Star moved from a low-priced product to a free and open-source product. In keeping with the apparent desire to needle SteveB as much as possible, McNealy and team created OpenOffice.org, a philanthropic-sounding consortium to support open source contributions and distributions of an Office competitor. What started off as an odd and failing strategy turned into an annoyance.

Highlighting Star Office as an alternative to Office was one way enterprise customers expressed increasing frustration with bloat. Depending on who you asked the products indeed had many flaws. What we began to consider was that we were now being evaluated on and held to an absolute scale. It was no longer enough to be better than a competitor we vanquished or a new competitor like Star. We needed to be great on our own, an absolute standard.

Despite the flaws, customers continued to buy, and continued to sign up for multiyear agreements. It was difficult to be a serious global company and not be using the full Microsoft platform for PCs, document creation, email, and enterprise infrastructure. Office and Windows were the very definition of product-market fit—we just could not lose a deal. Even in markets where software piracy was the norm, Office and Windows still won against free (and legal) alternatives. This created a disconnect that was difficult for product groups to fully grok.

Winning didn’t necessarily mean we had built the best product. Winning is a combination of product, price, place, and promotion and can come from any or all of them. At least for Word, Excel, and PowerPoint it wasn’t simply that our products were the most satisfactory sold by Microsoft, dominated industry reviews, and consistently won against competitors. Microsoft’s global sales force, product support, and complete product line were all part of a winning equation. Winning led to more winning when it came to familiarity, training, and cross-organization standards. Whatever products do win are by definition the best product.

Microsoft was a big place, and as we grew there were more and more people with ideas who were organizationally disconnected from execution. It was not difficult to find someone putting forth a proposition suggesting this or that risked ending a franchise: the browser, Java, open source, Linux, competitors using one or more of those, or customers rejecting Office due to bloat, poor quality, or complexity and cost in the enterprise. It was too easy to cast aspersions at the parts of Microsoft executing on what it takes to sell billions of dollars of software. These cross-group dynamics between the big money-making products and the new products or the groups simply incubating ideas with ample time to criticize introduced a new kind of tension in the company—one between those that were shipping and those that weren’t (yet).

In the world at large, Windows and Office were becoming listed resume skills and that enabled them to become the punchline to jokes on late night TV, sitcoms, and a constant stream of syndicated cartoons such as Dilbert. Earlier I described when late-night TV host Conan O’Brien did a funny number on Clippy. “Come on, Bill, Microsoft got off easy compared to what the government did to Clippy, that annoying icon that pops up in Word all the time.” (Followed by an animated gunshot and Clippy’s demise.)

We laughed—how could we not? Perhaps it was a rationalization to say that people always hated the tools foisted on them at work. I certainly remember how much people hated all the IBM mainframe software in use at my summer aerospace job and then the MS-DOS software used throughout Cornell. People loved the Mac, until it ate their file at midnight.

Our answer (and my answer) to all of this—the flaws, the increasing expectations, the late products, the quality issues, the jokes, and more—was to execute. Thinking back to that 1:1 when SteveB became president, ever present in my thoughts was what happens when a large development team loses focus and spins out of control. Considering how large our team had become with the addition of SharePoint, my concerns grew deeper. I had no idea just how real this concern was about to become.

As we were planning the follow-on to Office XP, the Windows team was starting to lose control after so carefully maintaining it. Windows XP shipped on August 24, 2001, within weeks of the original goal and six years after Windows 95, and then sketched out a grand vision for the next two releases. The first was code-named Longhorn after a bar in Canada between Blackcomb, which was the code name for the next release, and Whistler, the original code name for XP. Longhorn was planned to be a scaled back version of Blackcomb available sooner, which was being planned simultaneously as Windows traditionally did. Don’t worry, I couldn’t keep track either. There was so much excitement about the plans for Blackcomb that BillG kept pressing and the team was receptive to accelerating the long term work for Blackcomb into the near term Longhorn. It was typical to attempt this when planning two releases in parallel as the second release always appeared more exciting.

Nevertheless Longhorn was slated to be finished in a reasonable timeframe. Windows generally did not have specific completion dates as much as ranges though there were clear dates for early milestones. The release had a set of four strategic initiatives and grand long-term aspirations. These four initiatives were BillG’s self-declared main projects for the next 5 years (two releases) and included major advances in storage (code name WinFS), user interface platform and graphics (code name Avalon), networking (code name Indigo), and a major set of new developer APIs (code name WinFX). Longhorn would embody the biggest and broadest platform strategy ever attempted by Microsoft. I began to share copies of my favorite book on massive engineering, IBM's 360 and Early 370 Systems by Emerson Pugh, detailing the history of the biggest and most enduring computing platform ever built. Could we top that? I probably should have noted more of the history of the project that came before the 360, code-named Project Stretch, which went so poorly the project leader was ostracized within IBM (only to find redemption with the 360).

A really (really) big problem brewing was that Windows XP was struggling in the market, having received muted reviews it often proved difficult for enthusiasts to upgrade and required a significant uptick in PC hardware from OEMs. More alarming though, the virus and malware criminals and troublemakers that attacked Office moved their focus to Windows XP and Windows Server. Those products with significantly more surface area were under assault. The Windows team was scrambling to patch a relentless onslaught of bugs. There was ample consternation over the rationalization that the product was behaving as was intended while also deep concerns about breaking third-party software. If this challenge sounds familiar it is because it is exactly the situation Office was in years earlier.

Windows developed a plan to implement a fast-turnaround service pack that addressed the major holes in the product and to complete it in six to nine months. From my vantage point, having a 50 percent error rate on the estimated schedule completion of a short-term project was already a sign of a team that was not operating in control. The scope of the work, the resources, and the schedule were not aligned. The update to Windows XP was going to need more time, more people, and more work.

There was some good news in how the update progressed. Windows XP as it released was outfitted with Watson technology from Office. For the first time a Windows release was getting real-time information on crashes. The Office team continued to run the Watson service while Windows was able to isolate and fix a very large number of common crashes, as Office did while shipping Office XP.

Six months turned into twelve. Then more. More and more of the team, especially management, were being pulled into security challenges. An annoyance erupted into an existential threat to Windows. Even more importantly, the security issues threatened to prevent Microsoft’s .NET strategy from taking hold and earning product-market fit before even reaching the market. All around the world, the value proposition of only a browser and web pages with code on the server—the strategy espoused by Sun’s McNealy and Oracle’s Ellison—was looking more attractive. At stake was Microsoft’s reputation with enterprise customers.

A favorite saying in the Office hallways was that it is not enough for the leading product to drop the proverbial ball, but someone had to be there to pick it up and run with it. While there were many challenges in market with Windows XP, the real concern was that it was increasingly apparent that the network computer and browser were there to pick up the dropped ball.

There were endless debates over how far to go. I had a long email thread with a VP of Windows sharing my experience asking if “fixing” Windows was even possible? No matter how much was “broken” the architecture was fundamentally open and extensible and thus subject to ongoing assault. I had my doubts this problem was solvable based on my experience in Office. I would return to this topic in just a few years when I moved to Windows.

The definition of product-market fit ultimately prevailed—Windows was the winning product and the market could not get enough of it, even with security issues and incompatibilities. All Microsoft needed was to respond. The company needed to show it was taking the problem seriously.

Following the September 11, 2001 tragedy, Craig Mundie (CraigMu) led an effort to cement Microsoft’s response to security threats. CraigMu, from his position as chief research officer, went around the world representing Microsoft to governments, universities, and enterprise customers. He was deeply in touch with the public sector perception of products and the nature of the existential threat. Working with BillG, Craig and his team authored a memo called Trustworthy Computing (TwC), released in early 2002 and dictated a new set of priorities and new way to develop products. In addition, CraigMu further developed Microsoft’s Security and Response Center and led it to first-class citizenship in the world of cyber defense.

Often the press and outside world extend too much credit to BillG with something big like TwC. In this case, enough credit cannot go to Craig. He was early to this challenge and brought together the product groups and technologists in Washington, DC and around the world, academics, and other domain experts. He navigated these communities and found a way to frame the problem they were expressing so it could be addressed by the disparate organizations at Microsoft including engineering, sales, legal, product support, and more. Even the phrase trustworthy computing was no doubt influenced by the government commissioned report of that same name, which included participation from members of Microsoft Research and Craig’s advanced products group. Bridging the regulatory and technical gap became Craig’s specialty and proved enormously transformative for Microsoft.

TwC brought increased attention to cybersecurity as a boardroom issue for companies, beyond the damage done by viruses and malware. This was something existential to all companies and their customers, not just technology providers. Microsoft’s Executive Briefing Center added sessions on TwC which served to further entrench Microsoft as a thought-leader with enterprise customers. This was a significant turning point in the establishment of deep customer relationships.

The TwC memo also saw broad external distribution (and would be celebrated at decade milestones). Along with establishing the center, mandatory security training for engineers, and a host of commitments to enterprise customers, we also made security a first priority in everything we did. While many offered input and additions to the memo, I was always proud of pushing what I learned from responding to the Word and Outlook viruses. The January 2002 memo prioritized security over features as we did for Office years before—a strong signal to enterprise customers that we would be, essentially, making incompatible changes.

So now, when we face a choice between adding features and resolving security issues, we need to choose security. Our products should emphasize security right out of the box, and we must constantly refine and improve that security as threats evolve. A good example of this is the changes we made in Outlook to avoid e-mail-borne viruses. If we discover a risk that a feature could compromise someone’s privacy, that problem gets solved first. If there is any way we can better protect important data and minimize downtime, we should focus on this. These principles should apply at every stage of the development cycle of every kind of software we create, from operating systems and desktop applications to global Web services.

Message received. We were going to break a lot of stuff. Customers loved the TwC message, but the compatibility concerns would become a constant source of frustration for decades to follow.

Unfortunately executing the product changes to secure Windows XP turned into a 36-month journey (including an interim Service Pack 1), releasing Windows XP Service Pack 2, XP SP2, on August 24, 2004, three years after RTM and much longer than a quick turnaround. There were several major security incidents over the course of this, which either motivated more changes or slowed down releasing broad product changes, depending on perspective. When people say the regulatory climate distracted Microsoft and slowed execution, all I can think about is how much more responding to security did. While not everyone was working on compliance, every single group with code in Windows, Server, Office was making changes, fixing bugs, or investigating potentially risky areas to improve security of products while continuing to function correctly with the changes Windows was making. PC OEMs and independent hardware vendors (IHVs) contributed immensely by updating all the software installed on new PCs and required by hardware devices.

While the first couple of years were rather difficult with Windows XP, it emerged to become a deeply loved and fixture of a PC operating system. When I was working on Windows, we ended up extending official support for the product to nearly 13 years, three years longer than any other product.

Office was in a different place. We did not face the security challenges to the same degree but faced the needling of Scott McNealy, softening demand for new Office features, and high-friction upgrades from enterprise customers, and the ever-present risks of browser-computing.

More importantly, we were on the verge of understanding how Office could be a full participant in “services”. We began crafting our plans to finally deliver on those offsites from almost a decade ago where we were asked the question of how to turn software into an “annuity” business.

We faced the challenge of forging into new areas and doing new things. Everybody had ideas, which meant saying “no” became a big part of the process. But who would say no and to what and why?

On to 070. Office.NOT