050. The Team's Plan in the Face of Disruption

‘Personal Productivity’ is priority 6. –Me, in the Office9 ‘Vision’ document

With the looming threat of disruption, at least according to everyone at the company and the desire to get moving on adding new features to the apps, there was a need to have a strategy in place. Putting together a plan is never easy, and at Microsoft in the late 1990s you’d be challenged to find something that looks like a complete product plan combined with an execution plan. Starting from Basic for the Altair through DOS for the PC and even Windows itself, Microsoft asserted what a product was with little more than a meeting, some slides, or just an announcement or commitment. Execution often fared no better with even our best products, as we have seen, shipping a year or years later than expected. Even the Office apps individually, while having the best executed plans, had not yet combined that execution across the apps into a plan and execution for the suite.

What follows is the story behind my favorite process that we developed and honed over every product release that followed Office9 and ultimately Windows—affectionately called “the vision process”. It is also a real lesson in culture and how even with well-documented artifacts and tools, delivering and executing was really a product of the people.

Back to 049. Go Get This Rock

Leading the plans for Office9 placed me decidedly in the role of the incumbent in the context of “technology disruption,” as was being thrown around the hallways (or thrown at me). We were moving forward with a plan that was either going to work or prove to be one of the biggest cases of disruption ever, not to mention biggest mistakes ever made for an incredibly successful business on a huge upswing. Therein is the most counter-intuitive aspect of this plan—almost no one on the outside would think we needed to do anything to “save” Office, and everyone on the inside had wildly different theories on how we must save Office, all relying on nascent (at best) technologies.

I committed to create a document outlining the plans, a vision, for the whole Office9 product and my self-imposed deadline approached. The High Hopes offsite and memo turned out to be a draft, which was helpful. When I wrote the Priorities and Processes for Office9 that declared there would be a unified plan for the release I didn’t quite know what I had signed up to create. The offsite and accompanying memo were clarifying.

What We Are Doing Office9 will have three customer perspectives that represent the key customers for the product. 	End-users: Office9 delivers dramatic increases in individual productivity and ease of use for users doing creating the documents they need to create to get their jobs done. 	Administrators: Office9 delivers dramatic improvements in deployability, upgradability, and manageability of desktop productivity software. 	Developers and CIOs: Office9 provides components and tools needed to participate in web-standards based Enterprise application development.  Office9 seamlessly integrates with standards-based internets and intranets. OK, so that is all good and well and basically apple pie.  So the question is how are we going to be radical in how we approach transforming Office from legacy to internet.  This is a hard question and one that really caused me to write this memorandum in the first place. To reiterate, it is definitely easier to be critical or say more with regards to the Office9 plans, but it is pretty darn hard to come up with a complete and credible plan that is more radical than this, without throwing out some of the assumptions that we are making.  In particular, one is reminded that this is a plan to move Office forward, and not a plan to build some newfangled application that has all the magic of the internet associated with it.  Here are some of the assumptions and constraints that will go into Office9: 	Office9 has to ship in 1998. 	Office9 is a no-brainer upgrade from Office 97.  That is Office9 is zero-maintenance Office in terms of deployment. 	Office9 performs as well or better than Office 97 on the target hardware.  We will, for Office9, up our target hardware from an 8MB/486 to a 16MB/Pentium but we will be harder core about including mail and browsing in the benchmarking scenarios. 	Office9 reads and writes Office 97 data with 100% fidelity and in fact the Office 97 binary file format will remain unchanged for Office9. 	Office9 works just fine in an environment mixed between Office 97 and Office9. 	Office9 must not cause a corporation to pause and consider the ramifications for training users on Office9. 	Office9 cannot require an operating system upgrade (it must work on Win95 and NT 4.0). 	Office9 is a not a rewrite of Office 97. 	Office9 cannot have key internet functionality tied to our server strategy (Exchange, IIS, NT5), unless there is a way to gracefully degrade on other server platforms.  So if someone asks during a demo "does that work with my Sun server?" we can say "yes" with very few exceptions. 	Office9 cannot have key internet functionality tied to our client strategy; in particular we cannot use Office9 as a driver for upgrading to a new release of our own browser.   The last two points are not meant to inflame so please read on. These last two points do not preclude doing specific features that leverage our own client and server strategy, but we must recognize that the vast majority of our customers are not using our web server or web browser.  Our sales of Office, as demonstrated by the general environment and attitude, are very tenuous so the last thing we can afford to do is require a win in some systems/platform area before a sale for Office can be complete.  This is not a slam of our strategies nor is it the age-old argument about believing ship dates.  This is a realistic, customer-driven requirement. It is interesting to note that reliance on a specific service is a taboo in the world of the internet.  This is something that both Microsoft and Netscape (and Lotus/IBM) will need to address moving forward since it is clear this is the direction we are all heading (it is not even clear that there was ever the interoperable world that people claim there is). In looking at the above assumptions, it seems as though we are not being radical enough about our plans, since to some these assumptions look like things we should toss out.  If there are any that we should question then now is a good time.  It is no single one of these assumptions that has led to the current plans, but the sum of all of them.  Many of these assumptions are inter-related or imply other constraints.  For example, by forcing ourselves to hold the line on major reworking of the interface (to make it more web-like whatever that might mean) we are also meeting the need to reduce cost of ownership, since training is a major contributor to the cost-per-desktop of Office.  If we remove the constraint on the user-interface, we are likely going to fail at delivering a low cost-per-desktop release of Office.  So what are doing that is so radical?  We are embarking on new territory on the server, web-client, TCO, and programmability.  Here is a brief description of where we stand on these areas right now.  Over the next 8 weeks we will have much more solid plans (specs, schedules, etc.) for these areas.  We have been doing significant customer research on TCO and internets for the past three months so we are very up to date on customers. These descriptions are brief, as the process has just begun. There are already more ideas than we will be able to do so the real challenge will be in prioritizing what we already have.
From the High Hopes for Office9 memo introduced in the previous post, this is the draft of the plan for what we would be doing. I wanted to include this to show the iteration of the plan. Click to enlarge. (Source: Materials for Harvard Business case study on Office 2000)

The bet the product team made was on transforming us from a machinery adept at making new productivity features for individuals—IntelliSense, formatting, document creation and editing—to a new execution machine aimed at creating tools for a whole business. The cost of entering that market as a leader was to significantly improve deployment and manageability, or said another way reduce the total cost of ownership. The features we would aim for were not personal productivity features that saved minutes, but business features that saved teams hours and saved IT headaches and dollars.

In other words, the plan for the product—the vision—would completely upend the historic priorities for the product. This was a big change years in the making but faced with a single moment, the distribution of the plan to the complete team, to most the change would happen suddenly. While we were busy easing a group of 50 or so senior managers, the other 1500 people were mostly hearing rumors while they were busy working on their own team’s features. There’s no easy way to make a big change in a big company.

Office9 vision displaying in a vintage browser.
The Office9 Vision as viewed in a browser from the time. Note the final bullet points and ordering as discussed in the text. (Source: Materials for Harvard Business case study on Office 2000)

I took what I wrote for High Hopes, removed the defensive tone, and made it much more forward looking, focused on what we planned to deliver to customers, detailing the state of the business, and how we would work. It was an exciting document, if not a bit overly poetic as I’d not yet found a style for these. I wrote it using Word’s Internet Assistant and would eventually post it in HTML to our new http://officeweb running FrontPage sitting on a machine in my office. In 1997, almost nothing was written for an intranet website. The text was in the new sans serif Verdana font, blue with a muted yellow background, as I tried to make it look cool like a web page. It was rather unreadable and mostly unprintable, and with Office 97 copy/paste from the browser really did not work yet. We learned quite a bit from forcing ourselves to use web technologies in this way.

It is important to the process to understand that the past few months were spent in offsites and meetings, and a host of cross-team efforts, arriving at features that would be done by each app and the shared OPU team. High Hopes itself was a summary of what we had iterated on up until that point. This is the heart of what is meant by the Office process of “the best of top-down, bottom-up, middle-out.” The vision is not a news event when individuals see their own work and their features, but a chance to see what the rest of the hundreds of people will be up to. It is also a tool for the all-important process of adds/cuts—when each team (or feature team, the smaller unit of a team within an App team or OPU) figures out what they can really do with the resources they have.

This ongoing iteration within a decision-making framework is sometimes depicted as a funnel in consulting diagrams—lots of ideas come in and a process narrows them down. I think of it as a refinement with increasing levels of specificity. This refinement is also what leads to accountability. By the time the vision document is in the hands of the team, not only is it a reflection of the best efforts of the teams but it is also an execution plan, and it is also the accountabilities for the team. There’s a development schedule, at least the first cut, and a target ship date. The vision document itself is not a refinement but a summary of the refinement that has been happening all along.

That’s the view on paper. In practice, this first attempt would be a bit rough and contentious. The lessons learned would be super valuable the next time we went through this when the team would understand collectively that we were serious about the process. It is fair to say I brute-forced this first vision document through.

I wrote the vision on my own, circulating it for feedback first to OPU program managers and then to senior leaders and forging ahead without really considering the immense implications of what we were up to. Unfortunately, people reading the draft were reading for how it changed or affirmed what they already thought they were doing, not to learn what we were doing together. This was the first attempt at building a shared plan. While we were making progress, the Apps teams hardly surrendered their autonomy. The good news was that I captured most of what everyone was working on and laid the groundwork to unify the expression of why we were doing all that we were doing—that was the goal. The vision was a leading, but also lagging, indicator. The later steps of resource allocation would help to make sure the plan was executed as intended and agreed. This step, resource allocation, is what was almost always omitted in transforming a plan to execution.

The multitude of offsites and planning discussions paid off. Collectively, we were close to being on the same page, at least as close as could be for a team of senior managers who previously were working autonomously with OPU trying its best to be the glue across teams. The rest of the organization was starting to worry, something I heard in hallway grumbling.

Our team administrative assistant CollJ booked the big conference room, Kodiak Room, for March 15, 1999, for an all-hands meeting for the team including satellite/tape for Asia and Ireland where we had large teams. The last time we did this was for developer demo day when each independent app showed off features of Office 97. The night before the presentation I had an idea to make a cheat sheet or one-pager highlights. I quickly excerpted the 12-page vision document, choosing the goldenrod paper stock from the building 17 first floor copy room and made 1000 copies. I was there late in the night and most copies ended up crooked. I had to finish in a second copy room because the machine kept jamming. It makes me smile now to look at the crooked paper that remained on my cork board (adding subsequent cheat sheets each product cycle).

Office9 Cheat Sheet - scanned image
The “One-Pager” for Office9 featuring the Vision, Target Customers and Value Propositions and key project tenets. It is crooked. Click to enlarge. (Source: Personal Collection)

The vision began by stating that Office 4 through Office 97 changed the way people worked, but that was the past. A paradigm shift was underway (Microsoft, especially BillG, loved the word paradigm, in the Thomas Kuhn sense). This shift was toward the internet. Office9 declared itself to be “the best execution of an integrated suite of Internet-centric communication and productivity tools for creating, editing, sharing, synthesizing, and analyzing business information.”

This was my way of pushing back on the idea that the internet, by definition, implied new productivity tools. My point: The internet could make existing tools better and more relevant. The team liked this, or at least reacted positively to it, even if implications were unclear. Office9 declared Office 97 the end of an era of individual productivity and the start of a new one.

Later, I realized it was the beginning of the middle of the PC era, an era defined by expansion into business combined with a shift to enterprise features and sales motions.

An interesting note relative to disruption is that one response incumbents have to new technologies is to attempt to absorb them into an existing product, failing to recognize the substantial changes the new technology might ultimately imply. This was something I did not consider but thought a good deal about a decade later in Windows.

In order to outline the strategy shift, the vision explicitly stated the six priorities:

  • Migration, Administration, Deployment, and Management

  • HTML Document Creation

  • Outlook and Outlook + Application Integration

  • Web Collaboration and Solutions

  • Web-Based Corporate Reporting

  • Personal Productivity

Of note were the first and last. In the vision I used a bulleted list (HTML tag <UL>) and went back and forth myself over whether to number the items (HTML tag <OL>) to further emphasize the priority. As it would turn out, everyone mentally numbered the list anyway and I got the benefit of the full effect.

Migration, Administration, Deployment, and Management declared the most important thing we were doing—making Office a LORG product. Suddenly, the thing that was always last, always assigned to interns, always fixed as blockers in later product updates, was moved to the very first priority. The problem was that by talking about migration, administration, deployment, and management, I made Office9 seem like the dullest product ever. These features were always the last to get completed. The thought of doing this work as a first-class effort became an eye-roller. The vision called this the TAO of Office, or totally adminsterable [sic] Office.

HTML document editing was the second major area. Much of this work was already underway in the form of Internet Assistants for Word and PowerPoint. There were two controversial elements to this. First, Excel had done little by way of HTML and pushing an investment there would ultimately drive a great deal of effort on performance, rendering, and capacity in Internet Explorer (who loved web pages they could display but would crush Netscape). Second, we had not put much effort into ingesting HTML (versus outputting HTML). By developing the ability to open HTML files, as difficult and not particularly useful as that was, we laid the groundwork for using future HTML as a native file format (instead of our crazy binary formats that had caused us so much trouble in Office 97) and importantly for a format to interchange data between applications and the browser using copy/paste. This was the start of a multi-year, multi-product investment that would pay off immensely over a long period of time. The controversy around this choice will be explored in the next section.

In the past, the buyer and user of Office were the same person—the individual productivity user or the power-user/developer we called influential end-users. Apps previously segmented customers by end-users and influential end-users (power users, techies, were other names). Excel segmented bankers. Word segmented lawyers, and so on. Office needed to mature and build a product for segments the way we were selling software. The vision made a case for this level of importance by highlighting different customer segments and the value each would see from Office9.

For the first time, we declared that administrators and CIOs were users, not just buyers—they just wanted entirely different features. We also made a consistent appeal to developers, something we had done unevenly across the product.

The team understood this and making a case with the financials and sales of the company reinforced the new reality for the business. This information also reinforced the dominance of the suite in defining the product.

What turned out to be unacceptable was the last priority, personal productivity. Historically, personal productivity meant features customers liked and made the product easier to use and demonstrate. Anything and everything could be personal productivity since we made personal productivity tools. The personal productivity bucket consumed all development schedule hours and made the product appear as a long list of features to marketing, rather than any theme. That was old-school personal productivity, priority 1 (and beyond).

The plan constrained the definition of personal productivity to features that were unique to each app—features unique to spreadsheets or word processors, not general user experience or ease-of-use features. By allocating development resources to productivity features shared across Office and reducing app resources to focus on each app, the plan was to have a more coherent product to communicate to the market, and one that emphasized the suite nature. Most of the personal productivity features in Word and Excel in the past were similar ideas done differently, inconsistently. Office9 moved that work to OPU and away from Apps teams.

Immediately, program manager leaders across Apps threatened to quit, even raising the issue to BillG. It was not the reaction I expected. They felt disempowered and felt that I had kneecapped the apps. The need to build a suite for LORGs seemed like the obvious plan—to me. Also obvious to me was that Office 97 won. I was experiencing a reality of management: Everyone went along until something changed—they were in favor of change, and even change advocates, until the actual change.

It was one thing to declare the need to build a better LORG suite. It was quite another thing to choose to build one at the expense of other features.

Word, Excel, Outlook, Access, and PowerPoint believed that the battle to win in the category still raged. Outlook had been poorly received (and was now busy on their own interim release that would stretch out much longer than planned). PowerPoint was consistently viewed as the weak link. The general utility of the Access product, and our move to upsell Office Professional, which counted on demand for a database, was still too early to declare a success. Lotus and WordPerfect were rumored to be releasing Windows versions that transitioned their MS-DOS product leadership to Windows. From an app perspective, there were plenty of reasons to worry about losing category reviews, should there be any.

Winning in each of these categories, the PM leaders told me, required freedom to innovate in the base experience. There was no way for Excel to beat Lotus 1-2-3 unless they could build an experience tailored to the unique needs of spreadsheet users.

Repeat for each app.

We were right back to “Excel users are different.”

Independently, Excel was planning a unique user interface re-architecture that was “weblike.” This sounded crazy to me and was the exact opposite of an integrated suite. It was also something that had not been broadly shared or considered across the teams. I could not imagine how we could be a productivity suite if the flagship product, alone, had a new user interface just as we finished launching on the merits of consistency across the suite.

The two weeks from presenting the vision at the all-team meeting we were consumed almost entirely on defending Personal Productivity Is Priority 6, as it became known. My inbox was filled with subject lines like “#6,” “Priority 6,” or “Why such a low priority?”

What seemed easy, took a turn toward impossible.

To make the most difficult even more difficult, BillG appeared in my inbox. He asked me why Office was going have a plan that did not advance productivity and was not going to innovate in user interface. It was a direct shot at the plan even though he only knew a small piece of the story. He had heard from the Excel PM team.

Here I was again on the defense, though, logically, I was certain he was going to be okay with it. He knew the importance of the suite and LORGs, intellectually but not emotionally. Bill had not really faced a product team intentionally constraining a release up front. Of course, that is why so many things were late.

Once he read the vision, BillG switched from being concerned about the product to being concerned that all the smart people would leave the team if they weren’t allowed to innovate. I went from preventing productivity features from making it into the product to the manager who smart people did not want to work for. This felt personal and more of a character trait assault than a list of adjustable features.

This wasn’t the first time in my tenure as a manager and later an executive that I would defend the team that was in place over a single person leaving. One of Bill’s most enduring and appreciated traits was the loyalty he felt to those committed to Microsoft. This trait surfaced when someone telegraphed that they might potentially leave. In this case, Bill’s first reaction was to go to the manager assuming something was wrong in the environment that was causing this. Almost always, this was difficult to handle because the information was one-sided (regardless of how BillG found out) and the only thing a manager (me) could do was then talk about all the ways that the team was trying to move forward and how the disaffected person wasn’t on board.

I had been defensive in this case. It was early in my career (I was still leading OFFPM, which had grown to about 65 people). And BillG was concerned about any thought leaders (a great 1990s word) leaving. After some back and forth, however, he was supportive of the bigger picture. Despite all the changes in the vision and the demotion of personal productivity, the team was overwhelmingly in place as we planned and only one PM leader of about 15 bailed, and that had worked out best for everyone.

The rollout of the vision kept moving.

By spring of 1997 we still had two or more years of tight collaboration ahead of us, much tighter than with Office 97. We could not afford a misstep. We rephrased a section in the vision, tenets, that defined the cultural priorities for the release. We made them explicit in the vision document so we could refer to them later in the project:

All members of the Office9 team, regardless of the reporting structure, are responsible for the innovations in the Office9 product. By corollary, the shared feature teams are responsible for the integration of their work in each application.

Development and process efficiency is critical to the success of the Office9 schedule, and therefore it is better to do things the same way once rather than doing things in multiple places. This refers both to features and process. In other words, it is better to be the same rather than different.

We took this as a chance to create a new employee orientation for the Desktop Apps division. By instituting a small amount of informal training during new employee onboarding, we were able to show employees the vision document and detail the organization and priorities. Almost immediately, the vision document took on an even broader role than planned.

Office 9 TenetsWe are all responsible for Office 9It is better to be the same than differentFeaturesProcessesAll features must easily fit in the visionUpgrade/Migration scenario breaks all tiesNo gratuitous changes to UINo changes to native file formats Office 9 Tenets (Continued)Office 9 is openNavigator  3.0 gives great resultsInternet Explorer 4.0 gives better resultsAll server types supported via FP extensionsIIS/Active Server betterOffice 9 requires Win95 or NT 4.0Service pack level TBD
Some of the Office9 tenets from the vision presentation all hands team meeting. Tenets were a new process for the organization. Of note are the priorities for the team overall and also the commitment to openness for browsers (more on that in the next post). (Source: Materials for Harvard Business case study on Office 2000)

The vision even included specific tenets when it came to the product, schedule, and how we would manage the team. The goal was to have a set of non-negotiables across the App teams and OPU to effectively centralize what mattered. Even something simple like which non-English languages we would focus on (German and Japanese) was previously a big headache that we just decided up front. Similarly, we committed to the platform requirements for the release which included working on the new 3-year-old Windows 95 and also that we would make sure our HTML worked on Netscape Navigator, which was almost heretical (more on that in the next chapter).

Rolling out the vision for the first time to the entire team was stressful. There was the ever-present fear of leaks, leaving someone out by accident, typos, and oversights. Most importantly, the people who didn’t agree wouldn’t tell the sender (me) but would create negative vibe across the group. We saw some of this in the original 12/24 plan. People who didn’t agree stayed on the lookout for what wasn’t working and were right there to call this out. For Office9, we knew those who wished to prioritize apps would do the same. All of these were signs of an organization still finding its way from storming to norming.

Given how late Office 97 was, a significant concern was any doubt about the overall schedule. Those manifested as schedule chicken between apps, with each app betting they would just finish ahead of another, rather than working to be first.

The key to a robust schedule was buy-in from the test and dev managers. GrantG already harmonized the schedule across the test discipline, when he wasn’t personally testing the latest build or filing bugs. While there were differences in style, they really snapped to the same page under his leadership.

DuaneC rallied the dev managers behind the schedule. Duane’s style, much like JonDe’s, was quiet, understated, factual, and exceedingly straightforward. While directly managing nearly 100 engineers and having responsibility over the full team of over 350 engineers, he still managed to own code, fix bugs, and add features.

It all worked. Following the team meeting, the dev schedule was in motion. Code was being written. We officially started coding in May of 1997 (about 8 weeks after the vision meeting), with a beta scheduled for a year later after three milestones. We planned an RTM of July 1, 1998. There was a big risk to a summer RTM—another DAD rule of thumb along with not releasing on a Friday or before a holiday was avoiding an August RTM. If we missed it, there was a cascade (summer and global holidays that broke up the work calendar, followed by end-of-year) that almost automatically pushed us into the following year.

We were off.

One final note, the group program manager for PowerPoint, BrendanB, was so amused with the vision process and especially the cheat sheet that he went one step further and made a version I could hang from the rear-view mirror of my car along the lines of Repo Man (“there’s one in every car”). This became his tradition and I have a whole collection of these that I maintained on my cork board.

Leave a comment

On to 051. HTML: Opportunity, Disruption, or Wedge