049. Go Get This Rock
“Execs don’t think Office9 is exciting enough or soon enough.” JonDe to me, late 1996
The most difficult thing to do in a big company is change a core belief. Microsoft was going through a late 1990s change, and rather unevenly. We were moving from a company primarily or almost exclusively selling products to consumers to one selling to IT professionals. The unevenness was seen in customer engagement, product roadmaps, release dates, and cross-company strategic alignment. It was also seen in how various executives perceived each team, and importantly how Office was viewed now that our management chain at the executive level was rooted, for the first time, in Platforms history and not Office history. This transition to an enterprise company was happening in parallel with every major product quickly embracing (and extending) the Internet. Across the company a new book, The Innovator’s Dilemma, became ever-present in conversations, debates, and characterizations.
Back to 048. Pizza for 20 Million People
Please consider subscribing
Planning Office9 was going to be difficult because it was the first time we would plan a release from the start as a suite. We soon realized most other groups thought Office was being disrupted by the Internet (disrupted, as I will explain was all the rage in business jargon). To address this challenge, or I should say inevitability, Office needed to navigate external competitive forces and internal strategies that conflicted with each other, even before taking into account what Office might do for customers strategically or technically.
Windows existed in a parallel world where the Windows 95 consumer code base was almost entirely engrossed by the Internet, while the NT code base designed for business and IT was working to add a modern graphical interface and then build up compatibility with the consumer ecosystem (a project that would take three releases and 6 years.)
The server products such as Exchange and SQL were built around IT as the buyer and the user, which led to a world view exclusively about the enterprise, where embracing internet technologies had a less urgent need. Windows Server, the core platform product, had a clear mandate to be a great WWW server, building on the early work of Internet Information Server which was itself in a bare-knuckle competitive race with both Netscape and the open source Apache web server, both of those primarily running on Unix and increasingly Linux.
Office 97 finished the last consumer release and as a team we were in the process of figuring out how to focus on enterprise customers, while also recognizing that our buyer was IT, but our user remained the individual or workgroup. Our internet plans were based on what we had started years earlier, apart from Outlook which was in the process of its sudden embrace of internet protocols resulting in the off-cycle release separate from the Office suite. Nevertheless, in many markets Office was going to remain a consumer or retail business for some time to come, especially Japan which was approaching half of our business.
With the organization above me in flux and the executive overseeing the Office organization during Office 97 changing a couple of times, I discovered that sometimes there was opportunity in chaos. During this time, I experienced my own evolution as a leader, learning to be focused on the team and getting the product built, while stuff above me just sort of happened. I began planning the release in my role as program management leader for the Office Product Unit (OPU) but finished the release as the General Manager and then VP for the entire Office suite, though the team experienced none of the “big reorg” issues. My manager was JonDe for the entire release as he endured the changes above him, and diligently worked to minimize the impact of the chaos on the Office team. There’s no way we would have finished Office9 without that support.
As a program management team, we held offsites for several months prior to Office 97 shipping. I scheduled one to kick off the process of buy-in from upper management. I structured it in the way I believed the Platforms culture (our new executive leadership) preferred, which was a series of slide decks presented by area experts with interaction and discussion including a deliberate description of architecture. This differed from how Office usually handled offsites. I saw these cultural differences in working across teams and as BillG’s technical assistant and knew how important it was to have discussions culturally in sync, even if I did not always do a good job myself.
The plan was to have BradSi (now JonDe’s manager and Senior Vice President Applications & Internet Client Group) and PaulMa (Brad’s manager and Group Vice President of the new Platforms & Applications Group, which was everything but MSN) attend, as well as my manager, JonDe, and his reports, plus the group program managers (the product leaders across Office and also several teams from Windows and across Platforms) and of course marketing.
But then a wrench was thrown into the planning. JonDe told me the Office9 plans were creating angst among execs. This was a bit puzzling and somewhat scary because the plans were not known broadly. Actually we didn’t have any plans at all and the product hadn’t even officially started the schedule yet. How could they already be concerned and about what?
In JonDe’s office on the third floor in building 17 we grumbled about the challenge of Office being managed by Systems execs. We felt similar to a couple of years earlier sitting together in that very same office pondering the idea that the Apps teams said we in Office lost our marbles, before we finished the successful (but late) Office 97 product. This was different though because, as Jon relayed, Office9 wasn’t exciting enough or soon enough so it seemed. We were told the “rest of Microsoft” felt like Office didn’t get the internet and was not embracing the future—it was those kinds of vague assertions that made their way to us. I felt certain that I had credibility when it came to internet religion. What could such feelings about the team be based upon?
There were forces at work, or, more aptly worded, criticisms of Office based on nascent technologies that might prove competitive. Innovator’s Dilemma, the seminal 1997 book by Harvard Business School’s Clayton Christensen, was fresh off the presses and like every large company facing the internet, the book’s lessons were immediately extrapolated to the strategic challenges posed by the internet. The original article upon which the book was based, “Catching the Wave”, was widely distributed among teams at Microsoft. The book was not without controversy when it released and increasingly so as time passed. The disruptive force, as it related to Office, was the internet and what it brought to productivity and document creation. Unlike the concrete examples in the book (such as the switch to 3.5” hard drives from 5.25” ones) there was no lower-priced, less-functioning product competing with Office…yet. Office did not understand the internet, so our bosses seemed to suggest. I had, apparently, lost my marbles. Every discussion would somehow come back to the new and ever-present theory of disruption, though everyone seemed to have a different interpretation of the book.
Yet, there we were facing our own management team. In the context of planning Office9, we were being told Office was being disrupted. It was not a question if or when, it was happening right now.
In the Systems way of developing a strategy, problems were generally distilled down to specific technologies or architectures that would be used to out-architect Microsoft. The conversation almost always started from the technology end-state and from that basis one countered. Communication challenges would arise when the discussion turned to or started from scenarios or customer perspectives. Disruption facing Office was not a specific product, but the way future products were being built or contemplating being built. Somewhat like Christiansen’s steel mini-mills, Office faced a technology challenge.
Our technology approach was customer focused, not technology focused. Still thinking from a customer perspective did not preclude technology. Rather, we faced the belief that technology defined the starting point and context for the conversation, not the end point in solving customer or market problems. It should be no surprise, but technology driven is what makes sense for much of an operating system. This different focus is not a problem, rather it is why Microsoft had two wildly successful businesses. Even to this day there remains a nuance to this heated topic. Every company, especially mature and successful ones, claim to first and foremost listen to customers. Whereas every new startup is almost always highly technology driven. As we will see, Office was and remained customer focused while making significant and seemingly anti-customer bets on major technologies. Systems would continue to be primarily technology focused which both served it well and also created challenges within the team and for Office.
There were numerous technologies in play that were, as we came to say, poised to disrupt Office. Key among them were the browser, network computers, Java, and components. This might all sound like jargon or at some level interchangeable buzzwords of the era—and to those who know the jargon these might not sound like particularly discrete choices—but the importance of having a strategy discussion based on these technologies was key. Each one of these technologies was deeply important to a different part of the overall product organization. Each was viewed as the most important competitor for at least one part of the company.
As I discuss these, it is important to consider that the technologies while related were at an important level mutually exclusive—we could only build Office once and had to pick one technology approach to build the product. Office was being disrupted, but by which one of these? It also meant we were by definition currently building Office on the wrong technology for the internet—could it be that using Windows was wrong, in 1997? The problem was not just that we were wrong at the start, but we would have to pick one approach from several and in the process we would still be wrong for some executives and their view of disruption. How would we possibly align? Importantly, every division wanted Office to align with and validate its strategy.
Windows and equally about the bets we did not make. We took this responsibility very seriously. Even small things like what version of Windows was required by Office were galactically important—the teams building new versions of Windows wanted us to require the latest version because doing so drove new PC sales through PC makers with a one-two punch of a new Windows and new Office together. The newly powerful enterprise sales teams wanted Office to run on the existing OS and installed base of PCs.
At any given moment, about 30% of our customers were on the one before the previous version of Office (in this case Windows 3.1 and Office 4), 30% on the previous one (Windows and Office 95), and then in about 2 years the rest would be on Office 97 (probably with Windows 98 and a little bit of Windows NT in the enterprise), just in time for Office9. Repeat this for every new technology and you can start to see how difficult it became to release new capabilities that required a new OS, a new PC, and a new version of Windows. We were already stuck and didn’t even realize it.
First among technology equals was the browser. There were advocates that believed productivity tools like Office hosted in the browser were imminent and Office’s days running on Windows were numbered. In early 1997, HTML was made up of a collection of about 20 formatting elements and the programming language JavaScript that was about 18 months old, both experienced over 56k dial-up connections for most people. Internet Explorer supported both JavaScript and of course Microsoft’s own VBScript. Microsoft would tiptoe around the most strategic choice for scripting and the launch of JavaScript was one of the earliest “Anyone But Microsoft” (ABM) moments in the browser. The market made its choice of scripting languages clear with JavaScript the obvious winner. Office was already iterating on saving documents to HTML and making progress. Still, many thought the combination of the latest HTML 3.2 and scripting along with future browser enhancements meant the replacement for Office was looming.
PowerPoint was a canonical example of an Office app to be replaced by HTML. As it turned out, a dozen different sites were doing pages that from 10 feet away looked like a slide-creating program. The ability to make big title text with bullets was grabbing attention. Unlike PowerPoint in Windows, where most people used the default look reminiscent of color television of a blue gradient with yellow text. These new browser slides had cool texture backgrounds (like fabric) and blinking title text (thank you, Netscape, for that one!). These were absolutely trivial slides and there were no real tools for editing. In fact, these worked by typing lines of text into a form or series of five text boxes and clicking “submit,” and the slide came back as an image with bullets added. The image didn’t scale to full screen and most of the time picking the size of the image was done at create time. PowerPoint, however, was going to be the first victim of the browser, or so it was suggested.
Reading this, one might say that of course this happened, evidence today’s Google Workplace apps. Two decades is a long time—that is like saying the iPod was going to come along and disrupt the Walkman so the Walkman team should have just given up, long before the iPod arrived. Still, Google today has not commanded more than a small slice of the productivity tools business dominated globally by Office. Whether that is still changing or not, only strengthens the point about the timescale we are talking about. As this book shows, and will show, frequently being early is not always the best path.
Netscape was already building email and that was going to displace Outlook, as it was put bluntly. There was more credibility in this only because Outlook lacked support for standards and was still far from the most loved product in Office (“Byzantine” as it was called in reviews). Netscape was building an internet native email client, not unlike the current favorite Eudora that the Internet Mail and News app (Outlook Express) was going after. Rumors were swirling about a word processor and tools for collaboration based on a significant acquisition Netscape made. I was concerned. Netscape was a force. We were already on edge about word-processing with the rise of email, which is why we did so much to integrate Word and Outlook. A word processor that shipped with the browser was exactly the strategy the Office team proposed at the company’s very first Internet offsite.
For the rest of our Internet Division, however, the browser was everything. Having Office commit to the Microsoft browser was not only good for Office but would enhance the unique, proprietary aspects of Internet Explorer that Office would use to deliver a product in the browser.
I was not alone in questioning the maturity of browsers to build document creation tools. Sun Microsystems introduced a new programming language called Java that addressed the lack of power in the browser to create full-featured applications. Java was getting a great deal of attention from enterprise IT strategists because it came from Sun, leaders in the server world (and main competitor to NT), and because Java more closely resembled the client-server world they were used to. In many ways, Java was viewed as the successor to Microsoft’s Visual Basic with the added benefit that Java was touted as “write once, run anywhere,” which meant it worked on any computing platform. Enterprise IT loved to hear about technologies that avoid platform lock-in, the theory of Java was just that. Adding to the strength of that message was the rebirth of IBM under CEO Lou Gerstner as a company free of the shackles of proprietary technology and open to supporting all the popular platforms. IBM was “all in” on Java and emphasizing it as a key technology across their product line. The embrace of all competitive or alternative technologies as a way of leveraging account control was now the IBM playbook, and one that threatened to slow down Microsoft’s emerging opportunity in enterprise accounts.
JonDe and I grappled with the notion that writing programs in Java was a significant risk to Office. It wasn’t just technical reservations, but our life experiences. Java was an interpreted language, which meant that the programs were represented by code that was converted to native machine code as it ran, unlike Office, which shipped as fast compiled native code, as most all modern software did. For JonDe the idea of using an interpreter for programs was close to home. His first job at Microsoft used an interpreter (pCode as previously mentioned) specifically to write apps once that ran on many computers of the day using as little memory as possible—Microsoft had its own proprietary dialect of the C programming language and an interpreter for an array of different computers. Over the past few years, all interpreted code was removed from Office products as modern operating systems made using an interpreter unnecessary and slow. Interpreted programs made sense when the scarcest resource was memory, which was no longer the case.
Finally, the GUI programming model of Java was strikingly close to the big fat AFX class library that was thrown out and a huge failure much earlier in my career. The idea that the way to work seamlessly across multiple platforms is to invent yet another platform seemed doomed to failure. In the case of Java, Jon and I sat in his office reliving years of our shared experiences, making it difficult to think there was any reality to this technology. Cross-platform, interpreters, big class libraries—what a horrible foundation. Add in the promise of write once, run anywhere and it seemed obvious that Java was set up to fail as a tool for writing client apps. We’d seen these movies before. Or was that a warning sign to us to be cautious in fighting old battles again?
There were at least a dozen different companies building what were casually called Java Office products including consumer favorite Corel. There were suites of tools, attempted clones of Word, Excel, PowerPoint, and integrated products like Works. There was a huge investment from Silicon Valley venture capitalists to fund Java-based companies and many of those were going after Office. Like JavaScript, Java was supported by the loose consortium of anyone but Microsoft.
Therefore, Java was enormously important to the Developer Tools division where maintaining the mindshare of developers was their key mission. In another aspect of embracing technologies, Microsoft released Visual J++ as part of the family of Visual tools, side by side with Visual Basic and Visual C++. Visual J++ was a technical tour de force, but Microsoft was strategically conflicted over embracing it because of the loss of control on the client where Win32 was strategic and on the server where Java could lead to a stronger position for Sun (Microsoft .NET was still a few years away). Office was a big user of Visual Basic and enterprise customers were deeply committed to it for client-server development, at least for the moment. It was clear that Office could not bet on Java for those reasons, but then again what if Java were to win in the market?
The network computer, or NC as it was called, was particularly troublesome to the Windows operating system team. Larry Ellison at Oracle championed the NC, a simple computer that only ran one program, a web browser. For the NC to disrupt Office, browser-based applications offering some functionality like Office were required. The real fear of the NC was that enterprise customers would adopt it simply because managing Windows PCs was so painful and expensive. PaulMa and the people on the Windows team thinking about TCO spun up an initiative ZAW for zero administration Windows. It was a classic sales tool to solve a deep technical problem. While I was as worried about the NC as anyone, from an Office perspective it still required HTML Office (or potentially Java Office), which was, at the very least, a stretch. The NC was a strategic threat for every aspect of Microsoft. The question was on what timeframe and again with what technologies?
The fourth technology movement to navigate was the idea of components. Components were not a specific programming language or even technology, but the concept that component technology would replace tools such as word processing and spreadsheets with much smaller and lighter components. Components might be viewed as an expression of object-oriented concepts in the context of resulting products rather than programming techniques. Components could best be thought of as basic building blocks of applications from which a customized version of a full-featured application could be easily created with the benefit of having only the capabilities required resulting in a reduced need for system resources like memory and disk.
Components were a response to the feeling that suites were bloated with too many features no one used, making them inefficient for the enterprise. IBM, who did not have a competitive suite even after acquiring Lotus, was the leader in touting components. IBM repurposed Lotus SmartSuite as components, more sleight of hand than technology. Components were attractive to industry analysts like Gartner who believed that enterprises might construct purpose-built desktops tailored to workers by using components. This type of design was exactly what I saw at the bank in New York when I went to learn about total cost of ownership. Java was the new way to implement components. We were sort of going in circles. That was sort of the point—the proponents of Java did not want to compete with Office so they created a product strategy that was something Office could not do even if it wasn’t something humans wanted to do.
To cover all the bases, a newly created alliance of various Java vendors announced a component architecture called Java Beans, to fill the architectural holes in using Java for components. This technology was aimed squarely at Microsoft’s own ActiveX (or earlier technology COM). Many in the Microsoft platforms ranks viewed COM as something of the crown jewels of our overall architecture approach. This made competing in component technology even more important. Office already used COM and it was tightly integrated with Visual Basic. This was good for strategy, but again if Java or Java Beans became the defining technologies to disrupt Office then we would lose out.
In addition to technology, the concerns about Office included cultural and process issues starting with the length of time Office was going to use to create a new release. The Internet Explorer team became quite enamored with the concept of “internet time.” Internet time was a key element of the ongoing browser wars (as they were called1) between Microsoft and Netscape.
Unlike Office, where releases took 24 to 30 months, browsers were being released every nine to 12 months (at least for the past two versions—any two data points can make a trend). On the face of it, releasing the browser that quickly did not seem risky—the main characteristic of browsers was that they were viewers, and if they crashed a user could revert to what they were previously reading. No work was lost, unlike if Word crashed. Plus, HTML was designed in a fault-tolerant way, so any coding mistakes in displaying it on the screen were minor annoyances more than anything else. This relaxed a huge constraint on engineering and certainly made release velocity possible—that and the fact that these were not big programs yet. HTML and the browser user experience were maturing rapidly—there was so much low-hanging fruit to get right just looking at how other browsers worked. Basic, and known, features like clipboard, printing, accessibility, and more needed to be added. Most of all everything was new so there were few pre-defined criteria for features, other than what Netscape was doing.
To some, this was another point at which Office didn’t get the way the world changed. Office needed a new architecture and to release faster.
Office9, the product that few knew about and that even we had not developed full plans for, was not exciting enough because Office was being disrupted. It was also taking too long to get done, even though we didn’t have a schedule. To thwart the disruption, we needed to build a new Office that was more exciting, but to do so meant solving a complex web of technologies and competitors, none of which seemed remotely up to the challenge. Every time I said something like that I was literally the punchline (punching bag?) of Innovator’s Dilemma or sent another link to a press article about a new startup building Office in HTML, Java, Components, or Network Computers.
My emotions ran from angry to upset to frustrated as I tried to figure out how to have this conversation without being the person who said, “All the new technologies won’t work,” while also being the person who said, “Office won’t change.” That was a dangerous combination when the phrase “disruption” was being tossed around because such a reaction was literally the one written about in the book. In other words, everything I might have said was going to be viewed through the lens of me playing the role of the executive with his head in the sand. Oddly, I was one who helped get everyone excited about the internet in the first place. More than anything that stung, being painted as a luddite so soon after running around the company trying to get people excited about the internet.
The feedback felt to me was like an allegory of Go Get This Rock, that was told to me by members of the original LanMan team (the failed but still legendary networking project that was originally managed by SteveB).
Elder: I wish to be clear and helpful. Go get me a rock.
Student: (runs to riverbed to get a rock and picks out a nice one) Here is a rock.
Elder: No, not that rock. Try a bigger one.
Student: (runs again) Here's a bigger one.
Elder: Yes, but that isn’t smooth enough.
To the elder (the manager), this was the process of managing by “I know it when I see it,” which was certainly one valid school of management. To the student, this was unwanted insanity.
The kind of feedback we were getting felt like getting rocks. No product approach was right. No technology choice was right. Nothing was soon enough. And it was frustrating. It was, unfortunately, also the default executive management approach. At the time I was miserable from this and of course did not handle it well. This manifested itself in endlessly long email threads, which I feel I achieved a varsity letter in writing. With the benefit of hindsight, this was a product of the uncertainty. No one knew what to do and everyone was kind of worried. We simply entered a period where the prevailing view was knowing what to do once the right answer was presented, and at the same time there was a belief that the right answer was higher in the organization where there was more context about the risks to existing businesses. In many ways, this was the innovator’s dilemma we faced (all of us)—the question was if the new technologies could be fit somehow into existing strategies or we needed a whole new approach. There was also a great deal of Microsoft’s universal cultural attribute, paranoia.
Writing memos in addition to email became my tool for processing my own thoughts and, in a way, getting my act together for confrontation, at worst, or at least a strategic discussion. Writing was my way of saying, in detail, “Here’s a rock,” and a way of documenting promises and commitments in one place for all audiences. It was also a way of saying “This would be a dumb rock and here’s why”.
I wrote a dense 20-page memo called High Hopes for Office9. This set a tone that was, in hindsight, overly defensive. Caffeinated on Diet Coke and wound up, I banged out this memo in an evening. It served as a precursor to the strategy offsite for Office9, detailing the main product pillars. I took on all the technologies and strategies I could and did not hold back.
In the abstract, I needed to find a way to at least suggest that the main technologies being talked about as disruptive to Office might pose a threat but not in any reasonable time, even though this was tilting at windmills. We already planned to embrace internet technologies. Primary among these were saving documents as HTML, using HTML as a native file format, connecting Office apps to servers using internet protocols, even using the internet for help, assistance, and content like clip art and templates. Most importantly, we were shifting our resources and efforts to building a collaborative server capability using FrontPage. All of these relied on internet technologies to solve problems within Office, which was decidedly different than rewriting Office in internet technologies.
Second, I showed that I understood that the attraction of these new technologies was due to deficiencies in Office. I then demonstrated how we could dramatically improve the cost of ownership, ease of use, and management of Office on PCs by simply doing a better job in areas we had previously paid little to no attention to.
I also knew that no matter what happened, someone always said it would. Microsoft was at the scale where regardless of how something played out, someone always wrote the memo predicting it. NathanM was even famous for writing multiple memos with conflicting predictions.
I was not naïve, but I was optimistic. Our plan was strong, an internet-savvy plan, but we also knew that the zealots who were convinced the internet was the undoing of Office would not be pleased. As I learned from BillG, there was a benefit to balancing the opinions of the zealots with reality. Balancing the extremes while executing well was, for better or worse, my sweet spot.
With my memo presented as a deck at an offsite, and the goal of not hurting the morale of the team present, which would undermine plans and execution, for better or worse, the team appeared to feel the same way that I did. Looking back, it was more that the plans for Office were given reluctant acceptance by executives without much actionable feedback. In hindsight, there really was a high degree of uncertainty about what to do, really, and no one, especially executives from Platforms new to managing Office, wanted to hinder the Office business out of the gate.
At best if the project went well, then we could say we agreed, but if things did not go well it was obviously my/our fault. I was fine with that level of accountability. In fact, it served us all well.
The next step was to have an actual plan. The kind of plan that the Office team was skilled in delivering and executing.
Probably the best chapter so far, thank you! I can literally feel anxiety through it and I can only imagine what it was to make all those bold calls you and the team had to make with all the external pressure and uncertainty of late 90s. Great time and memories.
Are you going to write something about Office 2007 and the ribbon? It must be a great story too and thriller as well. I still remember myself asking people around what is the most used command in the Office UX. Almost everyone was shocked with the reality :-)
Great chapter. Echo comments below that this is one of the best so far. It's interesting to read that platforms / systems were technology driven and apps were scenario driven. In retrospect, were the transplanted tech-driven discussions the right approach for Office at the time?
After switching to product management in my post-MSFT career and working at large companies in the Valley, I've found these companies to be very allergic to tech driven strategies, esp coming from the PM organization. Everything must "start with the end user" or "work backwards from the use cases". This helps prioritize investments to maximize user value but can also be short sighted when it comes to making deep investments in durable strategic technology.