082. Defying Conventional Wisdom to Finish Office

As we conclude the story of Office12 and the major redesign of the product, Microsoft of late 2005 to early 2006 is in a bit of a lull which for better or worse is good for the launch of Office. Longhorn continues to stretch out and the lack of clarity continues, which is putting a drag on everyone. There’s something very special, yet bittersweet, about this release of Office.

With the conclusion of this chapter, Hardcore Software, will start to get into Windows. I have about 30 stories planned. As my roles have changed so too have the stories. With Windows, we will see a lot more detail on organization, change management, strategy, and direct competition. If you are not a subscriber, please consider signing up. Audio will continue to be free and posts with all the graphics, artifacts, PDFs, and videos will be available to subscribers.

Back to 081. First Feedback and a Surprise

Nearly every country’s “Feedback to Corp” slide at the grueling field sales multiweek Mid-Year Reviews (MYRs) in January 2006 published the same bullet point:

🚩 Office “12” – Needs Classic Mode

What was this big, and clearly coordinated push for something called classic mode, and why now? We, of course, knew what it was but we did not know why this was happening now. It was very late in the schedule, post-beta testing. We were just months from scheduled completion as we just went through the final validation of the product—when the team is changing as few things as possible for the last few months, certainly not making any design changes.

A broad public beta went out to most enterprise customers as well as the technical press. More people enrolled in the beta than we expected or could even imagine. There was a great deal of interest in such a bold direction for Office.

As with the technical beta, the reactions came swiftly and clearly, often based on little more than the first few minutes with the product. Reactions from the press arrived in three waves—straightforward news of the release, first looks or reactions based on first experiences, and then, after a week or so, deeper dives into the product.

The first looks wrote themselves as we expected. Office12 was a sweeping change, and the obvious commentary or controversy questioned whether customers or the market were ready for it. Would it work? How difficult would it be to learn? Almost always the point of view of why the change was made was reflected, but the tone was skeptical. That was kind of annoying, but entirely expected.

For example, CNET’s Ina Fried who is always fair and balanced, said, “The radical revamp could help the company as it seeks to stave off competition from OpenOffice and others, but it also risks alienating those who like things the way they are.”

Computer Reseller News, the trade publication focused on small and medium business, went to great lengths to express concern. “While most users will welcome the additional features, Microsoft’s decision to teach its customers a new user interface for accessing commands and functions could be a risky proposition. Once the beta testers (and the bloggers) have registered their opinions, some Office 12 design points could be in for a course correction.”

A more detailed expression of concern came from CNET’s editors. “In the past, Microsoft has sabotaged itself by unrolling too many new features to Office too fast. We’re keeping a lookout for problems; after all, Office 12 was in its storyboard stages just a few months ago. If you’ve spent the past two years mastering Office 2003, prepare for a steep learning curve.”

These articles generated the MYR feedback. The enterprise account managers, essentially all our revenue except for Japan, were on the verge of freaking out. They saw the Ribbon as pure friction in the way of revenue and nothing less. They cited doubts expressed in the articles, reprinted in every language around the world, as evidence of deep concerns over the direction Office was taking. They did not want to spend energy selling Office where the assumption was we’d already won. They wanted to focus on selling the big server strategy, where we were losing to open source Linux and a host of smaller competitors. So why put up a barrier, they asked.

As if to highlight these enterprise customer concerns even more, in the spring of 2005 Office marketing rolled out worldwide a series of advertisements as a follow-on to the “Great Moments” campaign previously described. Attempting to inject humor into the extremely enterprise Office 2003 wave and to encourage customers to digitally enable knowledge workers, marketing developed a new advertising campaign affectionately called “Dinosaurs” though formally called “Evolve.” These ads featured humans in the office but with oversized, cartoonish dinosaur heads, implying those who have not yet embraced a digital workstyle including running Office 2003 were dinosaurs. In other words, we called nearly all our customers dinosaurs. At least the ads were popular in Japan, a market known to appreciate a good mascot, where the company distributed a large quantity of small plastic dinosaur heads.

Very quickly what felt like a magical release suddenly seemed to be worrisome to the sales force. That was not acceptable.

We obviously took on a significant risk in choosing a complete redesign of Office to address our “good enough” challenge. In hindsight sometimes I can hardly believe we did so. Now that we had 18 or more months of time to develop the product, we were genuinely confident.

Our previous attempts at addressing bloatware or the belief the product simply did too much each failed. These approaches were rooted in the conventional wisdom of different stakeholders:

* Reduce User Interface. From the earliest days of the product, the path to simplicity was to minimize the amount of interface visible on the screen. The conventional reaction to bloat was to proclaim less is more, as we often read about in reviews and analyst reports. We did our best to avoid removing features. Instead we twice tried a few design tricks, one was Intelligent Menus and the second was the technique of rafting toolbars.

* Office Lite. The business view looked at price points and wanted to meet good enough with a lower priced offering without upsetting the main revenue stream of course. The way to compete would be to have a stripped down, easy to use, easier to administer, lighter-weight version of Office, that cost less. We solved for this problem by changing the composition of SKUs to create lower price points, rather than chasing the low end as previously described.

* Customization. Customization was always the easy way out. If a customer or IT group didn’t like something in Office, they could just rearrange it. The tech enthusiast users and those early in the beta process said the would be fine with the Ribbon, so long as it enabled full customization by rearranging the tabs or contents of the interface. We addressed this with the customizable Quick Access Toolbar, complete keyboard support, and support for creating custom add-ins.

As we have seen, each conventional approach was fatally flawed and by and large amounted to half-steps to addressing the challenge of bloat or good enough.

Instead, Office12 would take the perceived liabilities of Office—the depth and breadth of features—and turn those into assets. The strategy was to make the product better by not just redesigning but reprogramming the user’s experience for a modern era.

Office12 could easily be viewed as taking the contrarian approach to conventional wisdom and feedback at each step. In early 2000s Microsoft, the idea of not “listening to customers” was decidedly counter-intuitive to put it nicely.

Most of our Office buyers were vocal and visible. Enterprise account managers regularly brought IT managers and executives to Redmond for briefings. Along with a direct line to SteveB, they were never far away, nor were their expressed concerns about products. As previously discussed, the growth areas of the Windows Server business hinged on directly listening to and acting on feedback from IT pro customers.

In the consumer business, Microsoft’s new online services were increasingly enamored with A/B testing and experimentation, substituting data for intuition (much more on that soon).

And here we were in Office being radical. To many it looked like we were either ignoring customers or not using data. We were just working the old way.

The MYR feedback added a new challenge. Customers, especially our prized enterprise customers, would simply demand we not ship the redesign at all. Even if we chose to there should be a way to easily revert to the previous design, at least for administrators.

Whether enterprise customers installed and tested the beta or not, this concern rapidly spread through the world of IT directly to our account managers. Budgets, dollars and headcount were reserved for back-end servers and data centers, for which we offered SharePoint and the full spectrum of Microsoft servers. In this environment, the resources that were allocated to PCs for individual knowledge workers were used almost entirely to keep PCs running, free of viruses and malware, and handle catastrophes such as breakdowns and stolen laptops. The budgets and resources for training materials, helpdesk, and even how-to courses all but vanished from the corporate world.

Given that context, any major change to Office was costly and unbudgeted. Even though customers were paying for years of Office, they had stopped factoring change into their IT budgets. For most in IT, Office was viewed as complete. Office was good enough. At the most extreme, a new version of Office would be fine if it added a few more menu items or commands, but mostly the best release of Office was one with no changes at all, but with better virus protection, reduced system requirements (Office already consumed the least amount of system resources of most anything running, even browsers), and even more administrative controls especially to turn off new features. Whatever lock-down we saw back in 1999 that first time visiting enterprise customers was now an ever-increasing new normal.

According to conventional wisdom among Microsoft followers, Classic Mode (CM) was the answer. CM was not part of Office12 and never was, but almost on cue the early punditry and enterprise teams assumed it would be in the product. The feedback or request was more of a Microsoft reflex. The term originated from Windows, referring to a switch or mode that flipped the new operating system to the look and feel of the old version. Windows had historically taken this to extremes. For example, in Windows 95 it was still entirely possible to run the old Program Manager and File Manager instead of using the new Start Menu and Explorer (in fact, those still run today on the 32-bit versions of Windows 11). Windows also included visual themes that emulated the old graphic design, which made the product look. . . old or comfortable. This provided a comfort for IT managers concerned about training. It was marketed as an option, but it was heavily documented in many deployment and IT-focused publications as an asset or even preferred way to use the product. Technically, CM meant Compatibility Mode in Windows, but it was referred to colloquially as Classic Mode because it referred to the old, and presumably loved version of Windows. These were thin veneers on very easy to use features, but customers were comforted by the gesture.

It was therefore entirely logical that these same IT managers (and the field sales managers) assumed Office12 came with a switch that turned Office12 into the standard or conventional user interface design—Classic Mode. Both Classic and Compatible are interesting word choices in that both imply the new product is less than a classic or not compatible.

The absence of classic mode was a surprise to, well, everyone including BillG and SteveB. While at one point super early on it was something we thought we might do, in hindsight, it was never more than a consideration with a placeholder specification.

Still, I had to be careful not to say that at MYR. I learned long ago not to drop hints or to be vague at MYR. My action item was dutifully recorded and in due time I would get back to the field staff with our plan.

We had so many reasons why CM was not possible let alone desirable. First and foremost, the requests for CM were based on the assumption that existing Office products were as easy to use as our marketing implied. While customers overwhelmingly associated ease of use with Office, in everyday usage, the product was complex, maddening, and fragile. Each day millions around the world had moments of dissatisfaction. The old products were familiar, but no one thought they were easy in any absolute sense. There was room for innovation to save untold hours of grief. No sane person would debate the maddening frustration that came at some point when using Office.

The user interface for a product that does as much as Office goes well beyond aesthetics. The design of Office 2003 was functional, and as a design the product was failing customers. Many people were squeaking by as long as they used the small set of capabilities they previously learned. And the tiny percentage of people who mastered the product would not credit design for their success, but rather their fortitude and investment in learning the product. A product designed for a single profession, like Adobe Photoshop or Autodesk AutoCAD, could remain mysterious to outside users because those in need learned it as part of their professional training. Office needed to be different. It was a tool used by hundreds of millions of people who learned with little to no formal training.

The goal of Office12 was to be more human and less computer. The design language for the PC era’s first two decades was primarily about utility and consistency—as in, making everything just function. We were at a point in time where we wanted to make the products work for people and to do so with a new sense of mastery and ease.

In early 2005, JensenH wrote The Office User Interface System, a document detailing the rationale and design for Office12. This document covered the motivations, problems being addressed, and the detailed philosophy behind each of the elements of the design. Even to this day, it amazes me that we had this document a year before release, and it still stands as an incredible accomplishment by the UEX team.

There was no looking back. CM was about looking back. As a practical matter, there were three major technical hurdles to classic mode.

First, there was literally no room left in the product. One could easily project out the future of Office as having hundreds of toolbars and task panes. Office would literally collapse in on itself into a giant black hole of buttons with little room left for content. The screenshots meant as jokes ten years ago were looking more like predictions or designs. Any new feature was like parking at the mall the day after Thanksgiving. Except instead of circling the parking lot in a car, program managers would be circling the hallways in search of an empty spot on a toolbar.

Second, and less obvious, was that the Ribbon design fostered a new and more modern interaction between user and features—live previews, extended text descriptions, galleries, contextual user interface, and high-level grouping of commands. New capabilities in Office were designed knowing they could be offered to users in this more modern experience. There was nowhere to do that in the old interface. That meant we would either not have those features or we would need to develop yet another mechanism to provide those new features in an old way, somehow.

Third, and most critically, everything we knew about customer behavior said that once a customer turned on CM, they would never turn it off. They would expect CM not just for Office12 but for every release after that. When one considers that Office is supposed to be compatible release over release, then it is obvious CM becomes part of a permanent compatibility story. CM would introduce a fork in the Office product where everything is done twice, once the new way and once the compatible way. An easy solution to this was to simply run the old release of Office forever. Microsoft had a way to make this possible as well.

The debate over CM, in my view, trivialized the design of the product. While I was of course extremely empathetic with the change that would be forced (as some would say) on to customers, I could not help but think back to the early days of the project. At the start we talked about all the places in life and technology that change. People are frustrated for a time then recover and move on. We were going through one of the greatest changes in the history of the world with the internet. Every internet site was constantly changing. Why did Office have to be static? Static equals dying.

Why were people so nervous about this change? I was puzzled for a while. Then I realized, almost no one in power positions in the industry had lived through a major change to Office. Since about 1990, or almost 15 years earlier, Office was unchanged. Office was a constant. It was as if no one ever expected Office to change. Almost no one recalled the early MS-DOS applications or the pre-Windows era. Most of our own development team only knew Windows or Macintosh. Out of almost 2,400 people on the Office product development team, only 58 of them even worked at Microsoft before Windows 3.1 shipped and only 7 were at Microsoft before Mac Excel shipped. Over 80% of the team joined since Windows 95 shipped. Even our own team never really lived through the graphical interface transition or the 8-bit to 16-bit transition, except while they were in grade school. Most were hired from college and the majority had much of their early computing experience on Macintosh. Our new hires during Office12 were the first generation of web-natives, having had the modern internet since high school.

JulieLar had a strong point of view on dealing with this, as someone who did live through the graphical transition as an early Macintosh app developer on PageMaker. She often noted, “When you believe in a design, go for it.” Some might interpret this as no compromise, but principled was a more appropriate way to put it. In many ways it was a new-to-Microsoft approach. The general manner Microsoft (and Office) approached change was to always support the old way, either with an option or to move on to a completely new product that solved the same problem differently, leaving the old product on the market. If you ever wondered why Microsoft had so many data access APIs or UI widgets or any other of a multiplicity of solutions for one problem, it is this latter approach. It is vastly easier to start from scratch than to reengineer something in place. The only problem is starting from scratch and creating a new product/technology rarely brought forward the myriad of tiny subtle details that existed in the original implementation. Complex products resulted from this approach. The products were either complex because everything had an option or alternate way to use it, or complex because multiple products claimed to solve the same problem but in non-overlapping ways. Teams often took the path easiest for their code base, defaulting to whatever had the least friction to adding new features.

It is worth noting how valuable customers found a high level, or perhaps perfect, level of compatibility. Today we joke about running Excel 2.2 on 32-bit Windows 10, but it does so 35 years later! Even early 1980s character mode MS-DOS applications continued to run through new Windows releases as late as 2010. This is decidedly different from compatibility at a user interface level. Whether one uses old Excel or old Multiplan, doing so doesn’t impact using Office 2003 or Adobe Photoshop as the compatibility is just bolted on the side. In the case of Office, the old features were intermixed with the new and that was an entirely different level of complexity, an unachievable level of complexity.

Because of this history, JulieLar and I wound up on the front lines, so to speak, engaging with hardcore fans over compatibility mode from the early days of beta testing. In the private MVP newsgroups, I once wrote a very long essay, almost, about why change is OK reinforcing the history and context of our industry, including that most customers had simply never seen any material change in Office (or Windows). I might not have convinced anyone at the time, but I did start to formulate the kind of arguments that would come in handy later in my journey. Quoting from the newsgroup post verbatim:

To believe that at any given time some technology is the the ultimate in productivity and nothing should change is of course absurd. While many people have a massive investment in analog recording of video and audio, few would argue that the change in technology is worth it if you want to stay a leader in the field. Photography magazines are filled with "move to digital discussions". There will always be a few people who remain convinced that the technology they invested in is the be all and end all of the field and that moving to a new technology is not perceived as being better, and in fact is worse. As with any technology shift, it is *never* 100% better -- digital audio does not sound as good to some people, digital photos are not as rich in quality or resolution as film, digital video looks different than film, etc. But new technologies have benefits that were not possible or not thought of at the time. So it is with the new user interface.

The idea that CM was a short-term fix crystalized our collective point of view for how wrong-headed such a capability was. If we learned one thing over the previous few years of Enterprise Agreements, it was that if customers were offered a way to freeze infrastructure, or avoid anything new, they would take it. Not only would they take it, but they would embrace it and stick with it. How did we know? Many customers continued to run Outlook 97 even though we had several new releases and they had no interest in touching email on the desktop or retraining users. Windows NT 4.0 was still a dominant server running many Exchange mail systems and it was released a decade earlier. In fact, the most critical initiative in the field was to upgrade NT 4.0 customers to Windows Server 2000 or later.

With the 10-year support lifecycle in place, CM would mean customers would assume they could run the new release the old way for another decade.

We had always tried to honor past products with immense levels of compatibility that went far beyond any of our competitors on the PC. The lessons from changing the file format in Office 97 were clear, but so were thousands of accommodations or compromises we made over the years. Now, however, the combination of Enterprise Agreements and the 10-year lifecycle proved to be a huge leverage point customers had with product groups. So much so that customers always assumed that any changes to a product would be optional. Their ideal new product release was one that was the old product, just faster and easier to deploy and manage, and the new features would be available on an as-wanted basis.

That was not our plan with Office12 and the Ribbon. Ever.

The Mid-Year Review (MYR) where we were swamped with compatibility mode requests provided the best evidence for the excitement surrounding Office12. Many countries used the new visualization features of Excel to enhance their revenue, budgets, market share, and expense numbers. Every grid of numbers used the new features to automatically color code red/yellow/green or included tiny sparklines for a great visual effect. This time I knew how to accept the MYR feedback gracefully by empathizing with a commitment to get back to the teams.

I must admit I already knew the answer. We decided at the earliest days of the project (May 2004 precisely). It would be a few months from then before anyone would even ask about it.

During the early demos of Office12 when BillG went from office to office to see a select set of features, one thing he mentioned to me that I wrote down was “classic mode”.  He wanted to hear why we didn’t show him CM. He thought doing so was “trivial” and was something we of course did, but maybe (as was almost always the case) we were going to add it later. He was prepared to make his case and we had to defend our choices. We had to do so knowing we had no backup plan. Any product changes would mean a product slip, but that was the least of the worries. Bill did not think in terms of product slips or schedules even, and often believed what he asked for would be easy to squeeze in. The scale of the projects was still something he was not entirely adjusted to.

JulieLar and her manager and leader of program management (and former leader of Office development) Antoine Leblond (Antoine) were the right people to go to follow up with BillG. In January, they walked him through the state of the design, how we would measure success, and what risks we saw. They answered his questions with the supporting data. They detailed specific scenarios that they repeatedly measured throughout the development process.

I wasn’t at the meeting, but they told me it went well. Julie shared one direct quote from BillG, later shared in a magazine story. At the end of the demo Bill said, “I can’t believe you convinced me to get rid of menus and toolbars.” It was also one of the last Office product meetings BillG would have as a full-time employee before he transitioned to part-time later in 2008. We were done talking about CM.

We hit Beta 2 and RTM only about 90 days off the original schedule of the two-year project. By our standards we became an execution engine, and with Office 2007, as it would be officially named, we also showed we could innovate in a big way.

There were many reviews, now many blogs, from the end of 2005 through 2006. Reviews focused on the major overhaul of the product as expected. Also as expected, each put the question out there asking if it would be too radical or too bold. Nearly every review was positive to glowing.

A smattering of reviews continued to complain about the lack of a bridge to ease into the Ribbon, compatibility mode, or a way to turn off the Ribbon, which they just assumed would be there. Of course, there were customers who told us they were not going to upgrade, but for any release only about one-third did anyway. That was another problem entirely, and all the Ribbon offered was a convenient excuse that went beyond budgets, IT strategy, something else.

Personally, this release was the confidence builder I needed after a challenging Office 2003. It felt great to build the hot or at least interesting and innovative product people were talking about. This came at a good time for Microsoft given the Longhorn chaos and the cloud over the company due to the regulatory settlement.

Anil Dash was early in popularizing blogging (today he would have been called an influencer). He authored a post I loved. It read, “Short and sweet, the Ribbon and new UI in Microsoft Office 2007 is **the ballsiest new feature in the history of computer software**.” [asterisks in the original]

He also captured the risk that we felt for the preceding two years:

Now, most of us who like to prognosticate and pontificate about software like to say things like “It’d be easy to just . . .” or “It’s trivial to add . . .” but the thing is, most of us aren’t betting our entire careers on the little tweaks and changes we’d like to make to our productivity applications. Try making a mistake that jeopardizes a business that makes $250 million a week.

But something else was on our collective minds.

What came after the Ribbon would not be more features in traditional desktop apps, but more internet scale services, more use of the browser and mobile, and more connections to data. We built the equivalent of the Cutty Sark, the best of wind-powered clipper ships. Steam-powered ships were coming, however, in the form of smartphones and mobile-cloud computing, as long-time industry analyst Benedict Evans would later write in an essay “The best is the last.”

The era of formatting documents was ending. The Ribbon was a new paradigm for desktop computing (what we called Win32 apps) in a world rapidly being overtaken by the web.

We were also approaching the end of an era of software reviews. We could sense that as we went out on press tours. There would not be another release where a magazine would devote dozens of printed pages to Office, or Barnes & Noble would have a shelf of Office books. One review mattered above all for me personally and that was by Walt Mossberg at The Wall Street Journal. It wasn’t just that he was the most influential reviewer, though he arguably was. Others would review every feature and have dozens of screenshots. Walt spoke for the typical customers, the non-techie, the person who just needed to get work done without futzing. Winning that review meant winning over that customer, at least by proxy.

No one expects a perfectly glowing review of any product from Walt because he makes a point of raising concerns that normal people will have from learning, to new file formats, and even the pricing. That said the headline alone was huge for us and it was a big enough deal that the WSJ placed it on the front of the business section with color screenshots— “Bold Redesign Improves Office 2007.” There was that word, bold, just like we aimed for at the start of the release. He went on to write:

So, when Microsoft makes significant changes to Office, it's a big deal. And the latest version of the software suite, called Office 2007, due out Jan. 30, is a radical revision, the most dramatic overhaul in a decade or more.

I don't use the word "radical" lightly. The entire user interface, the way you do things in these familiar old programs, has been thrown out and replaced with something new. In Word, Excel and PowerPoint, all of the menus are gone -- every one. None of the familiar toolbars have survived, either. In their place is a wide, tabbed band of icons at the top of the screen called the Ribbon. And there is no option to go back to the classic interface.

. . .

If you'd like to get more out of Office, especially in the area of how your documents look, Office 2007 is a big step forward and worth the steep learning curve it imposes.

Of course, I personally fixated on the places he was critical. For the team this was a huge, huge, win.

While we gave new life to Office with the redesign and we created a foundation to continue to evolve the product incrementally, the next wave of innovations would (and should) be entirely different products. We disrupted ourselves. We made the previous releases of Office look old and underpowered. OpenOffice would continue to chase the old design, and the soon to be released Google Docs would do the same.

The world was changing though, and we knew it. It wasn’t just the reviews going away or the rise of the web for consumption. In November 2005, just before the MYR process detailed in this section, I wrote the framing memo as I always did for what would be called Office14 (yes, we skipped Office13 though I was careful to note that 13 is unlucky only in some cultures). In Aligning for Office14, I described five “Big Bets”:

The big bets we will explore as we begin aligning the team for Office14 include:

* Moving Up the Value Stack

* Office Web Companions

* Internet (Web-Based) Services

* Building on Windows Live

* Office's Enterprise Content Management Platform

The first bet was about enterprise computing, as it should be. My heart was in the second bet, which was to build Office for the browser. I received immense pushback for suggesting such heresy. Often people used against me my own argument from years ago that the browser wouldn’t work for “real productivity.” The trajectory we were on was now clear and the time to start was now.

To ease people into the idea, I positioned (so cleverly, I believed) the idea of building Office for the browser as “companions” to Office and called them OWC, the Office Web Companions. As companions versus competitors or replacements they would not risk cannibalizing the real Office. The other challenge within Microsoft was the view that corporations would be running a Microsoft-centric “browser-based” platform using much more capable technologies that relied on proprietary Windows Server and Windows Longhorn such as successors to ActiveX. The broad consumer world would be running “web-based” solutions in a least-common denominator browser (a phrase always used when referring to HTML.) It was a subtle difference in wording with huge implications strategically. So I danced around both as I wrote and then evangelized the memo.

I was very excited to build on our 1990s strategies of embracing the web with HTML and then Office Web Server. I was already dreading what was sure to be a significant uphill battle across the company, not unlike what we had faced in building Office 2007 or using HTML or creating SharePoint. The company had a strategy and these bets seemed to run counter to it, but only at first glance. I thought a good deal about how Windows rose out of what was often branded internally as a side project, operating environment, or experiment.

It was going to be a journey to disrupt the desktop applications, but we needed to start.

My direct reports and our significant others gathered for a dinner at Assaggio Ristorante in Seattle to celebrate the final beta release. I hardly ever asked people on the team to do things outside of work hours, but this release was so special.

Months earlier in just a hallway conversation, Richard Wolf (RWolf), manager of PowerPoint and Visio, said that it was cool that the “last” release of Office was the one with a major UI redesign—it was almost poetic for him to say. Richard was the productivity philosopher among us, having worked at Lotus before Microsoft, a reflective person, and an early member of the academic community focused on productivity. He was right. There was no reason to think there would ever be another major redesign of Office that was necessary.

Innovation is like that. Microsoft was built on the idea of creating, grinding out improvements, then moving to a new platform to innovate. We were at that point. Everyone could see it. It was as if we each felt it in our own way. We had accomplished what we set out to do a decade and six major releases earlier.

We shared a toast (of a beverage of choice) to what the team accomplished. We were proud. And we were happy. We built the very best version of Office—a reinvention of the product—in a way that had never been done.

For most of the seasoned leadership team at this dinner, this was going to be their last release of Office. I think we each knew that.

Things were about to change for me too. As happy as it was at the time, it was also a bit sad. There was always a bit of a low after shipping. The grind of building suddenly stops. A sense of mission accomplished takes over. Also, I just turned 40.

Unbeknownst to me at the time, this would be my last release of Office. Something I never even considered.

That Office14 memo was my last work on Office.

On to 083. Living the Odd-Even Curse [Ch. XII]

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com