Hardcore Software by Steven Sinofsky (Audio Edition)

Few recall our products being developed at the end of the 20th century, but they were the foundation of modern Microsoft: Windows NT 5.0 (Windows 2000 Server and Workstation), Office9 (Office 2000), and Exchange Platinum (Exchange 2000). These products had none of the glitz or bang that consumers experienced with the 1995 wave of products, but the company used the intervening years to mature and “pivot” from that consumer company to an enterprise company. It has been said (by many) the best products don’t always win, but the products that win become the best products. Take these relatively uninspiring products and launch them with a hungry, organized, and focused global sales force waiting for the opportunity to prove Microsoft was an enterprise company and we had the makings of, well, the future of Microsoft. For Office the first step, however, was to figure out how to even build products for these new customers.

Back to 047. Don’t Ship the Org Chart

A characteristic of the early computing era was how much of it was created and built simply for our collective enjoyment or our view of what the products should do and how they should work. Looking back, it is easy to see the limitations of such an approach. How could a bunch of math and computer science majors with no previous work experience build a word processor for lawyers or a spreadsheet for bankers? This was even more true in tools and operating systems where just doing the work to make other stuff function was not only miraculous enough to constitute a product release, but also kind of fun. Even Microsoft’s biggest bets, such as the graphical user interface, were not based on any sort of “what the customer wants” or even customer problems, as much as building it because we (or more correctly conventional wisdom among hackers) thought it made sense or simply because we could.

This approach, which I previously referred to as testosterone-based development, hinged on the most assertive argument or fastest to write code dictating what we did, served the company and industry extremely well. Then one day we looked around and the universe of people buying computers was much larger than our fellow techies. The people with all the money were interested in a more nuanced approach to software, and that included meeting what they perceived were their needs. They wanted computers to contribute to the business bottom line, and to do so cost-effectively.

Our approach to building the platform and apps led to a complexity that even we could not understand at times. I recall once struggling in my office to build a histogram with Excel. I just couldn’t do it (there was no internet to ask). I finally asked a teammate who was one of the original Excel developers to help me. We spent hours that night, some of it in the Excel debugger, trying to figure out how to make Excel do something we knew (or so we thought) it could do. It was a weird moment that left a real mark on me but in hindsight it was no surprise that even an Excel developer wasn’t an expert in actually using Excel. This pattern repeated itself across the whole Microsoft product line. Our “power users” and those that authored the 1000-page how-to books were far more expert in what we were doing and the limitations than we were. One group in particular had raced well ahead of us in understanding Office, the corporate IT administrator of our new LORG customers—those tasked with putting a PC on every desk. Much to our surprise, the complexity of issuing a PC to every worker was vastly more than going to the store and buying one for home or even managing the 5 PCs in a typical developer office. It was, in a favorite Microsoft-ism, non-linear complexity—the more PCs a company had the ever more complexity each additional PC created.

We needed to wrap our collective minds around both the suite and LORGs in a new way. What did it mean to build Office for LORGs? To be concrete, what features would sell? What were customer pain points that if we solved would cause more customers to upgrade?

Teams like Windows Server and especially Microsoft Exchange fully embraced the complete trappings of LORG product teams. The leaders were showing up in the newly renovated Executive Briefing Center where potential customers came to spend a day learning about our strategy. Teams engaged with the industry analysts at firms like Gartner Group, Meta, and Forrester. These groups acted almost as referees of enterprise product strategy and roadmaps, charging enterprise IT, our customers, handsomely for interpretation and explanation of vendor strategies. Microsoft even paid to have their strategy heard and critiqued knowing customers were paying for an objective interpretation—this was the enterprise game, or racket. These activities spun up and were driven by a newly LORG-focused Office marketing team with dedicated leadership for LORGs, staffed with people who previously worked in field sales. Server groups spent considerable energy on these efforts, particularly from program management.

It would be impossible to overstate the effort and results from the Server and Exchange teams deeply embedding themselves into customer environments. Organizationally from the top down there was a melding of the minds with the deeply technical IT leaders that were making career bets on deploying Windows servers and Exchange email. There were people on the Exchange team, for example, that spent far more time at Boeing than they ever did at Microsoft. There were LORG customers that were so frequently seen in the Server hallways that one could mistake them for full time employees or vendors (and some even had Microsoft credentials).

Office needed to find a path more suited to the products we were building. The server products were both purchased and used by IT professionals. Office differed between the buyer and the user. BradWe, of Office design, was fond of saying we needed to be building products that were “useful, usable, and desirable,” and then reminded us of that when the purchaser and the end-user were different people or organizations. IT people were both end-users of Office and also corporate gatekeepers. The most fascinating thing about working with them was keeping track of which hat they would be wearing for any given conversation. We had plenty of inputs and a much deeper understanding of end-users, but it was not uncommon for IT people to flip from talking about deployment or performance to suggestions for formatting features or ease of use. That was always the tricky balance for us.

The Apps teams pioneered smart processes for learning from end-users. Word used instrumentation to learn from individuals while also learning from specific customer types such as lawyers to understand the nuances of multipage footnotes, specific formatting of tables of citations, or the crazy complexity of nested numbering in briefs. Excel mastered getting inside the heads of the power users of Wall Street and the sophisticated models they created. PowerPoint from the start understood consultants and trainers (and preachers!) in addition to the art and science of graphical presentation. These techniques formed the foundation of learning from customers in a systematic manner that helped avoid product design by feedback and anecdotes.

With the rise of a highly engaged sales force and the deeply connected product teams, we had an onslaught of anecdotes. Executives were fanned out around the world “visiting customers” as we would say when referring to the highly stylized ritual of an executive hopping on a plane and visiting a few countries and 8-10 customers in a swing through a geography account teams in tow. Execs would routinely share the horror stories from these visits about products that didn’t work, competitive threats, or simply customer demands for must-have features. The target for these visits were the Fortune 500 or even the Global 2000, and the leading government agencies in most every country of the world. Quickly we were knee deep in forceful anecdotes—a new form of testosterone-based development. Sifting through these often conflicting inputs not to mention a tendency to most-recently-heard feedback being the loudest was stressful.

We needed some sort of systematic process. We needed to treat LORG customers as a category of customer, the way we had for lawyers, consultants, or bankers. They were indeed a customer segment, and now the most important one.

There was a gaping hole in the Office team’s knowledge of LORGs—understanding information technology professionals (IT Pros) and system administrators (sysadmins)—the individuals at a company responsible for pushing Office out to thousands of desktops and maintaining Office on PCs. Office assumed one person bought the product, ran setup, and was responsible for their own PC. There were features, white papers, and support personnel to assist sysadmins, but basically they used the same Office products. We dutifully produced the Office Resource Kit to assist these IT professionals, but most of the content was related to training and usage. With our file format crisis in Office 97 we had an early trial by fire and substantially increased the content related to deployment. Still, these additions were objection handlers and not primary design points. For the first time, we were designing Office for IT Pros and sysadmins.

Peggy (Stewart) Angevine (PeggySt) led program management on setup, the program that copied Office from floppy disks to the hard drive, a contribution considered somewhat mundane, though technically challenging. Originally and proudly from Wisconsin, PeggySt joined Microsoft a few years earlier after graduate school. She and the team created the first integrated Office setup feature, streamlining a laborious and manual process. The lists of the thousands of files that made up Office were maintained in large text files that were so big (and the lines so long) that even Word was not a good editor for them. In contributing to this, Peggy became well versed in the way that LORGs took these text files and customized them. When Office was installed on thousands of PCs at a big company, it was customized with the exact set of features that the company wanted, trading off on disk space and complexity. LORGs viewed the customization of Office setup as a key part of deploying Office and important features. Our first LORG feature for Office was enabling custom setup.

Setup was a major pain during this era of software. Originally setup meant copying files from floppy disks to the hard drive. Over time, setup became an enormously complex task that, in addition to being customized by admins, might, for example, detect what language or locale Windows was running and then copy over the right spellers (for example, in Canada both French and English needed to be installed). It might also do all sorts of things for our business such as check for existing versions of Office or validate the serial number typed in. This work was done by a couple of people on the team who maintained this sorcery in their heads because we had few tools other than a text file to codify the solution. Program managers Teresa Fernandez (TeresaFe) and Jennifer Cockrill (JennC) managed this complexity. I had 15 years of programming languages experience, yet when I stopped by Teresa’s office and looked at her screen filled with thousands of lines of code I was mostly overwhelmed by our creation—each of the thousands of lines in the file were hundreds of characters long with dozens of commas and semicolons and one character misplaced might be a disaster. We had no tooling or debugger other than using a text editor. Outside of Microsoft, a small community of people reverse-engineered this expertise, against our recommendation and support policy, becoming resources (on internet newsgroups) to the sysadmins of the world customizing Office. This system was called ACME and we were on version 1.1. Everything about this crucial step in delivering software was mostly an afterthought.

Embracing LORGs meant embracing setup and the process of upgrading software on an existing PC. PCs were significant capital investments and companies wanted them to last a long time, even forgoing the benefits of upgrading Office that they had purchased if it meant introducing complexity or incompatibility to an existing PC. HeikkiK, with his command-and-control military background, spent the last part of Office 97 working on a hardcore upgrade initiative called Upgrade or Die—intended to overcome the inertia among customers to stick with old versions of Office. Without upgrades our business was dead or suffering.

As trivial as it sounds in hindsight, setup and upgrades were the heart of how our new friend TCO (Total Cost of Ownership) was measured. The high costs of bringing even one PC into a business was increasingly dragging down what looked like an enormous upside. For the first time, business customers were telling us they simply could not deploy more PCs. Each PC they sent out was costing them thousands of dollars in internal help desk, slowing down the company, and just creating headaches all around. Worst of all, the internal measures of satisfaction with IT were very low and IT was starting to look like the punchline to jokes in most every venue from Saturday Night Live to Dilbert.

HeikkiK and PeggySt took on TCO from two different perspectives, Heikkik as a program management leader figuring out what features best reduced TCO, and PeggySt with the product planning team where customer research and learning took place. The first thing the pair did was to hop on a plane and go visit customers—our default response to enterprise customers, a direct result of the TCO crisis mails flying around from field sales after reading the latest Gartner report on TCO. The field was more than happy to host members of the product team for a lashing by their accounts. Whether through English as a second language or a translator, these immersive visits were enormously difficult for a group of us that, frankly, thought we’d done a pretty good job building apps that customers loved.

Learning trips like this involved meeting with a combination of our closest, biggest, toughest, and most open to talking customers. SteveB was the permanent Ford Motors account manager so they were top of the list (SteveB grew up in the Detroit area and his father worked there, as did my grandmother during WWII making tank parts in New York). There were other companies that were tour regulars, but Ford always carried the most weight internally because of that connection.

Heikki returned from Detroit having seen the light, so to speak, but his learning sounded like a dystopian future where the very tools of empowerment, the PC, were controlled by the dark forces of IT. Talking with the sysadmins at Ford, Heikki received an earful about the difficulties of the file format transition and customizing Office setup that he knew all too well. Ford wanted to minimize the disk space used and the number of features in the product to reduce the support costs of Office. As was typical at the time, Ford created a helpdesk that employees contacted for PC assistance, including help for basic tasks like creating and formatting documents. This type of support was factored into the Gartner costs for owning a PC. As the people building the product, we thought we provided a great deal of help within the product, which was designed for this situation. As far as Ford was concerned, we did not create easy to use products, at least not for their employees.

Sysadmins typically thought the best way to make a product easy was to remove a lot of features. For example, many end-users wanted more clip art and images for their presentations. That was a common support telephone call topic: “how to get more .”There was no internet inside of Ford or most any company and this was years before using the internet to search for images was possible. Office shipped with tens of thousands of images, but still, the perfect one might not have always existed. IT’s answer was to remove all the images and thus save on disk space and phone calls and not give the impression that images were even available within the product at all. Problem solved.

Not actually.

The real problem was not only Office, but all the cool things people could do with their PCs on their own. They could add a printer, buy more software and install it, play DVDs from home (and waste time!), attach a modem and dial-up to use AOL, or even plug in disk drives and other storage. From a sysadmin perspective these were distracting and costly. From a Microsoft perspective these were precisely what a PC was good for. In Heikki’s tour of Ford, his contact was sharing stories about how PCs were getting used for “too much.” Heikki learned they were buying sleek multimedia-capable PCs on the cheap online. The PCs arrived and all the software was removed. Ford customized Windows and Office, adding Ford’s other business software to the standard image. A hard drive image was a copy of all the files that could be easily transferred to a new hard drive in a single operation, creating an exact copy of a new PC, just how PCs were manufactured at Dell or IBM.

To reduce cost of ownership, Ford removed the DVD drives and the USB ports were sealed with epoxy. Heikki’s new friend proudly showed an entire storage closet filled with DVD drives that were removed from brand new PCs, along with a supply of epoxy. Heikki was also told, “And, believe me, if we could put the keyboards in this closet we would.”

The pattern repeated across the largest and best customers. The details differed, but the goals and basic hacking at Office were consistent.

I joined in the learning and visited a large Wall Street bank. My experience was just as concerning. I was shown the tool that IT created to simplify the creation of in-house documents like meeting agendas and interoffice communication. They determined that Word was too complicated, and it distracted people from their important work because it had too many features, or “options,” as they told me. To address these needs IT made a small place for Word in the traders’ desktop—a program that took up the full screen, dividing it into regions for different banking activities—and created a tiny little window to type a memo into. There were no menus or toolbars so no ability to format the document. There was a single custom toolbar designed with Save, Print, and Open commands and basic formatting. The customer took all of Word and cut it down to WordPad. They were proud of this work. I was mortified. Later in the day, when I managed to have a quick side conversation with an employee who was using this setup, they were quick to tell me how much they hated it and how they wrote all their letters on their PC at home. I had my anecdote.

The team heard dozens of similar stories as it fanned out around the world. We understood that IT was under siege. The PC went from volunteers requisitioning one at a time to companies mandating they be deployed to every knowledge worker, the newest hip term for white-collar work filling weekly business magazines. If a PC owned and managed by IT was a bit finicky or occasionally troubled, that meant that at any given moment someone could not get work done and needed hands-on help. That’s where the thousands of dollars were going.

How could we reconcile this? We could obviously see the complexity of managing tens of thousands of people using PCs, each unique in some ways. At the same time, we saw the good work we were doing, across Windows and Office, scaled back or even disabled. Worse, to simplify the product, Office was being turned into something it was not and was being made more difficult to use, the exact opposite of our design goals and past decade of designs.

To be fair, we simply didn’t believe in the idea that Office merely needed to do less. We understood and empathized, but the desire to do less was the solution as the customer saw it, and we could do better than that. It is not difficult to see the customer view. People are calling unable to do things in the product, getting tripped up figuring out how it works, or simply spending too much time on one task. The simple answer was to have less there for them to get lost in.

We felt we could provide empowering tools for creativity that were manageable and usable in a LORG. Doing so required us to integrate a LORG perspective into the product design process.

We aimed for the feature design process to be participatory and include IT—we wanted professional IT to feel a part of the design process for the features they cared about. PeggySt suggested we bring representatives of IT, those responsible for Office, together for an ongoing partnership to inform feature designs. While the server products deeply engaged with early customers, especially for deploying the product, and held design reviews, the idea of Office starting from a blank slate with a small set of well-informed customers, outside the sales and support process, was innovative. Peggy developed a straightforward plan and called the forum the Office Advisory Council, OAC, creating the first participatory design effort for a major product. What was different about the Office approach was how we combined the participation of IT professionals with our existing process for planning and scheduling a release. We intended to invite participation, but we were not taking direct orders or dictation for what to do, because we had millions of other customers we had to design for. That was the big difference.

Except nothing was ever simple.

Using her contacts across sales and marketing, Peggy solicited input for OAC membership—we intended to create a council that would meet quarterly in a systematic way. We believed if we assembled about 20 representatives from across countries and industries and spent enough hours with them then we would have a unique perspective to incorporate their needs into the product.

Peggy immediately ran into the sales organization wanting to understand what we would tell their accounts—the concept of “account control” was new to all of us, having zero experience selling. The regional VPs insisted on veto authority over the accounts we chose, and the sales team wanted us to work with accounts that were difficult deals to close and thus swayed by more attention from headquarters. The account managers insisted on being present. The lawyers on both sides were concerned about disclosure and intellectual property. The technical account manager teams (TAM) were upset that the customers learned more information about the product than they did. Other product teams wanted to align customers so that the best Exchange customers were also part of the OAC, or perhaps the worst SQL customers would become better customers if they saw the power of Excel working with SQL. Marketing was worried that these customers might leak information to the trade press. Even I expressed concern to Peggy that simply talking to customers before features were complete might commit us, especially if the customers communicated what they learned from our meetings to their Microsoft account teams.

It is often said that the hardest thing to do in a big company is to do something. We were used to the technical buzzsaw, but this was a process buzzsaw. What seemed like a simple idea of learning from customers turned into an avalanche of stakeholders and special interests. It was one of those times we just put our heads down and ignored the noise. We knew what we needed to do.

The OAC was a two-way learning forum, not a sales or support tool or a perk for good customers. We trusted the participants and they were going to trust us. The tone was a partnership. Customers thought their input was being taken seriously, not just documented.

Shortly after the vision for Office9 was completed, we held the first OAC forum. This might sound backwards or even disingenuous. What I observed with the Platforms engagements was that bringing customers in too early led to input and feedback that was all over the map and difficult to work through with clarity of purpose. Starting off with asking what to do, even with technology professionals, was still only as good as the solution set they were aware of. For example, we would receive lots of input on fixing the syntax of our setup customization language, but no one would suggest an entirely different approach. By having a high-level plan and features to discuss we were able to prioritize, refine, and validate the intended product—the discussions were far more constructive. Most importantly we knew that the resulting input could be mapped to a robust product plan and the feedback truly made a material difference.

The first meeting we held involved an exercise in budgeting the product engineering resources. We created lists of dozens of features for the product across each of the key areas we intended to innovate in for the release. Normally discussions would then take place about those—platforms would bring in experts and present those features and there would be a feedback session. We did that, but we also gave the OAC members a budget. They then got to spend a few hours with sticky notes allocating resources across the team, deciding what features they would choose to do. The most fascinating part of this exercise became the debates between the OAC members themselves over what Microsoft should do. By participating in this way we learned the value customers placed on different features while at the same time the OAC came to understand that there are inherent trade-offs in all we would do. Even they came to the conclusion that releases with no features other than TCO-reducing work would be boring and not have the business value justifying a deployment.

To broaden the impact across the OAC had across the team, we scheduled atrium talks where members of the OAC presented their view of Office and the challenges they faced and the needs they had. The atrium was the large open space in building 17 where we often held large group meetings. They presented how they rolled out PCs, deployed new software, maintained stability and robustness, and supported their own users internally. In a way, this was giving everyone on the team their own version of executive customer visits, knowing that customers had no interest in hosting every engineer on our teams the way they would host execs. As we made this more systematic it became common to hear people talking, actually empathizing, with customers over the problems they had and the unique ways they deployed and managed PCs.

Peggy introduced this exercise by saying building Office was like ordering pizza for 20 million people, without a big enough budget and no way to make everyone happy. It reminded me of the limited budget we had in our dorm for ordering pizza and the debates we had for that one time I got to spend my resident advisor budget. In hindsight, 20 million does seem like such a quaint number. This also became the title of my standard college recruiting talk that I would give for the next 5 or more years.

BillG even joined. He was never super enthusiastic about the needs of IT, especially when it came to tailoring products for the specific people who wanted to turn all the features off, so to speak, but the result of the session was interesting: Both Bill and the OAC members gained a strong sense of empathy and commitment toward a common goal. By this time, securing a small conference room meeting with Bill was not even something many of their CEOs would have been able to do, which made it all the more special.

OAC continued to grow to be an increasingly important and significant evolution of Office planning. Every member of our team working with the OAC could point to specifics in features they worked on that were improved, rethought, or prioritized because of those interactions. On the other side, members of the OAC became long-time friends of Microsoft and us personally. As members of the OAC progressed in their own careers (often to CIOs!) it was not uncommon for me to hear from them about how much being in the OAC helped them to better understand product design and how to relate to product makers. Each release the competition across the field to get their favorite customers into the OAC increased and the visibility of the program became its own sign of success. Still, maintaining the core function of participatory design and not turning it into another sales pipeline or marketing tool remained a (sometimes difficult to maintain) priority.

Personally, not only was the OAC a cool part of learning and process innovation at Microsoft, it was also a learning experience for me when it came to enterprise selling and an appreciation for the incredible complexity the PC was bringing to business even while empowering employees to be more effective and creative.

I consider the OAC one of the most important contributions we made to building Office for this middle part of the PC revolution. Over time, enterprise thinking became baked into product design. That presented a new set of challenges as we will see.

On to 049. Go Get This Rock

The Microsoft sales force had a ritual of reorganizing every fiscal year, like clockwork. The Platforms teams always seemed to be in some state of organization change, at least to me. Office, on the other hand, had been relatively stable except for two deliberate changes. As successful as Office 97 would prove to be, the product still reflected the development organization more than the value proposition. We needed to change that. To change that required us to develop a more robust planning process that was relevant to everyone that mattered.

Back to 046. Prioritizing a New Type of Customer [Chapter VIII]

With the start of our company-wide transition to becoming enterprise-focused, the product group organization seemed to be in a state of flux as we began a new release to follow Office 97. Churn across the senior leadership was a defining element of middle age for Microsoft.

Over the next decade or more, at least for me, it seemed as though we were always fluid at the top. We were either restructuring or leaders were being moved around, and sometimes both at once.

By the time Bob Muglia (BobMu) was my manager, starting in March 1999 and right around the release of follow-on to Office 97, Microsoft had gone through three major restructurings over the course of seven years—changing first to five main operating units then to seven and then back to three. Just keeping track of division acronyms was impossible, and as fast as we could distribute T-shirts and logo items, the acronyms expired. It wasn’t uncommon to enter an office with moving boxes that remained packed in anticipation of the next move.

Desktop Applications had four different executive leadership structures during planning and delivering a single release of Office over 30 months. From the end of Office 97 until we shipped the next product, the larger division containing Office would change names numerous times: ACG (Applications and Content Group), AICG (Applications and Internet Client Group), ATG (Applications and Tools Group), BPG (Business Productivity Group). The groups were each defined as Office and other stuff, often not particularly adjacent in the market. Each one of those changes came with some feeling that even after the successful launch of Office 97, some things needed to be done differently. But what?

While never explicit, the executive changes all had one thing in common. Each was a gradual move towards Apps being managed by executives from Platforms. There was a subtle reminder that the company was a Windows company, and importantly that when it came to the senior executives, it was the Apps teams that needed leadership from Platforms, not the other way around. It always felt like we were getting a message that we needed help in some way.

A level below these new executives, Applications had been stable for quite some time. As described previously, from the earliest days until Mike Maples’ business unit re-organization in the late 1980s, the teams were organized by job function. The business unit function served well through the rise of the Macintosh business leading to Office and the creation of the apps for Windows, until the creation of OPU in 1994, the Office Product Unit. This relative organization stability coincided with a growing execution capability on the team. While products were late, they were (with few exceptions) never out of control. Individuals became strongly committed to the individual apps teams and finishing what you started became a key element of the strengthening culture of Apps.

By way of comparison, Windows ran with parallel teams through much of a release, with one team focused on shipping the current product and another team focused on the next release. Culturally, there were starters and finishers. The starters were the big thinkers in terms of ideas and architecture, and the finishers were the closers who drove a project to completion and managed the complexities of closing down ecosystem contributions.

That meant that at any given juncture there were always two buckets, with code names: Chicago/Cairo, Nashville/Memphis, and Whistler/Blackcomb, for example. When a product finished, there was a changeover in leadership. The finishers came in and the starters moved on. It was their culture. The presence of a future team seemed to me to almost distract executives providing a team to meet with and a place for all the new ideas to go, while the shipping team worked heads down. The handoffs were never that clean and with some frequency the future product failed to make it to market or would change substantially with the shipping leadership.

Office, on the other hand, was predominantly single-threaded—focused on one release at a time. Office believed firmly in a culture of engineers finishing what they started, program managers owning features from start to finish, and testers being involved from the start of a feature. Most of our performance evaluations and promotions were based on understanding complete product cycle contributions. The idea that features that did not fit in one release rolled into the next release did not work for us, simply because we started each release from a clean slate and awaited feedback or learning from the market. It was almost never a good idea to begin a release with what was not finished previously—a lesson that is even more applicable in today’s continuous delivery model. Planning for the next release began informally around beta and then ramped up—a process that I worked a great deal on developing and honing. Our view was that shipping was learning and that assuming what was not complete needed to be finished was not the right place to start.

The Office team’s single-threaded product development proved frustrating to BillG and Platforms over the years, and given the change going on with the internet, browsers, and even org changes, the pressure to be talking about the future was greater than ever. LORG customers also demanded more information about the future, a constant source of tension for Office that lacked a second team building the next release. Because software was always in a constant state of deployment, LORGs wanted assurances that what was being deployed today would remain relevant in the future. Thus, with LORGs came an ever-increasing demand for long term product roadmaps. Accountability to those roadmaps was another issue entirely.

As much as a LORG customer might wish to standardize on a single version of Office and Windows for their standard PC, the realities of release schedules, product updates, evolving PC hardware, and their own desire for new features made that impossible. Like painting the Golden Gate Bridge, the deployment of Office and Windows was always a work in progress.

The execs felt that without a second team available for ongoing conversations, they had no ability to give input. My own experience, especially in watching this from my role as Bill’s TA and in seeing the hand-off between several versions of Windows, was that much information gathered from those meetings was lost in the transition between starters and finishers. The hand-off was a loss of team momentum as well. I was never convinced that it was possible to execute parallel releases. Our experience on Office 95 and Office 97 only cemented how difficult and consuming that could be, and we were extremely constrained and disciplined.

In order to gain more visibility for what appeared to BillG and others to be a secret Office planning process we began planning with more people from other parts of the company—company-wide thought leaders. I documented the offsites with memos and notes and distributed them. This, in turn, created more demand for participation and sharing, which concerned me because we had a strong desire to keep release plans confidential. The business relied on exciting launches and reveals to drive upgrades. We had not yet reconciled the demand for product roadmaps from customers but were already familiar with the ability for any forward-looking materials (especially) slides to find their way to the field, customers, and even the press.

These offsites were an integral part of building a shared view of a product’s future. As much as offsites were loathed, I witnessed their effectiveness (and not) when working for BillG. As such, I put them to use in Office. The offsites were a weird match between people who knew all the details and people who knew none of the details, but everyone had strong opinions often stated as facts when in reality we had very little data about the world as it existed and none about where things were heading. These offsites were useful in bringing a common dialog forward and at the very least when criticism was offered, we knew from where it came.

By this time JonDe was the VP in charge of the whole Office product, OPU and the app teams. He reported to several different executives in a short time. During the transition to the next product release, JonDe and I were determined to embrace a new mantra, “Don’t ship the org chart.”

Collectively we saw too many examples of this in Office 97 and across the company, where the organization mirrored the code architecture and that constrained what could be built, thus determining what would be built, regardless of broader goals. Developers naturally want to own code. Managers of developers want to know which code they own and control the flow of data to and from their code and what other parts of the system can use this code. Over time, for us, this created a code boundary that was enforced by the organization. Products ossify and it becomes difficult to branch into new areas. These boundaries define resource allocation requirements—if a team took a certain number of people to code one release, then it needed to have the same number, or more, next time.

Creating software is always a process of layers, each more abstract than the next. In an ideal world, there are clean layers of abstraction communicating only with layers above and below through pre-determined programmer interfaces. In the real world, not only is it exceedingly difficult to create these nice layers, but it is also nearly impossible to maintain them as the needs of the product evolve over time. In fact, innovation mostly happens when a new product comes along and has a different view of these layers, creating an innovative (better performing, more secure, easier to use) product by busting through layers.

Examples such as integrating charts in Excel, background spelling in Word, or the whole of the graphics features in Office 97 broke through existing or traditional code boundaries. Failing to recognize the power of breaking existing abstractions and, more importantly, not letting the organization determine how code is built is key to innovation. Having fluidity in layers and in ownership of code over time creates innovation and enables flexibility in the organization to take on new problems and bring new perspectives to how features should be implemented.

Planning the release after Office 97 was a chance to step back and create a new process for a new Office product, and a new organization.

We started with the defining characteristic of an Office product planning process—the best combination of top-down, bottom-up, and middle-out planning. This was straight out of the Cape Cod experience (credit where credit is due). It contrasted sharply with the prevailing approaches to product planning that were used across the company and most industries. Historically, the plans for products were driven by the “smart person” or staff who owned pulling together a slide deck. They presented this for review to executives. Over time, the decks became increasingly denser, but the overall integrity of a schedule, engineering plan, or iteration about the plan was all left for after planning. Much of this approach explained the difficulty of finishing a product on time. This worked well when the product plan was a known programming language or a known specification like a video driver. We had far too much iteration in what we were doing, not just how we were doing it, for such a centralized handoff or waterfall approach.

Each App team maintained a sense of rhythm of planning and there were many inconsistencies. In leading Office Program Management, I needed to find a way to bring synergy and consistency across the teams as we moved resources from App teams to OPU to create more suite-wide features. We de-emphasized app- or category-specific investments. This strategy remained controversial (for years) but was abundantly clear to the market and well supported by JonDe.

In order to talk about a new release, we needed a name for it. We settled on calling the next release Office9, complete with a working logo from the design team. The name was simply the next version number, not anything more (recall that Office 95 was the first time we bumped all the app versions to be 7.0, the successor to Word 6.0, followed by Office 97 as version 8.0).

We spent a good hour one day brainstorming potential code names. While Word had used clever code names, such as Spiff and T3, by and large I and Office shunned codenames. Flashy codenames when leaked were fodder for the press. We considered boring codenames like the government uses. My favorite example was Beige. In the end sanity prevailed and for the next decade or more Office stuck to version numbers.

I wrote a memo, Priorities and Processes for Office9, intending for it to be the planning kickoff, sent while the team was in the last days of finishing Office 97 (meaning only a few paid attention). The memo was a call for us to work together across teams. From a feature selection and prioritization, it was too little too soon, but it was the first stake in the ground on what came to be known as a framing memo, a step in the process for creating products.

Most merely wanted to know the release timing, since that was historically the first guidance from management. Office96 slipped nine months, painful and disappointing. Parallel releases proved brutal and the team wanted to make sure not to do that again. The memo announced one release, one ship date, and one product cycle.

The rest was mostly lost on a team focused on shipping a product that was later than we planned, though it was less of a debate across teams than when we began 12/24. The memo said we would have one of everything: one milestone schedule, one feature planning process, one specification process, one engineering process, one beta, one ship date, and so on.

Writing any memo always presented challenges, especially when the organization took everything in it as a requirement or an absolute, or the opposite, random musings from OPU. Starting a tradition, the memo explained itself and what it did and did not mean—it was a framework and any examples were examples, not specific mandates. At the same time there was a lot of subtlety because the absence of a mandate did not mean anything was possible. The polite way of saying this was that the spirit of the articulated direction needed to be followed. The impolite way of saying this was that the DAD organization was extremely empowered in a bottom-up manner, but this empowerment did not give the team the right to do dumb things or anything they wanted.

As a manager, writing a framing memo became an exercise in making sure I had a direct contribution at the start of every product cycle. Memo writing from execs and at length, other than from BillG, was something few did on the product side, though in marketing and sales, yearly memos created by the staff were the norm. It was important to me to put myself on the line like this.

The Office9 memo set a goal of a product plan memo in a few months called a vision memo. This was the first use of the term vision as denoting a product plan. Historically, a vision was more aspirational and less concrete, but I chose to call it such because I wanted us to feel that a release was itself an aspiration even if the document itself was supported by a concrete plan. It was a play on words for sure and some, particularly outside the team, were confused by the level of commitment to the vision. The vision represented our collective performance objectives and review goals, as an organization and individuals.

The vision was the plan. The vision memo became a signature process, and the hallmark of the machinery that became Office and later Windows through the middle-age of PCs. The process of creating a vision and series of offsites, memos, and communications became the subject of both emulation and some mystery. Teams always wanted to know who wrote the memos, when did I “approve,” or how were “decisions made.” While teams across the company looked to the artifacts such as memos, spreadsheets, and slide decks, the reality was it was the team that came together, and those artifacts simply reflected the collaboration versus driving the collaboration. Simply copying the artifacts ended up like the replicated food in the Squire of Gothos from Star Trek, knowing of “all of the Earth forms, but none of the substance” as Spoke remarked.

A unique characteristic of the vision is that it came from the product engineering team, and not a staff planning organization or the marketing team (as a market requirements document or product requirements document as they were often called in Silicon Valley). This was a key part of building a plan that was a combination of top down, bottom up, and middle out (using again those terms from Cape Cod). We were still a technology-driven company or organization with plans emanating from the engineering function. Incorporating the business aspects of the plan was an equally important part of the process, thus presenting a unified view of the entire business.

For the next months, teams brainstormed about what to build or what code to write. I was struggling with how to bring about a more unified approach to planning. I zeroed in on the vestiges of the product unit organization. Each of the GMs of the product units was still focused on a single product. I proposed to JonDe that we combine multiple apps into teams, broadening the scope of a GM while reducing the hierarchy of the organization (by having fewer GMs).

We shipped one Office box. In fact, while we had many SKUs of Office, the overwhelming focus and majority of business customers chose Office Professional: Word, Excel, PowerPoint, Access, and the new Outlook. This core product remained unchanged though different apps (or modules, as BillG called them) came and went over the next few years.

Sitting in the small conference room across from the big executive office on the third floor in building 17, JonDe and I worked to converge on a plan.

We settled on having an organization made up of Authoring (responsible for both Word and PowerPoint), Data Access (Access and Excel), and Office (OPU). This might seem simple but gave us two benefits. First, each of the general managers had oversight for two distinct types of customers, for example lawyers and consultants. Second, the opportunity for code sharing would present itself given the overlap in scenarios, for example the mechanisms for connecting to databases in Excel and Access.

With JonDe now leading all of Office, the logical successor for leading Office development was Duane Campbell (DuaneC), who was leading Excel through Office 97. Even though he was a development manager overseeing almost 50 people through Office 97, he still coded features in the product. He knew the code across every product better than most anyone and was clearly among the best engineers in the company. He also appreciated my Elvis Presley wall clock in my office. Grant George (GrantG) continued to manage Office-wide testing. Grant had proven himself during Office 95 and 97 as a supreme leader of large-scale testing. He single-handedly advanced Office in new ways.

We shifted more resources to OPU, and for DAD we continued to hire as many people from college as we could—everyone was involved in recruiting. Office became the onboarding group for the company and was brimming with the new-hire enthusiasm of hundreds of college interns and hires every year. We easily hired over one hundred full-time people from college every year, or as many as we could get allocated from the recruiting organization. I was taking two or three recruiting trips every year and would continue to do so for the rest of my career. I loved college recruiting.

One organizational problem we faced was that the newest member of the Office box, Outlook, was not even part of this organization. After the heroic efforts to get the first version shipped, the product was moved to be part of the new Internet Client and Collaboration division (ICCD) within the Applications and Internet Client group (AICG). After years of saying Microsoft would not have an internet division (“that would be like having an electricity division,” according to BillG at our Internet Strategy Day press event), an internet division was formed with responsibility for Internet Explorer, email, and many internet-focused products and technologies.

Org chart separations have the potential to take on a life of their own. Outlook was put in organizational proximity with the mail program, called Internet Mail and News, bundled with Windows 95, and eventually (and confusingly) renamed Outlook Express (code-named Athena, recall this was the replacement for Inbox from the Exchange team). The problem was that Outlook was designed for Exchange server. Outlook Express was designed for consumer mail and only worked with the internet protocols used by internet service providers and universities. In product reviews, Outlook’s support for consumer email was rightfully called anemic. Reconciling the strategy for the new Outlook product family became a high priority, especially since we already chose to name them as though they were related. The code bases shared almost nothing technically.

Outlook 97 was placed on a rushed product cycle to fix the deficiencies in internet support. This was a classic strategy that almost always backfired (as would be the case in this instance). What was supposed to take a short couple of months stretched out for more than six and resulted in Outlook 98 shipping in June 1998 (Office 97 shipped in November 1996). While the rest of Office was planning the next release, a key part of the product was working on what was termed an “out-of-band” release. Worse, the release was rather a hack in how the internet was supported. Running Outlook for the first time offered up a choice to run the product in Internet Only or in Corporate or Workgroup. The whole product had basically been split into a giant if statement. As a bonus, the product switched to a different installation technology, playing havoc with our total cost of ownership story. Outlook also missed out on planning with the suite. Yet we had just finished launching and selling LORGs on Outlook as an integral part of the Office suite.

The deficiencies of Outlook caught the eye of a future college-hire, Jensen Harris. He found the time to create add-ins for Outlook 97 that enabled it to do some of the things possible in Outlook Express and expected of any internet mail application. Jensen would go on to become one of the most significant contributors to the design of Outlook, Office, and then Windows.

It was all quite messy and the kind of crisis development that was rapidly becoming incompatible with the LORG focus of our business. We quickly regrouped with the Outlook team for the next release of Office, though as a result fell behind on the integration of Outlook with the suite.

This was literally shipping the org chart. We had to live with Outlook in this state as we planned Office9 and as we created and announced the Office organization.

If the framing memo was the first step of kicking off planning, the second was putting an organization in place. The planning efforts informed the choice of the organization, while at the same time the changes being considered, especially resource changes, inform the planning. Iteration of a feedback loop is crucial to moving forward while also avoiding lock-in based on organization.

We announced the org structure and had our first experience realigning the team and resources for a new release. That was easy. Not really, but it was done. Rolling out the changes and announcement was incredibly stressful for most everyone in management, on every side of the change. We even did a post-mortem on the announcement itself and collected feedback from a survey.

Everything felt new. New organization. Hiring many new people. New product mission. Even a new business with enterprise licensing and LORG customers.

I did learn one thing though as I walked around the halls and the cafeteria after the org change. By and large, most people didn’t really notice or care. They just wanted to know the ship date. milestone schedule, and most of all who their direct manager would be. That was a particularly good lesson for me. It reminded me of a story my Russian teacher from college told me at my 5-year reunion when we caught up. With the fall of communism, I asked him what his friends back in the former Soviet Union thought. He smiled a bit and just said, “Well, everyone still had to wait on line at the GUM department store the next day to see what was in stock.” A good reminder, that even in times of significant change, the local effects are what people pay attention to.

All the teams switched to using a variant of “9” for the names of the apps and we looked and acted like a single team, Office9. At least so far.

On to 048. Pizza for 20 Million People

This new chapter begins the middle of the PC era, starting in 1998, as I experienced. In a very short time, the industry from customers to suppliers, went through enormous change. It is easy to look at the products to see the change as we moved from 8-bit or 16-bit systems that could hardly power the software we wrote (that practically did not work) to 32-bit processors with 32-bit operating systems. Or to consider the change from character mode to graphical and to client server mode (both the fragile model as implemented across all the major platforms, and the loosely coupled model as the WWW embraced). Equally important, and perhaps even more so when it comes to how Microsoft evolved, is the transition from selling products where the buyer and user were the same person, a tech enthusiast, to selling products to an entire IT profession. The next three chapters detail that unprecedented transition and how it dramatically changed Microsoft. As we will see here, it was not just the products or customers, but the very nature of how the company was managed.

Back to 045. Incompatible Files, Slipping, Office 97 RTM

Since the organization was still in the early stages of creating Office first, rather than apps first, there was pressure and challenges that came from the race to start planning the next release. Apps figured if their plans could be put in place then they would be harder to unwind in favor of other ideas from the Office Product Unit. And so, the planning for the next product release began in an uneven manner prior to RTM for Office 97.

But over the next three product releases, almost seven years, the Office team and the business transformed. The era of apps, each operating independently, gave way to a coherent Office suite. The single user of productivity tools on a personal computer was the toehold upon which Microsoft built an organizational productivity toolset that became an integral part of IT infrastructure in large organizations (LORG). The focus on LORGs and the transformation of the business to multiyear enterprise agreements (EA) resulted in an increase in revenue, profits, and ubiquity of Office and set the stage for the business for years to come.

Although Office was sold as a bundle, it was built as independent, and award-winning, products. The next step was to build the product we were selling, an integrated productivity software suite.

The journey, however, was difficult and repeatedly pitted our efforts to build innovative and empowering software for individuals against the demands by IT professionals to reduce change and maintain a level of control over the ever-sprawling, always-connected personal computer.

These changes in the business and role of Office required the team to transform from a set of reasonably well-executing but independent entities, OPU and the app product units, to a single, execution engine. We needed LORG product development machinery to match the LORG business that was growing. Building software, at the time, was still too hit or miss, quality too uneven, and predictability lacking. These were all qualities that our new, and extremely large, customers were demanding of Microsoft. If we were to sit across the table from General Motors, the Department of Defense, or Proctor & Gamble we needed to operate at scale as effectively and maturely as they operated their organizations, even if we were making relatively newfangled PC software.

PaulMa was leading Platforms and had recently returned from one of his many trips visiting with CIOs and enterprise customers. PaulMa, more than any other product leader, was responsible for Microsoft embracing the dialog with CIOs most of whom were not from the PC generation, but began their careers on mainframes. Paul pushed across teams to engage with CIOs and even upgraded the Microsoft Executive Briefing Center against BillG’s wishes to provide a very deluxe setting for CIOs (and government leaders) from around the world to visit Microsoft and learn the latest in technology from the newly crowned leader. Upon returning from this trip, Paul wrote up his notes as he always did and proclaimed that he heard very little about “open systems” (as Unix was called). In fact, customer dialog had dramatically shifted away from open and towards “making Windows work”.

The root of the problem was a phrase total cost of ownership or TCO coined by the industry analyst firm Gartner Group. TCO measured the real cost of computers and servers in organizations, not just the cost of hardware and software licenses, but all the internal costs for training, management, upkeep, helpdesk, upgrades, and more. The numbers were astounding when we saw them. One of the first TCO reports from Gartner concluded that a Windows 95 PC connected to a network in a business costs almost $10,000 dollars per year.

Strategically, the Network Computer, NC, was a huge topic of discussion. The NC was a form of PC championed by Oracle and Sun that only ran a browser. That seemed crazy to us at the time. To the benefit of the PC, Gartner did not find these to be radically cheaper in terms of TCO. That did not slow down the conversation at all.

Paul immediately declared a war on TCO. As we’d come to expect from the Platforms culture, this was the new crisis. Suddenly there were meetings, offsites, slide decks (lots), and more. Platforms seemed to always love a good crisis. The thing was this was a real crisis.

Office 97 was very exciting for end-users, but between broken file formats, tons of new features requiring training, and especially because of the addition of email, we found ourselves essentially the enemy of IT professionals. Windows 95, so loved by consumers, was proving exceedingly fragile in an enterprise environment. There was great hope for NT 5 (no codename, which I totally loved), if only there was an Office to go with it. NT 5, however, lacked the consumer features of Windows 95 (and the follow-ons Windows 98, Windows 98 SE, and then Windows Me).  In other words, we had a product crisis on our hands due to TCO.

The people buying our product were IT professionals with an entirely different lens on product needs and capabilities. The buyer and the user were no longer the same person. Importantly, almost no one building products on the Office team had even the slightest experience working in an IT controlled environment.

Across the company this challenge could be looked at as a call for Microsoft to “grow up”, probably for the third time. Jon Shirley (JonS) joined Microsoft in 1983 after 25 years at Radio Shack, a great Microsoft customer. He came as the company was growing rapidly to bring a classic model of experience in scaling a small company. MikeMap and PaulMa brought a product development maturity five or so years later.

Now Microsoft was at a scale where no single person could up-level the company. Instead, we began an era of formal management and training as a way of instilling at least some common set or baseline experiences. These “HR courses” (Human Resources), as we called them, would become both objects of ridicule (I mean who doesn’t make fun of HR courses) and also brought a lingo and way of talking about Microsoft that we could at least share across the three different cultures in the headquarters product groups (Apps, Platforms, Online).

We experienced enough challenges building Office 97 in how different parts of the team worked together or even communicated with each other. Across the company these difficulties were compounded to the point that cross-company work was often hit or miss, as I personally experienced going as far back as building tools for NT 3.1. By the late 1990s, it had become all but impossible for people to even move across cultures and when they did often successful people would experience a form of organ rejection. As an example, one of the strongest leaders in Apps was asked to move to NT to bring a bit of apps program management to the team. He ventured over to NT and lasted only months before he roundtripped back to Apps, both sides convinced it was a horrible idea. Multiply this by dozens of people, the need to collaborate on code, and now the customer demand for products to work together in new ways and this was a huge problem.

Leading this charge for HR was NatalieY. Natalie who was the cultural beacon of the company and had recruited me to work for BillG was determined to help Microsoft mature. She hired many people who developed a broad curriculum and took so much grief for the work they did, though ultimately it was Natalie who convinced a skeptical BillG, SteveB, PaulMa, and many others to endorse, participate, and encourage the formal training.

This was not without a few early disasters, at least a disaster as far as a group of us were concerned.

Forming, Storming, Norming, Performing

When it came to these HR classes, I reacted as anything but supportive and open to them (as was the case for most engineering brains). I always felt I had my fair share of touchy-feely training as a resident advisor in college, where I underwent countless hours of introspection and sharing.

In fairness, however, I learned vocabulary that proved useful over the next years as a manager and leader. Like almost any of these extracurricular experiences (they were never required), what tended to make them most valuable was not necessarily the content but the timing of the content relative to what was going on.

One straightforward class was on organizations and teams. Its singular takeaway was the framework for how teams evolved. Tuckman’s Stages of Group Development was from the mid-1960s, but outside of an HR class there was no chance I would have been exposed to this. The timing of the class was perfect.

As the research described, a team goes through phases of forming, storming, norming, and performing. With this framework we discussed examples from our jobs. It was simple and non-controversial. It helped me to put the conversations JonDe and I had with ChrisP and PeteH in context—that idea that the Office team had lost its marbles.

The OPU and Apps teams were all in different stages of team formation, and at the same time individual perception of where the team was might not have coincided with an objective measure. While Excel as a team might have thought it was performing, that was only the case so long as building Excel was the goal (Excel was clearly our highest performing team at the time). The Office team finally shipped features in Office 97, but to say it was beyond the early days of norming was an exaggeration.

I walked away from the class believing all of DAD (which we continued to call Office, though that name would not be our official division name for a couple of years), OPU and the Apps, were organizationally much earlier than the business results would have us believe. In many ways, we were still storming. Looking at the reviews of the product and where customers were, we could also say that Office suites were slightly ahead and customers were beginning to see suites as normal, especially customers that adopted Windows. The class was a wake-up call to not assume anything about how the team operated as we developed the organization and plans for what would come next.

Each one of the spinning plates of Office maintained a process for ideation, planning, and execution, but we needed a process to bring these together and to scale from teams of dozens to a single team of hundreds. There was no playbook, and we knew that at this point while other parts of Microsoft were having their share of (enormous) success, there were no repeatable processes to emulate.

We needed to invent a new Office process while also building a new Office.

Another HR class became an accidental legend and provided endless entertainment and stories after the fact. A selection of about two dozen people from the product groups, including JonDe, ChrisP, me, and many across major divisions, were invited with few details to a training offsite. NatalieY picked a selection of cool kids or influencers as we would say today, assuming we would endorse the experience and more would choose to participate.  

We were sent reservations for travel with no lodging, just a flight. We flew to Boston (mysterious) and then took a small plane (like Wings) to Cape Cod.

There was a lot of eyerolling.

Upon arrival in the tiny airport, our luggage, wallets, ID, laptops, and new Motorola StarTac and Nokia 6110 phones were confiscated. We learned that before our arrival, leadership for the United States Postal Service had just experienced the retreat and loved it, which seemed to worry us. We were taken to a primitive location, a sort of religious summer camp where we were divided into three groups. The first were “tops” (I did not make up these names), who received instructions prior to the training, arriving a day earlier (JonDe was a top). The tops were assigned nice rooms. The second were “middles,” who were given group accommodations. The largest group were “bottoms” (of which I was one), and we were given what appeared to be the kids’ bunks with no linens.

Over two days, the middles were given various goals from the tops and some resources to carry them out, such as clearing dirt paths or washing picnic tables. In turn, the bottoms worked to accomplish the goals in exchange for provisions (like sheets or food). Our first assignment, we spent a few hours clearing leaves in exchange for lunch. We were trapped on the Cape without any communication tools at all, not even a payphone.

It was not going well for me—while I spent many summers camping in a tent, it was by choice. Being forced into this, with no idea what was happening, was not cool. I began plotting my own escape but couldn’t even find a phone, plus I had no money though I had my AT&T calling card number memorized if I could just find a pay phone. I was not alone. In fact, one person actually escaped by hiking to a nearby gas station and using a payphone. He caught a flight back, abandoning his luggage and laptop. He wasn’t just complaining like me, he literally escaped the island.  

At one point, I was serving dinner to JonDe, as a way to secure linen for the evening. We were told that the next day we would receive richer tasks and be given more exciting things to do. After sleeping in a bunk bed with a sheet and using a washcloth for a towel, the next morning we were given tools to create an economy, so to speak, and we could do things for money and stop bartering.

It felt absurd. ChrisP, also a bottom, devised a coup in hopes of ending the farce. We took the supplies for the “town” and everyone started creating art—paintings and drawings, and such, and selling them to the tops at inflated prices and then buying each other’s products at even higher prices. In other words, we flooded the economy with money. We ended up with more money than there were provisions to buy, and the game literally collapsed. The organizers were alternating between laughing and crying. Hungry and stinky, I took to yelling at one organizer, who eventually shut down and walked away.

We broke the entire system, cutting the entire simulation short by two days. We thought we were clever. Really, we were kind of a bunch of jerks. Just horrible. When I think of how I behaved at this course, I have nothing but regret. Forget needing to mature for CIOs, as a group we needed to mature as human beings.

Game over.

We learned that the workshop was a famous organizational behavior workshop based on some important academic research. They conducted this exercise (at this same location) hundreds of times before and never anything as crazy had happened. Suffice it to say, there was a sense of old-school Microsoft pride in having hacked and destroyed the entire training exercise.

However, all was not lost. We walked away with a set of important lessons about organizations—though to be fair they could have interoffice mailed us the pamphlet and skipped the trip. The essence of the experience was to better understand the power dynamics across different strata of an organization. We tend to think of tops being in charge, middles balancing the needs of the bottoms and tops, and bottoms as victims. In practice, every individual can take on the behavior traits, beliefs, and coping mechanism of each layer. Every role is a bit of each layer or caught between competing layers.

As crazy as all of this was, the core idea of bottoms as victims, tops as all knowing, and so on being highly context dependent did in fact have an impact on me. Years later, a friend in HR begged me to go to a three-hour version of this workshop held at Microsoft. For years I forbade anyone on the team from participating in this class out of retaliation for my suffering. I conceded and found the short version to be quite beneficial, and I recommended it for many.

In reflecting in several email threads, the most important lesson for me was that while a group of us really hated the training, there were people that did not mind it and some even liked it. In fact, some of the people from Platforms wanted to have a follow-up. Perhaps that spoke of the diverse cultures more than anything.

Still, the legend of breaking Power Lab is one for corporate history.

Note. The internet is filled with experiences teams and companies have had with Power Lab. A search yields many extremely positive discussions, and not a single description of breaking the simulation entirely. In 2005, I wrote of my experience for a MSDN blog. I detailed the lessons more specifically. The post is available via archive.org.

On to 047. Don’t Ship the Org Chart

Back to 044. Our First Big M&A Deal (Beating Netscape)

Please keep the feedback rolling in. This post concludes with shipping Office 97. It represents the end of the first era of the PC, where the focus was on features, retail consumers, tech enthusiasts, and mostly just getting stuff to work and shipping. The next couple of chapters represent a major shift in the PC as the focus turns to the enterprise business and the primary customer the business itself and professional IT.

Office96 was quickly becoming the biggest slip to an Office or Apps release in years, and that was extraordinarily disappointing. We reached our Zero Bug Bounce milestone (ZBB, because for a brief moment the product would bounce around a mythical zero bug count) in July 1996, and that was great. We were also behind our original schedule by months, and we knew there was no way to catch up. We needed more time. We felt like s**t.

I did not always go to lunch in the building 17 cafeteria but happened to go one summer day. I was waiting to pay, holding my two slices of Marriott cheese pizza, when I heard, “SINOFSKY! SINOFSKY! WHAT DO YOU MEAN YOU ARE CHANGING THE FILE FORMATS?? WE CAN’T DO THAT!”

SteveB was yelling across the cafeteria at me, and all of a sudden, I felt like a few hundred people got quiet and were watching to see how I reacted. His voice seemed to come from everywhere, so it took me a moment to locate him. A 10-minute conversation followed that started in earnest as he made his way toward me about the reality that Office 97, as it had been officially named, had a whole new architecture with loads of new features for document creation like drawing and fancy Word tables, animations in PowerPoint, and new charts with top-notch graphics in Excel. Word and Excel changed the file formats to support these features. A changed file format meant a customer file such as FOO.DOC or FOO.XLS on disk was only compatible with the version of the app that created the file, or a newer version. Trying to open FOO.DOC created with Word 97 on a Word 6.0 setup would give an inscrutable error message. This message would often terrify the user into thinking they had a corrupt file or the computer had eaten all their work. This horrible experience was perfectly normal for state-of-the-art software. I kid you not.

Well, it turned out that the strategy of not changing the file formats in Office 95 (at least for Word and Excel) was a huge hit with the field sales force. So much so that they thought it was our new strategy to maintain the same file formats forever. When, in fact, we thought of 95 as the exception and only way to sync up with Windows 95—we had spent a ton of creative energy arriving at sellable features that did not require a file format change but were severely constrained in doing so.

I never really thought of mentioning this because it was so obvious, or so I thought. Steve thought we were totally screwed and had misled his sales team.

The file format changed probably within the first weeks of the project and was standard industry practice. The success of Office 95’s unchanged file formats caused a bit of a crisis as we were working on Office96. It was obviously both too late and impossible, regardless, to reverse course. HeikkiK coordinated what could best be described as a crisis mitigation plan involving format converters for existing applications and Save As capability within the new versions to produce down-level files (with the risk of losing new features). This was a reasonable solution but would require organizations to install software on every PC, whether it was just a converter for existing computers or the whole new Office 97 on new PCs. In other words what we thought was reasonable was a huge pain. SteveB was right.

The Apps culture was tuned to avoiding crisis moments, usually by rewarding prevention, and a low tolerance for avoidable drama. When a crisis did hit, self-inflicted or otherwise, the Apps approach aimed for cool, calm, collected. ChrisP often described this like listening to the cockpit recordings of Naval aviators landing jets in difficult circumstances. That calm was accompanied by an executive team that did not view a crisis as an opportunity to micro-manage or upend existing processes.

As a result, we thought this through in excruciating detail. All of the test managers and PMs from each team had developed a complete plan to support the new file formats in old products and deliver product updates to existing products, even using the novel approach of internet downloads. This did not solve the physics problem that we could not make the new features of Office96 show up in Office 95 or Office 4.3, but we could ease the pain and prevent people from being unable to open files they received due to the growing use of email.

One bit of good news was that the biggest motivator for changing the file format was to support the new world-wide standard for representing text in computers, called UNICODE, that Microsoft had contributed a huge amount to. Up until then, PCs had a difficult time representing many of the world’s languages and mixing several languages at once was almost impossible. UNICODE was a major step forward and for multinational corporations, the ones complaining loudly to SteveB, easing the pain of multilingual documents was a significant win. A decade later, UNICODE would become familiar to everyone as it supported Emoji.

This was a rare crisis for the team and a good learning experience to the degree that foisting incompatible files across a corporation could be called a learning experience. As an organization this did bring us into the modern, Office-focused world in two ways. First, the crisis created a new muscle, which was driving change to core behavior across all the products. That had to happen. It was the first of what could be called suite-first problem-solving and coordination.

Second, this was such a pain for every team that it served to be an early dose of the enterprise business and what would be different for the team. The needs of enterprise customers became paramount as we moved to future releases, and the solutions to those needs were addressed across the entire team.

Still, this was my first of many, many lessons in the difference between consumer products and enterprise products, between selling at retail and selling through account managers. Because every product always changed file formats, this should have been viewed as routine. But the world had changed—seemingly overnight documents were being emailed around, and all of a sudden it was all too common to get files that could not be opened. In a sense this was really a crisis for the Office business and one that would cause a sea change in how we viewed files. It also happened to be the strength of the internet and the World Wide Web—one single format that could be read by any browser, and soon one language that could be used to write a program once and run it anywhere.

Beyond that it was a lesson in how Microsoft’s customers were changing. The technology enthusiasts who embraced changes and had a high threshold for the pain that random changes caused were being replaced by system administrators and IT professionals who were not only change averse, but often barriers to change. The file format incident was a warning sign for what was to come, not just for Microsoft but for me personally as I had to reconcile innovation with a customer base that was becoming less interested in technology changes, which we thought of as cool innovation, and more focused on the costs of those changes, which we thought of as simply necessary.

Strategy changes don’t always come with a moment, but it was clearly this moment when it became clear we would move Office files to be open and to use the format of the internet, HTML. This would prove to be enormously controversial with BillG as the very origin of Apps, specifically Word, was the invention of the Word .DOC file format, which was a key, and proprietary, competitive advantage. It was also a technology Bill knew well.

By the Fall, Office96 was approaching the finish line. The team was tired. We were nine months late off our original schedule. We felt it. Nine months late was kind of inexcusable, but relative to the rest of Microsoft and the industry still well within norms. More than the feeling of exhaustion, we were feeling that as much as we accomplished, we had also not executed as hoped.

We were hard on ourselves for the slip. The routine post-mortem that would follow was filled with genuine discussions of trying to figure out how not to repeat this slip, even if it was also the last release we would talk about Office versus the Apps.

Even with exhaustion there was much to be proud of. The product cycle was difficult, but we did not experience any sort of death march. Yes, many people put in long hours. While many teams would do a “bug bash” one night in a week, we were not catering food every night as was common practice in other parts of Microsoft. Babies were born. People were married. There was all the life experience that happens within a group of 1,000 people over three years. Relative to the rest of the company, we ran the project with a sense of balance and normalcy. The core tenet of our process was that we arrived at the schedule and dates from bottom-up estimates, and when those estimates were wrong the individuals worked extra or we scaled back features—both of those were viewed as acceptable. We did not seek out heroes. We were proud of that. And we would get better at estimates, accountability, and balance each with release going forward.

The release to manufacturing, which came about six weeks before launch, was on a cold and rainy November 16, 1996. A few of us were at COMDEX in Las Vegas doing press when HeikkiK led the team through the final ship room meeting and signoff. He was kind enough to call in and I spoke from my flip phone but might as well have been in outer space—the connection was horrible. Still, the sense of accomplishment was as real as the relief. From afar I wished everyone well and knew there would be one heck of a party on campus. And there were pictures to prove it.

Marketing was gearing up for a launch and did a fantastic job creating awareness and a retail presence, and for the first time gearing up an ever-growing enterprise sales force. The industry had grown so much creating a massive demand for press coverage unlike any we had experienced. Every paper in every town in every country seemed to have a tech section. The summaries of press coverage were growing ever longer, and the skills the Office marketing had to get the word out in a consistent and clear way were growing with demand.

The launch was subdued relative to Windows 95, and that was by design. Late 1996 was mostly about the enterprise and servers so Office focused on those elements of the product.

While Office 95 was viewed as a significant release, the realities of a 200-page Office 97 reviewers guide detailing all the features of the product really sent the message that Microsoft was all-in on suites and had unparalleled depth and breadth to offer. The plethora of features in the product and breadth of tools kept the technology press busy and excited. The phrase shock-and-awe was routinely used to describe the overwhelming depth and breadth of the newest Office suite.

The reviews were extremely positive. Office 97 garnered nearly all the major awards across magazines, which at the time were a big deal. BYTE, PC World, PC Magazine, and more each recognized the suite and individual applications as editor’s choice or world class.

Clippy became the most controversial feature, even to this day, in productivity software. Even the reviews were controversial, with key mainstream reviewers citing both innovation and acknowledging the problem needed addressing. The late Steve Wildstrom, the widely read and deeply respected columnist at BusinessWeek, wrote, “I was deeply skeptical about these omnipresent artificial-intelligence devices. But to my surprise, I found the animated assistants useful—and a feature that sets the new Office apart from competing software suites.” Quite a few reviews were initially skeptical, and then using the product turned them around. For example, PC Week said, “Office Assistant exceeds my expectations: It's not only visually effective, it's also more than superficial in the help that it offers to even a veteran nerd.” These comments gave us hope, gave me hope.

Still, there was a love/hate relationship with our assistant friend. Clippy immediately became the stuff of legend when it came to the reception among the core technical customers in IT and tech enthusiasts—the kind of users that know all the keyboard shortcuts and don’t want anything to get “in the way” of their work.

I learned something in how this type of customer chooses to express distaste for a feature. Rather than directly say, “I do not like it” or “I will not use it,” these customers generally stepped up and claimed to speak broadly for “typical end-users,” often talking about their mothers or grandmothers (always female, to represent someone who is not fully versed in the product). In the case of Clippy, we would often hear that this is not the right feature to help “those users like my mother or grandmother needing help.” This projecting of product concerns rather than owning them directly would be a valuable lesson and something I would carry with me when bringing new features to market that must make it through these gatekeepers.

The negative reviews of Clippy were fairly brutal. I think everyone used the cuteness of Clippy as an invitation to spice up the language used to insult the feature. Stephen Manes in the New York Times wrote, “ . . .help is presented solely in the form of dialogue balloons attached to one of eight cartoon characters, most of which make irrelevant, distracting movements and sounds until you turn them off. . . . But these toon-zombies are as insistent on popping up again as Wile E. Coyote.”

That really hurt.

Most unfortunate, though, was how the feature could be construed as a symbol of Microsoft losing touch with customers, especially in this era of heightened scrutiny on the legal front. We were wrong, but not because we had lost touch—we were wrong because we went overboard (and in the wrong direction) trying to make computers easy to use for a much larger audience.

Still, we had pushed through a final design change to enable the assistant to be turned off. The change was easy technically, but difficult emotionally. Our goal was for Clippy to be an ever-present but unobtrusive assistant (Agent was the term at the time, today that would be Bot), thus turning Clippy off was an admission of failure. Making this possible was quite hard on the team given how far we had come from Bob through “tfc” and beyond. That is all the techie crowd needed, and with that most of the business deployments of Office 97 had no ever-present Assistant.

These reviews mattered. Reviews of products might seem old school in a world of instant hot takes in social networking and especially with products where bugs or errors can be fixed on the fly. In an era when software could not be so easily changed, publications assigned several people over the course of weeks or more to dig deep into a product, and our own marketing touted excerpts. These reviews really carried weight. We had a reviews team in marketing, 3 or more full-time people plus a reviews team at our PR agency working broadly with all the outlets, and this was repeated in most major subsidiaries, especially Japan, Korea, Germany, and UK. At the peak (over the next product cycle) there were easily 100 reviews being executed in the US. The marketing team was on a plane for two months meeting in person with all of these. I would visit dozens myself. There was a constant stream of communications fielding questions, dealing with bugs and compatibility, and offering support for demos and more. There was a growing parallel effort working with the rising importance of IT industry analysts. Analysts such as Gartner Group would soon eclipse the traditional tech reviews in importance to our business.

It was not without controversy that we focused so much on reviewers. This was an era where they could be characterized as a form of gatekeeper. It was no doubt limiting as any one reviewer represented a narrow perspective compared to all customers. There were no real alternatives. In many ways the internet would come to save us and enable a product as broad as Office to reach many more customers directly with more tailored messages, content, and calls to action. The changes in how we reached customers coincided with the maturing PC and PC industry.

Two reviews really stood out as defining, not defining the product in market as the product went on to great success but defining for me personally as a “product person” and also a leader. Stephen Manes, who had obliterated Clippy, was by most descriptions a curmudgeon and it would be difficult for me to say something he liked. We once debated whether a specific Sony laptop (the 505) was good compared to an Apple PowerBook in a session that went on for most of a press event at CES. His complete review, however, of Office 97 had a headline (keying off his description of the product) “An Upgraded Leviathan Sets Sail.” This was a brutal shot. It characterized the product as, in a sense, just another release while also describing it as, well, a leviathan. The text of the review is painful for me to read even today.

I will say for the record that one part of his review I often talked about was that he called out the addition of word and character count in the status bar of Word. While it surprises many professional writers, most people using Word never used the word count feature because most writing is not tracked by that metric. We did, however, add it to the status bar by default for the press who lived in Word. We have no shame about that. They were an important constituency. True to form, I think most reviews mentioned the feature.

While I hung that review on my Office door as I did many others, I also went to the office supply store and purchased a portfolio case—a plastic folder with a dozen or so clear sheet protectors in it. The first thing I put in the first page was the leviathan review. After that I put a few pages that I would carry around all the time and update as needed—the list of teams, senior managers, total headcount, ship schedule and milestones, data sheets on competitors, top support calls, and so on. It was this review and the next one below that I would talk about and hold up at team meetings when describing our challenges as a business, especially as we planned future products.  

Much more problematic was Outlook’s reception as it was not a single feature to turn off after making fun of it—but rather a marquee addition to the suite, a new “puzzle piece” (the Office logo was a puzzle with each app taking on a different color). The absence of support for internet standards as well as the overall complexity of a version 1.0 product led to a series of fairly brutal reviews. Perhaps the one that stung the most came from the Wall Street Journal with the title “Microsoft Introduces Personal Organizer That’s Unorganized” and zingers such as:

The combination is so tempting that Microsoft incorporated Outlook in its showcase $190 Office 97 suite of software, and rejected the commonly used PIM [personal information manager] label for it, calling Outlook a “desktop information manager,” or DIM. Sadly, that unfortunate acronym is apt. Outlook 97 doesn’t live up to its potential. It’s a great idea, poorly executed.

What was an internal joke between the now rival Exchange team and the Outlook team was a review. The review concluded, “Microsoft has a history of doing a poor job on the first version of new products, and Outlook fits that pattern.”

The reporter, Walt Mossberg, had a broadly read and widely discussed column, Personal Technology, aimed at taking on the techies of the world and makers of overly complex products. He was the clear leader in the point of view that, in his words, “Personal computers are just too hard to use, and it isn’t your fault.” He would challenge us, consistently, repeatedly, and objectively. He played no favorites and was perfectly straight in dealing with us and any vendor. There was no way to exert undue influence over him, no special treatment, nothing. We showed him the product, answered his questions, tried to fix any issues, and waited for the review, then he returned the product and loaner laptop to us promptly.

Walt’s contribution to encouraging or pushing Office do a better job is something I have shared with him many times. I have enormous respect for him and what he accomplished in his column (and later the conference he cocreated and then a media and technology publication site). His keen reviews profoundly influenced buyers and makers alike.

The complexity of Outlook and Walt’s experience ironically deepened our ties. Walt began sending me questions and comments from his readers and I would often answer the myriad “how-to” or “why” questions he received. I never resented or tired of receiving these, and later felt nostalgic about them.

Walt was right about Outlook, and we had a lot of work to do.

I can’t exactly compare what our team went through to a battle or a traumatic experience, but we did have a shared experience that changed the team dynamic. It also came at the right time as the industry was changing dramatically right before our eyes. Teams are built by going through a journey together. When I reflect on Office 97 I am convinced that the journey to build the product is what created the team and culture that have been so enduring, even today.

Office 97 was the last release to be sold primarily to individuals at retail. It was the last release to be marketed significantly as app features. And it was also the last release to be built as independent applications with shared code versus a shared strategy.

PCs were the new onramp to the information superhighway. The internet had become a global phenomenon driving PCs into every home, as Bill and Paul had envisioned more than 15 years earlier. No longer did demand need to be created for PCs; it needed to be met. For Office, all those PCs getting on the internet were being used for schoolwork, homework, and work at home using Office.

PCs were also standard on every desktop in the business world, as Bill and Paul had hoped. The race was on to equip workers with all kinds with PCs, to get them email, and to provide them with the tools needed for the creation and dissemination of knowledge. Office was a standard part of this.

We needed to scale our product development approach to meet these needs and scale.

In terms of PCs, dollars, documents, and customers, millions would turn to hundreds of millions and hundreds of millions to billions.

We were at the “end of the beginning” of the PC Revolution—the first part of the journey dominated by hobbyists, tech enthusiasts, and early adopters. The PC was now front and center in a revolution taking place in business and Office was destined to be a foundational element of the computerization of work. Over the next twelve months, PCs would sell more than 100 million units and more than half of those were bought directly by businesses. The PC was no longer a hobby or a luxury, but an essential element of business.

For me personally, Office 97 marked both an end and a new beginning.

On to 046. Prioritizing a New Type of Customer [Ch. VIII]

Office had been early and aggressive inserting Internet technologies across the product, including hyperlinks (so new!) and HTML, as well, sort of, email with Outlook. We started to notice a challenge for us—web sites were not single documents but collections of documents. Office was not particularly useful for dealing with collections of documents (except for the failed Binder experiment).

We were about to enter the fray, going head-to-head with Netscape to acquire a “hot” internet product being developed in Boston.

Back to 043. DIM Outlook

We enjoyed a very fancy and atypical dinner at Daniel's Broiler on Lake Union. Chris Peters and I were hosting the co-founders of a Cambridge, Massachusetts startup, Vermeer Technologies, Incorporated. It was awkward. Only after would we learn that none of us knew what we were doing and we were all nervous and kind of terrified.

If email was the biggest application on the internet, the technology that was causing Office the most strategic concern was HTML publishing pages to the web. When it came to web publishing, figuring out the role, if any, Office would play was much more difficult. The internet was quickly splitting into two camps. There were those who were hand-crafting sites in HTML. Using basic text editors they pushed the limits of HTML to do everything in the browser—going all in on native HTML, which at the time did not even support basic tables or much of anything. Then there were those who would navigate with HTML until at the very end a link pointed to non-HTML documents such as PDF files (almost like the eventually extinct Gopher application), particularly inside the earliest corporate web servers called intranets or the new consumer web sites from print magazine publishers

Our approach was to find ways to use Office to create HTML content so it could be viewed in browsers even without Office—in a sense the idea was to turn the World Wide Web into the next generation printer or workgroup file server for Office. Except we had two big problems. First, HTML was too minimal to support any common business documents, even as a “printer” so to speak. Second, from a PC there was no way to emulate the Save dialog to save a file to a web site. As much as we had a vision for these intranets, the technology was not there yet. We had to invent something.

The Internet Assistants across the apps bringing HTML add-ins to market for this “print-to-the-web” scenario was a level of agility that Office had not yet exercised, with much of the work happening while both Office 95 and Office96 were under development. A key person in those efforts was Kay Williams (KayW), a program manager on the Word team who had worked on getting Word’s first Internet Assistant to market just in time to beat Netscape 1.0.

At one of the internet conferences in Boston, Internet World, in the fall of 1995, Kay spotted the demonstration of a product called Vermeer (named after the artist) by the company cofounder Randy Forgaard. Kay fired off mail to the Word team highlighting Vermeer’s WYSIWYG HTML Editor (What You See Is What You Get, an editor that showed what the end result would look like while the document was being created). The product was especially clever. It not only edited HTML pages, but it had a new model for managing a full website collection of pages.

Nothing like that had been done before.

The technical challenges of typing a web page were understood, but no one had invented a way for less technical people to create a whole site. A site needed a home page, navigation aids, and a way to link all the pages together. This was something that many of us were experimenting with at the time as we all raced to register domain names based on our last names or other pet projects. Creating web pages was tricky enough but managing a collection of pages and especially doing basic things like collecting information from a form were equivalent to programming. Vermeer seemed to address this. I had been using early versions of the HTML assistants to share digital photos (taken with the Epson PhotoPC, one of the first consumer digital cameras, which I had found for BillG to give as a gift to the exec staff one holiday). I pulled together a bunch of photos and created a PowerPoint HTML slideshow. I did this for a trip we took to the USS Ohio nuclear sub in Bremerton hosted on my original sinofsky.com. That was the early world-wide web.

Several of us tried the Vermeer product and were all impressed. We later learned Vermeer was keenly aware from its server logs that Microsoft people had downloaded the product, decidedly something we were not used to. Sitting in ChrisP’s office he was pondering the idea of approaching the company to see what could come of a relationship with them. Chris was many things but not usually spontaneous, so for at least an hour we rehearsed a “cold call” to the company CEO with an offer to simply meet and see a demonstration. It was kind of exhausting and very ChrisP.

After some discussion and rehearsing the call, ChrisP picked up the phone and dialed directly to Charles Ferguson, the CEO. Much to Chris’s surprise, Charles picked up the phone. At first, I don’t think Charles believed the vice president of Office was calling. Chris was probably more nervous, even though he joined Microsoft when it was tiny he had mentally transitioned to being used to Microsoft scale. Since PowerPoint, the Office team had not done any M&A, and it was certainly new to Chris and me.

After chatting for a bit about how excited he was to see the product, “HTML for the masses” and describing how much the design and feel of Vermeer reminded him of an Office product, Chris invited Vermeer to Redmond. We would have gone to Cambridge but they were just as happy coming out here. By this time, we had already demonstrated the product to BillG and Chris made a point of telling that to Charles. Chris was convinced Microsoft should acquire the company.

Microsoft was not a particularly acquisitive company. Since going public, Microsoft averaged less than one deal per year. The Applications group had done only a single deal, but it was a huge winner—acquiring Forethought, Inc., the makers of PowerPoint. That $14 million dollar deal (Microsoft’s revenue at the time was $345 million) and the way the product was integrated into the company, set the bar very high for Apps.

None of us were well versed in the intricacies of venture capital nor did we know at the time two important facts. First, Vermeer was in the process of fundraising, which might not have mattered except it had a big impact on the purchase price of a company (I vividly remember having this explained to me). Second, one other company had called and expressed interest and that was Menlo Park–based Netscape. Marc Andreessen was also going to be visiting the company.

Charles Ferguson and co-founder Randy Forgaard arrived in Redmond. It was nerve-racking for all of us. The two were as awed by the scale of Microsoft as they were petrified of the Microsoft reputation that preceded. It turns out Charles was somewhat skeptical of Microsoft as a company. Prior to co-founding Vermeer, Charles authored the book Computer Wars: The Fall of IBM and the Future of Global Technology, which among its chapters describes Microsoft as having a strategy focused on locking customers into products.

Nevertheless, the demonstration and the team were a hit. We had arranged a fancy steak dinner at the Seattle institution, Daniel's Broiler. The conversation, at least our side, was rehearsed and practiced days before. We had no intention of trying to extract information or anything more than size of the team and so on—we had decided the product was exactly right, “105% of what we had been thinking” Chris repeated from the phone call. We were trying to get to the next stage of a deal. Chris had developed a salvo that went something like, “We would love to work with you more closely. We might consider anything ranging from a lightweight marketing arrangement to a source code sale or perhaps all the way to possibly the full meal deal.” Much to our surprise, Randy and Charles did not skip a beat and were open to acquisition, even downplaying lesser options.

And like that, Chris and I found ourselves totally in over our heads negotiating the purchase of a company. We enlisted the help of Microsoft’s treasurer and soon-to-be CFO Greg Maffei (GregMa)—my former office neighbor when I worked for Bill. Greg quickly educated us on all sorts of things we did not know about: Series B financing, percent ownership, pre-money, and more. Greg even came up with some clever idea of a bridge loan in case they needed payroll, in an effort to reduce the need for them to raise the next round.

With the help of Greg, we met in the fanciest boutique hotel I had ever seen in New York City (GregMa picked it out) and negotiated over a pot of coffee that cost $80. It was an amazing experience to watch Greg negotiate the deal. We did not reach a final offer in the room, which was Greg’s strategy. We flew back, agreeing to send a new offer in 24 hours. The response to the next offer was not a yes. We were worried. We did not know it at the time, but Vermeer was worried too.

In the midst of the negotiations, on December 7th Microsoft held a briefing, Internet Strategy Day, for the press at the Seattle Center. It was a huge event with international press, not a single one could resist the Pearl Harbor theme. The big news was the licensing deal for Java crafted by the platform team. Among the many demonstrations and strategy slides, Office would demonstrate the role intranets would play in the modern workplace. Our team had prepared a “vision” demonstration that I did on stage with BillG. The key features included publishing to websites from future Office tools.

The Vermeer team saw exactly how committed we were to web publishing and the internet. They also concluded, though did not share at the time, that joining forces with one of these companies would be a better way to achieve their vision than competing head-on.

We started to get worried and knew they were also in talks with Netscape. That was enough to pique the interest of PaulMa in Platforms. Charles pressed Chris that a deal could be had and offered to fly back to Redmond to do a demo for BillG, PaulMa, and other key executives (he was specific). He did, on December 8th. That demo by Randy sealed the deal, probably as much as the body language and Randy’s impressive demo skills and passion as it was about the interest from Netscape.

A little more back and forth and we had a deal, and Netscape lost out or passed or whatever. For a brief moment, it seemed very cool to us that we had won out even if we kind of also felt it was our deal to lose. I mean we were Office. It felt a bit weird to be so focused on such a tiny company among all the scale of Office, but we were deeply convinced that web authoring was a future for Office.

Just after the papers were signed, I flew to Cambridge with Chris to help to make a good impression with the team, at least we hoped. The success of the deal relied on successfully hiring almost everyone and also moving to Seattle. That’s how deals were done then. I had previously visited companies at this stage and knew how tense employees could be. The fact that Microsoft was viewed as a cross between The Borg and a Death Star did not help. When I visited Intuit at this stage, some things our group said about culture did not go over well, so at least I had those lessons. Chris of course was masterful, as he was one of the most tenured and respected engineering leaders who had progressed to lead the biggest business at the company. I filled in with details of strategy and other details, most of which I said Chris would be handling and no one had to worry. Most of the team had read mainstream press and certainly everything in the industry was skeptical of Microsoft on many dimensions. The just-published Douglas Coupland book, Microserfs, was making the rounds and that didn’t help either. Generation X was much better, but I digress. I found myself trying to unwind serfdom and settled on ordering copies of the just completed Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages, even though I disliked the title. We cooperated with the professors writing this book and I found it to be an accurate and detailed description of how products were built at Microsoft at the time.

Most all of the engineering team ended up making the move, which was a huge success. Several could not relocate due to family reasons and were offered roles in the regional office.

The deal was announced on January 16, 1996. It was announced for $130M, almost ten times the PowerPoint deal and an enormous deal for Microsoft at the time. We watched the stock price that day, though we rarely did, and it was up enough at the announce to pay for the deal. Having just finished the crash course in venture funding and deal-making, we then began our crash course in M&A regulation and learned about all the FTC filings and the process. Microsoft was under investigation for antirust and everyone was quite worried, as just a couple of years earlier a deal to acquire Intuit, makers of Quicken, was scuttled due to regulatory concerns. We worked through the process and won approval. We got a real kick out of the requirement that Vermeer would need to remain an independent company, in other words Vermeer.com for email and the web site, and other accommodations such as which entity would own the source code.

ChrisP decided it was time to dive back into code and return to the engineering and product scale he loved. He dedicated himself full time to Vermeer, leading the team as VP of FrontPage, complete with a new Vermeer business card. He was incredibly energized and even wrote code. He quickly added an Insert Hyperlink dialog to match the one in Office.

What ChrisP did was an example of a golden rule of any acquisition—always have someone of seniority willing to bet their career on the outcome of the deal. That means someone willing to change jobs, integrate themselves into the appropriate place in managing the deal, and signing up to be there until the next logical step (almost always further integration into a broader organization or the separation of the business into something needing a distinct CEO role). To his credit, ChrisP signed up for that role. To many it looked like Chris walked away from a big job in Office. Though to Chris—developer on DOS 1.0, Mouse 1.0, Windows 1.0, and so on—this was a logical progression and Office was the diversion from his path of shipping and innovating entirely new to Microsoft products.

The strategy was to quickly turn around a released copy of FrontPage, packaged in a standard Office box, and get that on shelves as soon as possible, which they did. This FrontPage 95 (Vermeer 1.1) made it into market and in short order became the leading web authoring tool, selling over 150,000 copies in a few months, substantially more than the 275 copies Vermeer had sold as an independent company.

Once that release was complete, ChrisP began the long-term integration of FrontPage. The biggest concern was losing momentum in what he believed was a next big category for Office. In some ways, PowerPoint offered a good lesson in integration. For the most part the team continued on their mission, only prioritizing getting a Windows release out quickly. The whole divisional transition to Office also changed PowerPoint from an independent, so to speak, operation to one more integrated. Even then it was a peer to Word and Excel, albeit remote.

In the short history of acquisitions, Microsoft could be said to have roughly three modes of venture integration. The most common was to simply absorb the code and team into an existing group or product. Microsoft just completed a series of acquisitions in graphics, for example, and those in some form (or not) went on to become parts of or team members of the underlying graphics technology for games on Windows. Similarly, several acquisitions were done in e-mail and networking, landing in their respective teams.

A second type of integration, far less common, was to acquire a company in a space Microsoft hoped to lead and to put forth the product as the new leader. These tended to be less successful during this era, perhaps because of the way the sales efforts were transitioning to business licensing from either retail or distinct sales motions for each product. The company was becoming a Windows, Server, and Office machine and whole new products would struggle to fit in if they were not part of these efforts. A big challenge with these deals was the ever-present goal of synergy across Microsoft. The pressure on visible leaders to also show integration with Microsoft, especially to leverage sales efforts, was rather intense. Additionally, there was the pressure to build more on the next generation technologies Microsoft was building. SoftImage was acquired to enter the television production space for $130 million, but Microsoft lacked a structure that could capitalize to grow the asset. HotMail was acquired for over $500 million in 1997, and from the start it was a leader in free email but also in constant synergy negotiations with Exchange and ongoing pressure to build on Windows server. This pattern would repeat many times for many future acquisitions. The logic behind this integration strategy is always something along the lines of “this is a great company, but we can make it even greater.” In reality, most leaders seemed drawn to this approach, declaring the acquired product a new leader, because that brought with it all the attention and glory of being a leader having simply done a deal.

A third type of integration, and by far the most difficult, was what I would call sheltered. The company was acquired and the product nurtured as though it was going to be a new leader, with a specific integration agenda and a strong sponsor that tightly controlled all the inbound requests for synergy. I hate to describe it this way, but you could picture essentially building a bubble around the team and offering outsiders (to the team) very specific points of integration. Executing on this strategy while not simply telling every other group to drop dead was both an act of diplomacy and heroism, and enormously self-sacrificing. As we know today, this is almost always the right way to do venture integration and when everyone agrees the painful bubble is replaced by standard operating procedure. The logic of this mode of venture integration is easy to see — “this is a great company and we acquired it because it is great and the team should keep making it even greater, just ask where Microsoft resources could help.” The emotional costs of such a strategy in a company dominated by strategic synergy and sales efficiency were high and few had the clout to pull it off.

ChrisP had the desire and clout to build a bubble around Vermeer. Inside the Office team we knew to basically leave FrontPage alone and unless Chris or one of the senior people came asking, we just assumed they were doing what was right. As the development of FrontPage 97 continued, many points of integration came about, but with few exceptions these were done via the negotiated portals through the bubble.

Chris and the team found themselves drawn to many potentially strategic discussions, however, and those created quite a bit of stress. It is easy to imagine that everyone had their sights set on either leveraging one part of FrontPage for their product or expanding the strategic importance of their technology by convincing FrontPage to adopt it. At the same time, few teams saw the beauty of the whole of FrontPage, an integrated view of designing, creating, and managing web sites.

Some teams wanted to use the incredibly novel ability of FrontPage to publish pages and content to the web. This resulted in a technology that many of that era remember, the FrontPage Server Extensions, which became a standard offering on most web-site hosters. These even ran on Unix back in the day, which was quite controversial at a time when helping Windows NT to win in web hosting was key. Other teams wanted to add HTML editing to their tool and so it was natural to request the editor component of FrontPage as a chunk of reusable code, something that BillG would be proud of. Things are rarely that separable. Internet Explorer was also working on adding editing at the time (as was Netscape). Many meetings were held explaining how much more difficult WYSIWYG editing was, even if it was for simple HTML. It was clear the FrontPage team were probably the world leaders in Office-level HTML editing, which made these conversations awkward.

The team soldiered on working within the bubble that Chris had so carefully crafted. He was under enormous pressure and at the same time was happily coding away his features in the product. It was amazing.

To help to scale the team, ChrisP also built out the program management (product management in modern Silicon Valley vernacular) function of which Vermeer came with none, say for Randy the co-founder as is common with most startups today. ChrisP assembled a PM team from several members of Office, with a lead from Word who had originally detailed the depth and richness of FrontPage. Chris also brought in a leader to build out the test function and a marketing leader, thus making Vermeer equivalent to a well-staffed Office application along the lines of the old product unit model, before Office. Vermeer was a self-contained unit with the functions needed to create a stand-alone product and business.

As the team would learn, bringing PM into a development centric startup was not nearly as easy as one might think. Our view was always that PM was there to help make development more effective and not to waste time, and importantly Apps viewed the approach to PM as something that contributed significantly to the success of Word and Excel. PM would often handle all those inbound requests for help and so on. The Vermeer developers, however, felt pretty good about their ability to select features, prioritize, and specify interaction models—after all they got this far and did well enough to be acquired. There was a tendency to think of PM as process over substance, a not uncommon view among many outside of how Apps had evolved the role. Building out the PM role while continuing to build the product, was one of the more challenging aspects of venture integration.

For many years, the integration of Vermeer would be the case study for Microsoft in how deals could be discovered and executed. Harvard Business School had a six-part case taught over two days to first-year students. Reading the entire case is one of those times when the case method is able to tell a great story and anyone wanting to read all the details as told to a Harvard Business School professor and researcher would find it enjoyable and worth the effort.

As it would ultimately turn out, however, the viability of a stand-alone web-authoring tool would be subsumed by many different categories and brought to market as a part of a variety of products. The web was still young and moving fast in many directions. While FrontPage did not endure as a stand-alone product, most all the members of the team went on to remain and contribute significantly to Office and as leaders in both editing and web technologies. In that sense, Microsoft got an even better deal than originally envisioned.

On to 045. Incompatible Files, Slipping, Office 97 RTM

I’ve received so much positive feedback which I do not thank readers enough for. A few have asked for more sooner, so I am going to see about a slightly increased frequency and how that goes. Please do not hesitate to send feedback at any time, [email protected].

Due to the rising importance of email, Outlook, which originated in a separate division from Office, ended up becoming a second anchor tenant of the Office Suite early in the Office96 cycle. Arguably the reason that it became possible for Office (in combination with a service-based Exchange mail) to transition to the Office 365 cloud, Outlook had a very bumpy start. Simply getting the product shipped then deciding on the packaging, and as we will see over subsequent chapters making it reliable enough for the modern world, were all challenges.  

Back to 042. Clippy, The F*cking Clown

When we started the 94/96 plan, Office was Word, Excel, PowerPoint, and (for about half our customers) the Access database in the premium edition, Office Professional. By the time we shipped Office96 we added two entirely new products, FrontPage (acquired from Vermeer corporation) for website creation, and Ren & Stimpy (the code name for what would become Outlook) for email and scheduling. It is rather remarkable in hindsight that by some measures the Office product nearly doubled in size and complexity along the way. Bringing two products into Office proved to be equal parts learning and terror, and my first experience dealing with the role bundling plays in our business execution.

Through the whole Office 95 product cycle, I was maniacally focused on all things internet. One of the fastest rising uses of the internet turned out to be the oldest, and that was email. Microsoft tended to view email through the lens of the nascent yet growing server business because of Exchange Server, still under development in the Workgroup Apps team (WGA). With the release of Windows 95 (and WordMail), Exchange Server was front and center for all of Microsoft and the growing enterprise business, and still a year away from release to the public but deploying inside Microsoft and a few select customers.

Being a server team, the end-user experience for the product would characteristically receive less attention. The Exchange-created mail client program, Windows 95 Inbox (previously Capone, but still called that in discussions), and the calendaring program, called Schedule+, which was ported from the legacy MS Mail system, constituted the Exchange clients. None of these clients (client as in client-server architecture) were particularly good at connecting to internet mail.

The industry, in general, had a blind spot for internet mail. New entrants like Netscape were the exception, as everything at Netscape was native to the internet. Lotus Notes, the primary competitor to Exchange, was aggressively building in Internet capabilities. They already had a successful product in market and recently executed a big launch of internet connectivity at their conference, all with the backing of IBM ownership.

Surprisingly, within the Workgroup Apps team there was a second mail client being built with the code name Ren & Stimpy. Originally the team planned two releases, Ren a lightweight product to include in Windows, followed by a more full-featured product, Stimpy, to include potentially in Office. Work had been going on for quite some time already.

Brian MacDonald (BrianMac), leading the team, was legendary in his ability to project a monstrous and all-encompassing vision for a project and recruit and rally an ever-growing team to go after the vision. Brian was well known within Apps, having created Microsoft Project as a start-up acquired by Microsoft 1989, growing it to a business of hundreds of millions of dollars. Project was a traditional project management tool used to manage timelines and resources for big projects such as construction. It was one of several market-defining and significant revenue-generating products from the expanding roster that were often over-looked in telling the story of the Apps business.

Sometimes people with BrianMac’s set of skills, their aspirations grow faster than the execution. Perhaps through no fault of their own, they find the product positioned between one or more teams who alternatively believe they are competitors or depend heavily on the product for their own success. In the case of Ren (the shorthand name), it was clear the team achieved a combination of most of these.

The Ren vision was extremely broad—to encompass the whole flow of daily work on a PC from mail and contacts to scheduling to tasks, including managing your files and even custom business apps like Lotus Notes could create. It is this breadth that at once caused it to become an essential part of every team’s strategy and also a competitor. Without having shipped a line of code and without anyone outside the team even close to using the product, Ren had become central to most every conversation within Microsoft. When Ren wasn’t licking the proverbial cookie of some team, it was the cookie being licked by another team.

Ren was heavily dependent on Exchange features and performance. Ren also bumped up against (or even surpassed) capabilities of Inbox/Capone and Schedule+, Windows Explorer for managing files and the successor called the Cairo Shell, Lotus Notes, and even Excel because of the pivot-table like UI it had for viewing data stored in Exchange. Yes, this was a confusing lot and meant it pretty painful to go to any meetings on these topics. Was Ren partaking in cookie-licking or was it going to deliver was a common theme and that meant groups had no problem articulating plans that bet against Ren. In other words, there was no shortage of pessimism about the product to counter its own expansive and optimistic vision.

While we had not made any packaging choices for the product, in the latter part of 1994 the Ren team was moved to the Desktop Apps division, specifically within the Office Product Unit. Adding an entire product to OPU was awkward, as our mission was shared code, but the state of the product was such that it would benefit from the hands-on management that would presumably come from BrianMac working side-by-side with the rest of us in OPU.

As an alternative to Capone and Schedule+, Ren was clearly going to be integral to the success of Exchange. Early on, however, there was a great deal of resistance within the WGA team to an outside group that did not understand the intricacies of the email server being so core to the success of the product, as we learned building WordMail. Yet the server team’s focus and execution on clients remained a relatively narrow expression of the space, aiming to expose the server functionality in a somewhat linear manner—meaning a focus on email messages, not a general database as both BillG and BrianMac were pushing. Ren had much grander visions for taking advantage of all the server might possibly offer in ways the server team had not really thought of doing—something experienced frequently by platforms.

The product team that most immediately placed Ren in the crosshairs was the even larger and more ambitious operating system, Cairo. Cairo was a fundamental rethinking of the operating system from the ground up, with two aspects of it that ran up against Ren. The challenge here was not aligning products or technologies, but how to foster such an alignment when both projects were so exceedingly early and ambitious that really this was less about one code base pitted against another and more about one slide deck going against another.

Cairo aimed to reinvent the interaction with the desktop, files, folders, and programs. This new model, an object-oriented shell, encompassed two third rails in one description. First was the buzzword object-oriented. As I learned in C++, this was a phrase that meant everything or really nothing, depending on your perspective. When it meant everything, as it did to Cairo, it meant that it was likely that Ren was doing everything wrong. There were going to be many OS techniques that Ren should take advantage of that were entirely different than those available on Windows 95 (and beyond). That’s what reinvention is all about. Navigating this would be quite difficult since most capabilities didn’t yet exist, and Ren was trying to sync up with Exchange Server and also Windows 95.

The concept of the shell as the one place for everything is essentially what the “desktop” is on an operating system, or on today’s mobile phone home screen. Since it is the most visible part of the OS it receives a lot of attention, especially during reviews and evaluations. In practice, most customers who aren’t tech enthusiasts see the shell as a place to launch the programs they care about and copy files around and not too much more. As an OS-first company, though, Microsoft and BillG were very much shell-first in thinking. This meant that Ren’s self-described mission to be a shell was important and thus would bump up against the actual operating system.

Every team aimed to be a shell. In tech evolution in general, each mini-epoch can be thought of as a time when all software generally converges to one type of application. In the early days of the PC basically everything became a word processor—most all programs were about typing in some way or another and would add features over time to be better at typing (spelling, printing support, and fonts). With the GUI, most every application aimed to become a shell and place where other programs could be launched, and files opened. The Microsoft Office Shortcut bar is an example of this as was the investment in overly featured file open dialogs across most commercial software. Future epochs would be defined by convergence to web browsing, later photo editing and sharing (which became a routine demo joke during the early 2000s when it seemed every product demo at the company meeting showed photos), and in the late 2010s every product eventually became a text-based messaging product.

The second rail of Cairo was an entirely different underlying storage model—where mail and other data should be stored. So again, even before getting too far down the process, the Ren team was doing everything either twice correctly or once correctly for the present and incorrectly for the future. This dilemma routinely faced Microsoft, as during this period of rapid expansion things were being duplicated at many different parts of the company and with varying levels of execution capabilities.

The Ren versus Cairo struggle is not unlike so many of the classic struggles at Microsoft, which could be summed up as asking the question “Why did Microsoft have two (or more) groups trying to do the same thing?” To outsiders this can look wasteful at best, or plain stupid at worst. To insiders, this looks confusing and strategically lacking. Basically, everyone on the collective teams just thinks executives are clueless and needlessly torturing everyone. Oh, to be young again.

To the execs, they knew that they wanted the sum of the work across all the teams. They might want the user interface skills of the Apps teams and the server programming skills of the Server division but had no way of doing both easily. The naïve view was to just create a team with all those skills and let them go at it. That was what almost everyone in product teams argued for, but to execs doing that created a ton of organization friction not the least of which was even deciding where to put that team. Frankly, there’s enough experience to know that even if you created a whole new team with all the valued skills and perspectives, wherever the team lands was going to be the high-order bit of the new team and determined its fate.

Something I came to appreciate as I gained experience was that organizations are not a substitute for strategy. In fact, the organization ultimately defines what the strategy will be. Capone sitting in the Exchange team guaranteed a minimalist mail client that expressed the viewpoint of the Server, as an example. Years later I would often approach strategy questions being debated through the lens of potential re-organizations by asking rhetorically “tell me the outcome you want, and I can craft an org” knowing that was exactly the decision execs did not want to make. Usually, the answer to that was something along the lines of “the teams will work out the optimal solution” to which I would reply seriously, not rhetorically, “tell me who will manage the team and we’ll know the decisions they will make.” Even though that was right, I could be frustrating.

With such a grand vision and sandwiched between two groups, Ren had an even bigger challenge, and that was executing. There was simply too much to do. ChrisP, master of shipping, was asked to manage the Ren team and help find a way to get it to ship with the Office96 product release. In the best of circumstances this would have been a crazy challenge. Our team already had too much going on, and the urgency ChrisP was asked to inject into the team was not welcome. Rather, the Ren team continued to expand its scope, further raising the eyebrows of both WGA and Cairo.

Once Ren was moved to Office, it was going to ship. That instantly became the high-order bit. In Office we shipped, and strategy and vision were scoped to shipping, not ever-expanding. That was going to frustrate some (including the Ren team) but putting the team in OPU determined the next steps. As part of moving Ren to Office, part of the Cairo team also moved to Office. That was really BillG hoping that those magical Cairo features would ship sooner. While I’m sure some people believed that could happen, I was certain that moving the team to Office made the actual outcome abundantly clear.

Moving the responsibility for developing Ren to DAD made sense as it could compete with SmartSuite on the desktop, leaving Exchange to compete on the server with Notes. Still, this was controversial since the strength of Notes was that it combined both a server and a desktop client in one integrated product. In a sense it was taking a contrarian view of competing—having a distinct client and server communicating over a well-defined API, rather than having an integrated client and server placing code where it made the most sense. Or it could be viewed as relying on the strength of the Office desktop versus SmartSuite. Would the email client pull in a new set of productivity tools for Lotus/IBM, or would the leaders in productivity tools be able to pull through a new entry to mail servers with Exchange?

ChrisP and I developed a “get focused” management approach that was both straightforward and rather gutsy. Since I would be on the front lines in daily/weekly cross-group meetings, to downplay the expanding visions we developed a series of questions that we would have at the ready every time the Ren team looked to be slipping out of “get-done” mode and back into vision mode. We called these the “Get Serious Seven”:

* Is it 100% Compatible with Capone?

* Is it 100% Compatible with Schedule+?

* Is it 100% Compatible with Chicago Explorer?

* What is the working set [memory usage] when using it to read mail?  When using it to browse files (not logged onto mail)?

* When is it going to be used by all of Office?  All of DAD?  What are the code complete, ZBR, beta dates?

* Is everyone running and testing Ren on Chicago?

* Does it browse FAT [file system]?  Cairo OFS [file system?

There was nothing magical about these questions as they encompassed the ChrisP and DAD methodology and also represented the claims the Ren team was making about the product across the company. In that sense this was rather straightforward. The details do not make much sense today since many of these features never made it, but the idea was to constrain the vision talk and emphasize execution talk.

A second action, and gutsy one, was to add a person to the mix. ChrisP asked Jodi Green (JodiG), the longtime Word engineering leader (also cafeteria tablemate) and fantastic project leader, to take on a role as the development manager for Ren. The thing was there already was a development manager and the org was not going to change. Jodi was looking for something she could take on part time where she could use her expertise without the overhead of line management, so this was a perfect match. JodiG convinced herself, along with support from all the OPU managers across dev, test, and PM, to sign up to be the adult supervision—or a spy, depending on your perspective. The truth was she was going to be an asset to the team if they could just realize it.

Jodi and I often talked about the challenges—the lack of specifications, the churning of ideas and code, and general absence of discipline. The team was in a situation that we saw all too often in both “version 1” products and projects that did not feel the hunger to get to market but were seeking perfection—the enemy of the good is the perfect. As a version 1.0 product, Ren also had its share of trying to use all the latest tools and techniques. Ren was first big application to be object-oriented and to use C++ and even started from my old MFC libraries. There was nothing inherently wrong with this (in fact, I was super proud and excited, albeit a bit nervous), but when you’re already long on vision and short on execution these become evidence points and, worse, part of the blame game in the hallways. It is worth noting, that the Ren team was made up of many people who had shipped a lot of products, but something about the vision and leadership had caused an expanding appetite for vision.

The plan was starting to work, and after a few months things really started to solidify. While Jodi deserves a huge amount of credit for putting herself in the middle of the team as an influencer, she drove a more refined team culture and helped to bring them into the DAD fold. As one might expect, projects that churn and change a lot also begin to fatigue the team or at least create some frustration or friction. One engineering leader in that camp was Don Gagne (DonGa), new to Microsoft but with 20 years of experience at start-ups shipping software, growing companies, and more. He joined with significant experience in the email space and had risen quickly to become the go-to leader of the team. With JodiG from the outside and leaders like DonGa rising from within the team, Ren began to look more and more like it could be part of Office96.

The depth of features in Ren was kind of mind-blowing. Early in the product cycle, after using the product for a brief time I sent AndrewK, the user-interface leader for OPU, a note bemoaning my “exhaustion” in using the product because it had so much “stuff on the screen”.  While that sounds like an insult, I also said it was a “goldmine”. I wondered though how customers would react when the vast majority were not yet using email and almost none had email in their corporations. Email growth was, however, exponential and with Exchange driving that there was an enormous opportunity for Microsoft.

Ren not only had a very feature-rich email capability (such as a new inbox that showed the first few lines of a message) and incredibly rich scheduling capability (including delegate access, numerous views for day/week/month/workweek, time zones and more), but a host of other modules including rudimentary task management, little yellow sticky-notes, browsing regular files in Windows, and even a kind of journal that kept track chronologically of all the work in Office. Beyond that the user-interface was, for lack of a better word, object-oriented. Every one of those features could create custom views of items that worked like Excel pivot tables or display items as a calendar (tasks viewed in a calendar for example), or even dragged and dropped to create mail messages (such as mail a task to someone). Beyond that was a whole new user-interface element called the Outlook Bar, which was like the Office Shortcut Bar but inside Outlook for switching between the different modules of Outlook plus tons more features. The Outlook Bar was itself the subject of intense debate and endless consternation over the design and whether it had enough (!) The product was a fountain of snazzy, but incredibly difficult to discover, demo features.

A quick view of all the features in the Outlook Bar. (Source: Personal collection)

While all of this was going on, the big competitive issue for DAD and Microsoft in general remained Lotus SmartSuite. The resurgence of Lotus Notes, arising from IBM’s aggressive acquisition of Lotus in late 1995, put a spotlight on the enterprise threats facing Microsoft—competing with Notes became much more of an issue for Office. IBM’s enormous sales force selling Lotus Notes for workgroup and email with SmartSuite on the desktop would be formidable and scary.

Ren was christened Outlook after an elaborate and expensive search for a product name. The marketing team defined Outlook to be in a new category, desktop information management or DIM. This somewhat puzzling choice was the source of endless puns from the groups that still bet against Outlook ever finishing. In moments of frustration, the Exchange team loved to remind me of “DIM Outlook”. 

I was worried. Shipping is difficult in the best of times. We were behind in Office96, with an original ship date of end of early 1996, it was becoming clear that even making 1997 was a challenge. Blaming Outlook would be easy, but also incredibly unfair. Across Office we had too much work to do. The question was not, however, if we would finish but simply how late we would be. Still, I was not immune from worrying Outlook would be the “long pole” as we would say with respect to shipping.

Outlook was the first of several newly created products used not to grow new businesses (revenue streams) but bundled with Office (or given away for free, depending on perspective) to sustain the existing business. Jim Barksdale, the CEO of Netscape, was famous for his comment, “There are two ways to make money in business: bundling and unbundling.” Microsoft, and SteveB in particular, were squarely on the side of bundling new capabilities into our existing efforts to sustain them and deliver more to customers.

Much like the strategy versus org question, the bundling question is one that had easy answers when I was young in career and over time the answer became more subtle and nuanced. At this moment, I was decidedly against bundling but entirely for operational reasons—I was just worried Outlook would slow us all down while also dramatically increasing memory requirements. Additionally, without Exchange server Outlook was all but useless. It would not be until later that rudimentary support for the basic Internet mail protocols would get added, but many of the core demo features of the product required Exchange (which was exactly the point, strategically speaking).

The other naïve perspective I had was that if we wanted to grow the business, then clearly selling a new product for a real dollar price was better than just giving it away for free. Given that Outlook wasn’t useful for most customers (or so I thought) how could a free product grow our business. Our old friend exponential growth is important here because the growth in mail was so explosive, that the idea of email not applying to customers would be dated and plain wrong less than a year after shipping.

What I truly failed to grok, however, was the role of having an incredibly simple and efficient message for an expanding army of salespeople. The cost of adding a new effort to sell Outlook was enormously high and didn’t scale around the world like I might think it would as an engineer in Redmond. Having a simple message “Office” everywhere is something that scales. The couple of SKUs were there to just fill in basic price points and offer negotiating leverage for sales, but the message everywhere was “Office Pro”.  Guess what sold? Office Pro.  Lesson learned.

This lesson would really hit home to me just a bit later when I visited the newly opened Microsoft Vietnam subsidiary. The General Manager met me at the hotel, and we took a scooter to the office. It was a single open space in the capital city. When we entered the whole office was lined up to greet me—all three people plus the GM. After introducing ourselves by name, he smiled when I asked who worked on which parts of the business. I was expecting abstract assignments like Public Sector, Enterprise, Small Business, Education, and so on. Instead, he proudly pointed left to right “Windows, Office, and our administrative assistant”. Back in those days, a GM could add a person to the subsidiary for each incremental $1M in sales. Owing to the recent success of the business, the administrative assistant was recently added.

I wish I could say that lesson would cause me to love bundles. The choices became more difficult over time as the pressure for incremental revenue increased in the face of slowing sales to new customers. That didn’t change the complexity of selling something new or the pressure to develop whole new products. It did make the debates over packaging choices much more lively.

The early packaging choices, Word + Excel + PowerPoint, and later adding Access and Outlook, were so enormously successful that it tended to confuse later decisions. In the market, Word and Excel were undeniably successful, each on their own, and in many ways supported PowerPoint (at least for a while until PowerPoint gained the same footing) and later Outlook in achieving success. Outlook being the required client for Exchange (and included at no extra charge whether customers bought Office or Exchange, as IBM was doing with Notes) helped everyone (customers, sales, analysts, and reviewers).

From the product development perspective, the challenge we faced was an inability to understand market success with such a strategy. Was the whole product winning? Were we winning just because of sales and marketing? What was the right way to measure winning? Was winning about product reviews or customer satisfaction? Or was it much more about the efficiency of pushing product through our new sales channels? These challenges added complexity to our ability to plan and deliver features and products while coordinating releases with sales.

We had a great deal of work to do to ship and to learn how this decision played out. What we knew now was that Outlook had a lot of features, it was a new “puzzle piece” in the Office family logo. Outlook was going to ship everywhere Word, Excel, and PowerPoint shipped…just as email was exploding. If we were right, then Outlook would have the potential to redefine the suite. If we were wrong, Outlook would be an albatross that could impact the adoption of new versions of the core money-makers.

On to 044. Our First Big M&A Deal (Beating Netscape)

As a company gains success and grows, taking risks becomes, well, riskier. The costs of failure come front and center, as the ability for a company to play out scenarios where something would not work overwhelms the naïve optimism that used to characterize efforts. It is like one day, suddenly, everything becomes more difficult and scarier. Clippy, née Clippit, needs no introduction as the failure, the evolution to kitsch, and the resurrection as a technology ahead of its time have been baked into even mainstream consciousness. If you would have asked me in 2000, three years after the debut, if I would still be talking about this failed feature, I would have LOLed. While I could probably fill a book with the story and the team that brought the feature, this is the story told in the context of the arc of the PC and Microsoft.

Also, a good time to note that success has many parents and failure has none. There’s no shortage of told-you-so around Clippy, until recently that is.

Note, this post is best read in a desktop browser for a complete experience.

Back to 041. Scaling the Office Infrastructure and Platform

In early discussions, we attempted to explain how we had learned from the abysmal failure of Microsoft Bob and that we had a plan. At one point, the conversation turned from stepping through a complex task in Excel to BillG bringing us to tears in playing back what he heard. They were both tears of joy and tears of pain. It went something like this:

Demo: The Assistant will then appear and offer each step in sequence to create a chart, as the user interface does today. But it will be more friendly and approachable and have easy access to help content.

Bill: So, when I want to create a chart the clown will pop up and say, “I’m here to help” and . . .

Demo: Not clown, but assistant.

Bill: The clown pops up and then I’m like clicking on the clown saying clown next, next, clown next or something just to create a chart.

Demo: The Assistant is just a more approachable and helpful version of the same number of clicks and steps you always had.

Bill: Next . . . next . . .next, and pretty soon I just want the f*****g clown to get out of the way.

Bill often had these routines or short skits that he would play out over and over—if you were the target, it was painful the first couple of times then it was for show for other attendees then you had to assert yourself. This was one of those. Through the entire rise and ultimate fall of the idea of an animated character or agent, which he referred to as a “clown”, this pattern complete with the escalating high-pitched frustrated BillG voice would make an appearance. I lost track of how many times he ridiculed the feature this way. Still, he doesn’t get the right to say told-you-so.

This started with the earliest products based on an animated helper that were developed in the early 1990s and released while I was working as Technical Assistant, so I was quite familiar with the above routine. Then Microsoft’s focus was on bringing software and PCs to children and like all products for children, the general theory of education told us that products needed to be fun, engaging, and immersive, and different from business-oriented or grownup products.

A pair of products were developed together for Windows 3, Creative Writer and Fine Artist, a kid-oriented word-processor and drawing program. While these products were nominally about the basics of productivity, they were part of an entire animated world called Imaginopolis hosted by the ever-present guide, McZee, a lanky purple humanoid. It is easy to be dismissive of the products, but in fact they contained enormous feature-depth for the time. McZee was more than just a helper, but essentially the full user interface for the products. All the actions were directed through McZee.

Measuring success in the new Microsoft Kids line was difficult because the unit sales weren’t spectacular and because everything was new and the company was determined to stick with it (remember the Microsoft reputation for taking three versions to get something right). The spiritual successor to these two products was an even greater product risk as it was not just for kids, but for the home. The problem that needed solving was that people were buying home computers, but lacked software to do home things, like keep lists, write letters, track to-do items, and calendars. While there were business packages that did that, the general theory was that software for the home needed to be more friendly and approachable, especially because those not skilled in business computers would use it.

The Consumer Division where Microsoft Kids software came from was filled with people on a mission to bring software to a broader audience. One of those was Karen Fries (KarenFr) who was the lead advocate and pioneer for the use of what was widely known in academic circles as social interface. Karen was co-leading program management for these new products and was deeply immersed in the cutting-edge technology. She was a co-author of a 1994 paper “Seductive interfaces: satisfying a mass audience” with some of the early work in the area. Other authors on the paper were Stanford researchers, Clifford Nass and Byron Reeves. This was serious work with some depth. Nass and Reeves (who would later consult with our efforts in Office) developed the work into a book The Media Equation: How People Treat Computers, Television, and New Media Like Real People and Places. Their research developed and provided evidence of a core thesis that humans “treat computers, televisions, and new media as real people and places” and beyond that, humans develop models for interacting with technology and media based on how those works are designed. At the extreme, this explained frustration and fear of computers because of the general belief that computers are smarter than people and so interacting with them took on the traits of interacting with a much smarter and less tolerant human. This is what Karen, along with her co-leader (and designer) Barry Linnet (BarryL) set out to fix in developing Microsoft Bob, codename Utopia. No strangers to making easy to use software, Karen and Barry co-led the creation of Microsoft Publisher, a very successful and much-loved entry into what was known as desktop publishing, a tool for creating newsletters, certificates, menus, signs, etc. aimed at home and small business users.

Like McZee, Microsoft Bob was an immersive environment. The experience, however, was less kid and more home. It was still animated, and it was still fun. Bob was the smiley face that occupied the middle letter O of the name, though within the software an ever-present puppy acted as the assistant and guide for using the many modules of the product. Each module was depicted as a place to click on in the home—click on a phone index for contacts, a pad of paper to write a letter, a checkbook for finances, a globe for a geography quiz (gosh, that was such a BillG thing), and so on. The software had even more depth than the previous products. As an example, a typical home letter-writing effort might be a complaint to an airline for lost luggage. Bob not only contained samples, but even maintained a list of airlines and addresses that it would use to pre-populate a complaint letter (and this is before the internet).

At the January 1995 Consumer Electronics Show, Bob was launched to immense fanfare and broad media coverage across print and even morning television. There was so much enthusiasm about home computers but before the internet people were just not sure what to do with them, at least broadly. That said, the product was unfortunately not well-received and ran into the buzzsaw of technologists who simply didn’t buy into the shell or veneer Bob created around Windows.

Why was Microsoft going through all this and making these risky, or even edgy, products? Many seemed puzzled by this at the time. In order to understand that today, one must recognize that using a PC in the early 1990s (and before) was not just difficult, but it was also confusing, frustrating, inscrutable, and by and large entirely inaccessible to most everyone unless you had to learn how to use one for work. In fact, using a computer usually meant signing up for an in-person class that would meet at night for a few hours over the course of several weeks—often buying a computer came not with an extended warranty upsell, but one of these classes. It was this era when businesses would put out job opportunities for people that had 1-2 years of experience using a PC, preferably Lotus 1-2-3 and WordPerfect. These products with their dizzying array of keystroke commands and chorded combinations of ALT, CTRL, and SHIFT keys were difficult if not bordering on impossible for most people to master.

As written previously, Windows and the graphical user-interface were supposed to fix all this with its easy to use menus and direct manipulation with a mouse. Yet the exact opposite happened because while those made accessing commands easier, the number of possible commands was growing at a rapid pace. It wasn’t just that Word added bullets and numbering, but it added the myriad of options to stylize, format, and order paragraphs. And footnotes, endnotes, pagination, hanging indent, and on and on, then Excel and PowerPoint too. In order to mitigate the growing complexity of the products, Office developed an array of bolt-on utilities from massive printed and bound books, wizards (pioneered in Publisher), tutorials, getting started (like a tutorial but shorter), even a friendly tip-of-the-day that offered a quick refresher lesson when you launched a program. It got to the point where even these various forms of help needed an overview to explain them. Ironically, an after-market developed which packaged up all that information and the expertise of authors to create even more help. Typically, owners of Office (or even those considering owning the product) would invest in phonebook sized softcover books further explaining the use of the product. At first this seemed cool, then we started to realize the futility of our own product development efforts.

My college recruiting talk on developing the Assistant detailed the story of building the guru into Office in these several slides (animated). (Source: Personal Collection)

The one constant, as we studied the landscape of people using Office, was that getting anything done involved tracking down the nearby Office guru—the person that invested the time and effort to master the software more than the rest of the people in the office. Need to create a table, figure out a formula, or draw an org chart then go down the hall and get help from the guru.

Chances were high that the product did what you thought you wanted to do, but the path through the maze of commands was not only difficult but fraught with the risk of destroying your work or getting the document into a state that would make further work even more difficult. We often would receive letters detailing specific features or outcomes a customer would like to achieve, only to learn that the feature was already in the product.

With Office96 we set out to build the guru into Office to solve this growing problem and dissatisfaction with the product. The early love of Office was turning into early signs of resentment as the customer-base grew. Early adopters loved the power of the product, but increasingly new customers felt overwhelmed by their lack of mastery. We had a genuine customer satisfaction problem on our hands.

As we knew from Nass and Reeves research, people had confidence in the tool to get things done but lacked a way to interact with it to understand how unless the right human guru was helping. Our challenge was to build a software equivalent to the guru.

That software equivalent would start with the clown as BillG called it, or Assistant as we called it. The name of the internal implementation of the Assistant, tfc in our Hungarian notation, was a hat tip to BillG’s “the f*cking clown.” Even though Bill had ridiculed each social interface product, we were deep in the problem we needed to solve and optimistic we could figure out an approach. We needed to look no further than the computers on Star Trek, which enabled Captain Kirk and Spock to tap into the vast resources with vague questions and open-ended problems. Similarly, the industry was buzzing with the idea of agents that would be able to do work on your behalf such as find cheap airline flights or schedule meetings. Everywhere from Apple to the MIT Media Lab were talking about agents. There was ample evidence this was not simply a weird vision in our corner of the tech world. In fact, by some accounts we were in a race to have the first and best guru in the box.

The lesson from Bob was clearly that an entire immersive environment would not work, plus there was no way we would do that for Office. We also knew that rewiring the entire interface to do everything through the step-by-step interactions with the assistant would not work. Instead we wanted to combine the warmth and comfort of a social experience with the kind of help the guru provided in real life. While many would ultimately conclude that the paperclip was simply bolted on the side of Office to provide cuteness, we made three big technology investments, even bets, to bring Clippy to market.

The first step in asking a Guru for help was to ask a question in your own language. The guru then maps that question to the typical answers or FAQ (frequently asked questions) that were known. You might ask “how to print sideways” and the guru knows to check the landscape option in the print dialog, or “how do I hide the elephants in Word” and the guru knows you are talking about the pilcrow symbol, ¶. A typical question might be even more abstract such as “how do I format alternating lines in a spreadsheet" which a guru might point to more sophisticated features of Excel rather than some of the direct formatting tools. This is precisely the technology we had developed and released for Office 95 as the Answer Wizard. In fact, we back-ported Answer Wizard to Office 95 because it was working pretty well and did not disturb the rest of the product. As mentioned previously, there was a collaboration with Microsoft Research (also a group from Stanford) that led this first pillar of the guru.

Next, one of the things a guru does, at least a good guru, is watch over your shoulder when you are struggling. Often diagnosing a problem, like trying to align two boxes in an org chart or get the columns of a table to be the right width, is not so much being told the right answer as much as being told which step was where you went astray. We knew many tasks in Office were composed of multiple steps that needed to be done in the right order, and often people would try something click undo and try something else. We posited that if we could track the activities as the product was used we could either proactively or on request (hitting the help key, F1) offer a suggestion from our library of help topics for how to get the right thing done. For example, if a user seemed to be clicking around paragraph formatting and indenting, the system might know enough to suggest a help topic on formatting headings or paragraph spacing. And if a user was stuck, simply hitting F1 was a way to summon the guru using the context that was accumulated over the most recent few minutes of use. This was another collaboration with Microsoft Research based on some of early 1990s work using Bayesian math to build a model for making these guesses based on contextual cues. This work came out of Stanford’s artificial intelligence lab and formed the early AI efforts in Microsoft Research. It too was all the rage at the time in academic tech circles.

It was this part of Clippy that proved to be the most challenging to deliver on the promise. Deciding when to fire off the assistant, finding that balance to being helpful versus annoying, is precisely what the human guru finds challenging when looking over your shoulder. Too little help and the product remains frustrating. Too much help and the user just wants to hand the keyboard over and say you do it. The artificial intelligence approach may or may not have been the right technology, but it proved inadequate at the time. The product had too many commands and entry points, or simply too many decisions to make at any given time to be truly helpful.

One mistake, well really the mistake, was firing Assistant on the most simple and obvious effort in Word. The sequence of starting a new document, typing Dear and pressing return would cause the assistant to say, “Looks like you’re trying to write a letter.” And with that Clippy was forever sentenced to memedom (is that a word?)  In our heads we thought this was OK because we were already doing a tip (a yellow bar across the top of the screen) to alert the user to the letter writing feature. This was really a step too far. It did not help that if you clicked “Yes” the software would launch an incredibly complicated wizard offering all sorts of options for a letter, most of which went unused. A few years later, the Microsoft researcher who contributed the Bayesian technology even turned on us in an interview with The Economist and said it was all because we didn’t use enough of the technology. That really hurt—it was as much their work as our work.

The third pillar of bringing the guru to Office was to offer the user the calming and comforting personality of a guru. Using a computer was difficult and frustrating, and we set out to bring some levity to the daily grind. Leaning heavily on the work of Nass and Reeves, we developed the actual character to represent the guru—to attach a personality to the source for answers and tips that would encourage help. We also went a step beyond that and decided that the Office Assistant would be where messages (or alerts) would come from. The ever-present “Do you want to save this file” or “The spell check is complete” would emanate from the assistant. This was the biggest and highest risk bet of the entire feature. It is also what separated the feature from the previous dozen attempts at providing help—it wasn’t yet another bolted-on tool, but it was in the flow of usage and there to help everyone. Internally we called this IntelliAssist.

The minute we had an animated Assistant it was obvious that any opinion or controversy about the feature would stem from the clown or character itself, not the assistance provided. Starting in early 1994 we began the most intensive usability research testing we had done to date on a feature. The number of tests, the number of locations and languages, and design ideas we iterated on was kind of mind-blowing. At one point people were flying to Japan and Europe to rerun tests to see how the results might differ. How big should the assistant be, how much noise should it make (if the user even had a sound card), how often should it appear, how animated should it be, and on and on. The iterations were seemingly endless, all with the goal of making it friendly and approachable while tapping into the fancy underlying artificial intelligence technology.

Choosing the actual character was incredibly controversial. It became immediately apparent everyone had an opinion, and importantly every major sales geography had their own view of what would work locally. It didn’t matter that many animated characters worked globally, there was a strong demand for input and oversight. The risk, after all, was very high. For example, Japan accounted for nearly one-third of Office profits because of the unique market there. The lead program manager, Sam Hobson (SamH), an experienced member of the Excel team who joined OPU (also a college hire like the rest of us) had the perfect demeanor for managing all the connections across the company.

Perhaps we were naive, but we never sat around contemplating the risk the business of doing this feature. In 1995, Platforms revenue was $2.36 billion, and Applications revenue was $3.58 billion—even a small hiccup in Office would be a huge deal. We weren’t comforted in the past sales of the product, but rather sought the comfort of believing we were on a mission to solve an acute customer problem—a problem left unchecked that could materially impact the business. How could a product remain successful if people increasingly dislike it?

Sam created huge boards of potential characters for everyone to look at and pick their favorite. He would lead tests at shopping malls and markets around the world understanding preferences. Meanwhile, Nass and Reeves reminded us these preferences were rather predictable and also not as crucial as maybe the sales people who saw this more as branding than utility believed. In one hilarious early use of these boards, Sam invited the spiritual leader (and then Microsoft board member) Mike Maples to pick his favorite character. Ever the rancher and Oklahoman, everyone thought Mike would pick the big dog or maybe the lion or something. Instead after browsing the dozens of choices, Mike went with. . . the pink bunny rabbit. He smiled and said it reminded him of the rabbits on the ranch. This kind of reaction is what led to the full gallery of choices. While the paper clip, Clippit aka Clippy, would be the default, we featured a dog, a cat, a happy smiling dot reminiscent of Bob, and several more including a really boring Office logo for marketing purposes. The scale of Japan’s business required us to take their input and from that we ended up with the highly controversial Office Lady or Saeko Sensei, which to many at HQ was less than appropriate. Japan also came to love symbols of nature, and guided us to a Kairu, a dolphin and again there was irony in that choice that made us uncomfortable. We kept those characters to the Japanese version of the product. We would later add a small Macintosh-like computer called Max for Mac Office. Being Microsoft, we had an SDK and even a third-party partner that could (and would) create additional assistants.

The character, like the artificial intelligence behind the first two pillars, had a depth of capabilities that often go unappreciated and certainly did at the time. We were severely constrained in disk space and memory, not to mention graphics capabilities, yet wanted to provide a reasonable animation experience. This proved extremely difficult as the expectations for animation had been set by cartoons.

At one point we had a most memorable opportunity to meet with the legendary animators from Walt Disney, Frank Thomas and Ollie Johnston otherwise known as Frank and Ollie. Together they were involved with everything from Pinocchio to Fantasia to Bambi and more. An example of a constraint that frustrated us was the window the character was trapped in. We wanted to do a borderless Assistant like in Bob, but the platform constraints were too much when overlayed with regular Windows apps. Frank and Ollie not only relieved us of that but explained how we should use the window as their stage to allow for entrance and exit and directional animations. They also pushed us to add a sidekick (think Thumper) which was something they had pioneered in animation. They suggested Clippit have something like a little eraser friend. That was well beyond the two dozen or so animation sequences we could have but really brought us optimism for how the feature could evolve with more platform support.

Sound was still nascent in most PCs, constrained by the original MIDI sound capabilities. Windows 95 and multimedia were changing that. We also added a set of sounds that came along with animations which if a user had them on made a real difference in the experience.

These capabilities were coded throughout the product. The Assistant would occasionally just blink or smile or take note of work. If you stopped typing for a while it might perk up and notice you. Using a technical feature would come with a more substantial animation. The assistant was also programmed to get out of the way while you were typing or scrolling, which led to a fun game of chase-the-paperclip using mouse and the Excel grid as was commonly shown in demonstrations.

As we tested the character in various stages behind one-way glass or in focus groups, there was almost always surprise and more frequently than most would believe today praise and support for the feature. It is a cliché for a failed feature to say that it worked in early testing, but that was genuinely the case.

Still as the project progressed there were many that were nervous or outright hostile. As we showed the product to the hardcore technical audience, the reactions were often visceral and immediate. Either people wanted to immediately turn it off without much consideration or they would be thoughtful and suggest that it is not for them, but they could see others (read as less technical) people benefitting. As we would learn time and gain, when core technical users say that something isn’t for them but for others it too often means that the feature might be good, but it is going to need to get past these gatekeepers. We made a very difficult decision to provide an array of settings to control the various capabilities of the Assistant. In other words, we made it possible to turn it off. At the same time, we provided full programmability with Visual Basic for Applications (VBA) so that developers could create custom solutions with full control over the Assistant, including adding custom text in the balloons and choosing animations. Imagine how much fun that budget template in Excel could be with custom chatter from the Assistant!

The Assistant was one part of an enormous release of Office. The remainder of this chapter details some of the other challenges in building Office 97 on the platform and infrastructure described in the previous section.  The product reviews were ultimately mixed, but hardly universal, as we will see in the end of this chapter.

We stuck with and improved the Assistant in the next release of Office. By the second subsequent release we retired the feature, albeit in a humorous way. In parallel with Office 97 an effort began to bring the Assistant to Windows for use by third party developers. Microsoft Agent had much richer interactions using early speech recognition and voice but lacked deeper integration with applications unless coded by developers. Agent was used in Windows XP and remained available for some years.

The journey of Clippy (in spite of our best efforts that was what the feature came to be called) was one that parallels the PC for me in so many ways. It was not simply a failed feature, or that back-handed compliment of a feature that was simply too early like so many Microsoft features. Rather Clippy represented a final attempt at trying to fix the desktop metaphor for typical or normal people so they could use a computer. What everyone came to realize was that the PC was a generational change and that for those growing up with a PC, it was just another arbitrary and random device in life that one just used. As we would learn, kids didn’t need different software. They just needed access to a PC. Once they had a PC they would make cooler, faster, and more fun documents with Office than we were. It was kids that loved WordArt and the new graphics in Word and PowerPoint, and they used them easily and more frequently than Boomers or Gen X trying to map typewriters to what a computer could do. It was not the complexity that was slowing people down, but the real concern that the wrong thing could undo hours of work. Kids did not have that fear (yet). We needed to worry less about dumbing the software down and more about how more complex things could get done in a way that had far less risk.

The other lesson from the Clippy experience is clearly how amazing it was that Microsoft even considered such a high-risk feature. Imagine doing a feature that you know at launch will have some people significantly annoyed with you but doing so also knowing that you could reach some other new customers or bring joy to customers that were otherwise worried. The whole business relies on upgrading existing customers and attracting new customers when all of them have an option of doing nothing or going to one of several competitors. The Microsoft that made Clippy is the risk-taking company that I admired so much. It was the failure of Clippy and the lack of repercussions that in a sense that cemented my own connection to the company. I got way more grief outside the company than inside.

And I needed that because for the next five years of college recruiting trips, I would have to answer snarky questions about Clippy from college students. The deepest pit in my stomach came when I was in New York on a trip at a low point in the Microsoft versus DOJ trial. I turned on the hotel television for some Late Night with Conan O'Brien and his opening monologue took a swipe at Microsoft, “Come on Bill, Microsoft got off easy compared to what the Government did to Clippy, that annoying paperclip icon that pops up in Microsoft Word” [emphasis added] followed by a gruesome violent act perpetrated against poor Clippy. That hurt. A lot. The cheers from the studio audience hurt even more. I was totally signed up for the risk and reviews but being mocked on my favorite late-night show. Ouch.

Then one campus season, perhaps in 2002 or 2003, those snarky comments turned into an expressed love of Clippy and comments like “I remember Clippy on my mom’s computer at work” or “I miss the Dog”. That was amazing. Only that was outdone when about a decade later, Clippy transitioned from nostalgia to a high-tech feature that was somehow ahead of its time. I wish I could say that was the case, but it was simply an idea, not an unreasonable one and not one with a particularly bad execution. The implementation, however, was decidedly 1997.

On to 043. DIM Outlook

Perhaps more than any particular feature in what would become Office 97, though there were a lot of features, the biggest innovation was building the organization and culture supporting a shared infrastructure and platform team. Before Office 97, Microsoft decidedly switched to selling Office, yet we continued to build Word, Excel, and PowerPoint, and we were organized that way. The Office96 product cycle, starting in 1994 (in parallel with what became Office 95) built out the new team, OPU the Office Product Unit, and new approaches to creating shared code and infrastructure. Not only did this come to define the Office product and organization, in many ways it defined my own career and high-order bit.

Please note, this post might be a bit long for email so be sure to click the link to get the full experience.

Back to 040. Creating the First Real Office [Chapter VII]

In shipping at scale, it is not enough to agree on what needs to be done. There also needs to be agreement on how it gets done.

While the big apps were successful in their own right, won reviews, sold incredibly well, had high customer satisfaction, and were made by teams that were exemplars of the MikeMap value system, they evolved with different engineering systems. Differing in detail, they all accomplished the same: shipping high quality (for the era, or at least higher quality than everyone else), while striving for a ready-to-ship product every single day of the process.

To developers and testers, the micro details of how this worked across teams for committing changes, check-in tests, unit testing, localization, and more were highly evolved. Each step in the process was tuned to the “unique” needs of each product’s engineering organization, or perhaps tribe is a better description. Minor differences would be amplified both at scale and across teams. A common example was how much time in the schedule was reserved or buffered for the unknown. Excel with its record of getting closer and closer to on time RTM, could be seen as either extremely hardcore or excessively conservative, but managing the day-to-day progression through the schedule was critical and very much a key part of the culture.

It is a statement about Microsoft culture that the better Excel got at hitting projected ship dates and shipping award-winning products, the more the discussion across Microsoft (outside the Excel team) centered around how conservative the team was getting. To Excel, they were just being hardcore. This was best symbolized by the leather biker jackets developers earned as a ship gift adorned with a Recalc or Die logo. Times were different.

The idea that getting better at daily engineering and hitting scheduled milestones was somehow a sign of being less aggressive or grandiose in plans gets to the heart of the divergence of Microsoft cultures across the company. The Apps teams not only wrote the Zero Defects memo but internalized a cultural attribute of promise and deliver. Much of the rest of Microsoft seemed to have succumbed to the idea that such a process (or philosophy) was somehow less hardcore or even wimpy. There was a strong belief among the over-promise side of the house that building a platform was simply more difficult than building applications (never mind that the applications were also platforms, but I digress) and that there was a real difference in impact if a platform cut features the ways Apps did in order to ship. I can say this because many times when it came to collaborating across the company I was on the receiving end of comments along the lines of “yes, but that’s only because it is just an app.” In my weaker moments I would say the quiet parts aloud, such as “yes, but you’ll never ship.”

Apps, meaning Office, was the more fragile growth engine of the company, and bigger opportunity for profits. Office depended on customers choosing to buy Office over an existing product they already owned or competitor, and that decision benefitted from a new version of Office drawing interest to new capabilities and over time would come to depend on much more profitable corporate deals (as we will learn in the next chapter). Windows, on the other hand, was going out on most every new PC (at a much lower price than Office but a much higher attach to a PC). Whether an updated version of Windows was on the PC or not, PC sales were going up primarily due to businesses buying first PCs for many employees, and in a bit of a twist those customers often preferred the current or even previous version of Windows anyway. There was certainly a pop that came from a new Windows, especially when timed with updated PCs for back to school or holiday, but no one was confused over the revenue drivers. These differences in the business models directly led to the variation (and tensions) in development processes, and also to the differences in how each business evolved and innovated well into the future. We were all products of our environment.

As an example, within Office each program management team (Word, Excel, PowerPoint) developed unique approaches to overall design and feature selection. When there were differences in design or prioritization the discussion would inevitably turn to a claim along the lines of “Excel users are different [than Word or PowerPoint users].” Each team was focused on ease of use, or what we often called “basic use,” yet maintained a different idea of the prototypical personas using the product.

Putting these together, there were three tensions at play in building Office96:

* Enlisting support across executives for an overall plan. The normal process of each formerly Business Unit then Product Unit doing this on their own no longer sufficed.

* Developing a plan with buy-in from the dev managers and test managers for how Office96 was to be built—the tooling, day-to-day dev process, and the overall testing and verification, through to localization.

* Deciding what to build that represented a suite while continuing to recognize that to the outside world, customers and press, the category battles might not be yesterday’s news even if the Microsoft strategy was all Office.

I wish there was a lot of a story to tell about how this played out, but in reality, “decisions were made” in a bottom-up or distributed manner. The rest was going to be in execution. The Office Product Unit was formed while the product plans were created in parallel, thus much of Office96 would be characterized by OPU and the Apps in a state of tension over planning and execution. Ultimately, this made for a bumpy Office96 release filled with many new execution challenges, but it also built the foundation for an execution machinery that would become unprecedented and largely responsible for what ultimately became the largest and most secure business at Microsoft.

The Office96 plan had two main pillars:

* The Apps product units embarked on deep, category-defining features, continuing to make inroads against legacy MS-DOS competitors and to win against Windows competitors. At the outset the suite included Word, Excel, and PowerPoint within the DAD organization and Access in the Tools group. These products underwent significant architectural work consistent with a full 24-month schedule. The initial plan was to continue to ship Mail and Schedule+, though this would change completely as we will see.

* The Office Product Unit built a set of features shared across the apps and then they integrated those features into one or more apps (this is a key tenet about creating shared infrastructure), leaving the other apps to do integration work on their own. In addition, OPU would, by nature of code and also influence, make sure the suite was designed for consistency and integration across the apps.

The OPU features ranged from a lot of heavy lifting, but straight-forward, to some of the most sophisticated refitting of features envisioned by the apps. In contemporary terms, OPU was both an infrastructure team and a platform team. In terms of infrastructure, OPU drove a new shared engineering and quality process (led by JonDe and GrantG) and created shared components essentially representing a platform upon which to build Office applications, providing the code (APIs) for many common application paradigms across user interface, text handling, graphics and drawing, and much more.

As a successful product engineering team scales and a product line grows, there is an inevitable desire to gain efficiencies of engineering scale and an ability to expand the product line efficiently. This all sounds perfectly reasonable until you realize doing any of this runs strongly counter to the very forces that got the teams to success in the first place. Changing processes sounds risky when it took so much work to get to the current state. Sharing code always sounds much more difficult than not sharing code.

Sharing code always means either replacing something that already exists in a winning product with new code from someone else or adding code that does not completely and fully understand the unique needs of the winning product or its customers. As is almost always the case, the shared code is viewed as bloated, overly complex, or simply does more than needed. Despite the recent success in using shared open source code, the more established a product is the less likely it is to see code from the outside as a preferred path. In 1996, it was always about performance, memory management, or simply complexity. The technical buzzsaw would evolve to include security, manageability, and even privacy/safety—the reasons might change but the goal of avoiding shared code remained. Shared code is a way of ceding your autonomy to another group. Developers have traditionally maintained an attitude of NIH, not invented here, as shorthand for the distrust of OPC, other people’s code.

A a note, startups today love code often extolling the value of Open Source as a way of achieving a good deal in short order. Generally as we’ve seen to date, with success such reception to outside code is tempered.

The benefits to sharing are enormous, and that is what leads teams to take on these challenges. If a product team can create infrastructure and platform assets, then more engineers can focus on category-specific work while also making it easy to add entirely new products to the business with substantially less effort. Office had Word, Excel, PowerPoint, and now Access, but the world of productivity software was vast and it made no sense not to try our hand at personal information management, drawing, note-taking, project management, desktop publishing, or a host of new categories. OPU would be a key part of how to scale both out and over in productivity, and Office96 would be our collective growing pains.

To best illustrate this, let’s look at some of the specifics of what OPU did. The diversity, breadth, and frankly aggressiveness is due to JonDe and his engineering leadership that pushed to do a lot in the first release of shared code out of the gate in early 1994 (a few months before I joined the team). The body of code was packaged in a Windows DLL (dynamically linked library, a Windows mechanism for packaging executable code to be shared, and also the source of endless frustration in the world known as DLL Hell, but I digress though will return to this topic soon enough). The DLL file was ultimately named MSO97.DLL, though sometimes called mee-so (for MS Office) in conversation. Along with MSO, there were a few other files as well as a test harness that could exercise many of the capabilities called Lime. Lime would grow over time and eventually prove out just how much of a platform we were building.

MSO contained code designed to be shared across applications, bringing with that engineering efficiency, experience consistency, higher quality (doing something once brings that), improved performance, and even more features because generally that is what happened with a dedicated effort.

Features were the currency of Apps teams. Features defined contributions. The more visible and customer facing, generally speaking the better. Therefore it was important for OPU to have its own features, not just be a dumping ground for the grunge work that the big teams traditionally farmed out or de-prioritized. An example of this was Setup, the code that copied bits from floppies to harddrives. Almost always getting this done was a last minute sprint and shunted to new hires or even contractors. Apps teams were more than happy to have OPU take this over (without giving up any resources of course). Creating OPU was not going to go that way, so the portfolio consisted of a fair share (or more) of grunge, cool features, and even an app of its own, the Binder. This type of portfolio was critical to the successful creation of an OPU team and culture, giving it an identity beyond simply the plumbing team, so to speak.

Over time and several releases, MSO would be viewed by the entire organizations not as a tax or effort bolted on the side, but as an asset and more importantly a starting point and platform. The journey of building the Office platform would start with the tension and difficulty described herein, and end with new features defaulting to shared efforts, new apps spinning up quickly with MSO, and the organization finding a balance between platform-infrastructure, and category-specific innovation.

Every product (or even organization) at scale finds itself at some point of the swinging pendulum of centralized versus distributed efforts. Often this is viewed through the lens of what is good for the broader business, but at each end of the pendulum is an on-the-ground view of challenge. These views are as predictable as the broader swings. When moving from a distributed to centralized effort (or resources), the formerly distributed accountability will find every reason to doubt the capabilities and necessity, and ultimately viability, of a centralized effort. Over time, the same people and organization comes to rely heavily on the shared team and actively pushes work to centralized efforts.

This dynamic characterized most everything in OPU.

In the work I do with companies today, the topic of scaling, sharing, and building new products efficiently over time is one of the most popular lessons I have the opportunity to share. My own experience was a journey of a career of scaling, sharing, and collaborating, occupied the next 15 years of work. We spent a good deal of time in 2000 describing some of this for a Harvard Business School case, which for many years was used to teach a combination of customer-informed product development and shifting an organization to sharing (see Microsoft Office 2000, MacCormack and Herman).

At the sophisticated end of the platform features was a shared drawing layer, code named Escher. The Microsoft art collection, which had a significant job to do to fill the reception areas and lobbies with something, mostly featured Northwest contemporary artists but had one original M. C. Escher hanging in the building 17 atrium. The acquisition of that was championed by Art Committee member and first Office vice president, ChrisP. Sometimes even Apps had cute code names.

Escher was a big effort spanning all the apps and especially PowerPoint, where much of the lower-level graphics code would be implemented. The integration of Escher into Word was done by a new OPU team, staffed with developers from across Apps. Having engineers that had worked in each of the apps code bases was critical to building shared code to work across those products (again these were the massive products and code bases of Word, Excel, and PowerPoint) and a key decision JonDe made in staffing the teams.

Like all of the new shared features, there was a constant debate across the Apps teams and OPU as to the value of the feature for each team. OPU was in a constant state of selling the value of shared code and the idea that sharing enables teams to get more than they might need, basically for free. Except in practice nothing was free as each app inherited compatibility and complexity that it decided it did not need. Drawing was a great example of that, but it was not even the most controversial.

Every app in Office had some support for drawing, but none were particularly deep and all seemed to serve category specific use cases. Word was able to embed drawings as regions within a document, much like a photo, which is how most people thought about adding illustrations to business documents, if they could draw. Business memos and other documents using simple drawings that could float on top of a document, much like an acetate layer, greatly enriched documents and were recently added to Word but still relatively limited. Even more exciting was the ability to use broadly the fancy text that became known as WordArt, which was new but constrained, as with drawings, to be embedded in regions and not used arbitrarily throughout a document. The complexity of creating feature-rich and deeply integrated drawing tools was daunting in Word. To mitigate this, the lead engineer, Peter Engrav (PeterEn), volunteered to lead the integration of Escher into Word from within the new OPU. A key tool for managing the shared features was that OPU would lead the integration into one of the main apps, thereby learning firsthand the complexity and also minimizing the work to the app.

Excel had elaborate tools for charting (candlestick, donut, 2.5 dimensional, etc.) and some minimal tools for doing callouts and basic graphics on sheets. There was a great deal of resistance to features that were deemed “not something Excel users requested” or even features that were viewed as less than professional or business-like, whether that resistance was genuine or simply a sort of buzzsaw didn’t really matter. The Escher team constantly received inbound “doubt” over any features simply from the perspective of it not being interesting to Excel users.

At the other end of the need spectrum was PowerPoint, which was basically a big drawing program. Why would a drawing program want to use a shared code base, as that was their entire domain? As though to emphasize the maximum complexity of sharing code across these apps, PowerPoint’s main concern was that Escher wasn’t enough for them competitively, simply because they were spending time putting drawing in Word and Excel—neither of which appreciated drawing as much.

See how that worked? That’s the “middle” that OPU found itself in as a platform team for already successful products.

Escher would go through many rounds of adding features for compatibility with what was there and removing features because of schedule constraints, along with challenging debates over features versus integration. The end-result, however, was a tsunami of graphics features across the product. Every product picked up integrated capabilities previously found only in high-end and rarely-owned professional tools including drawing shapes, modern graphics files formats including transparency, photo handling, shading, animated GIFs (like the best viewed in Internet Explorer logo on all the HTML files we created) and even an integrated and vastly richer variation of WordArt, the curvy, glowing, bubble-text so popular with grade school children and small business signs. A huge part of Escher was that much of the shared work was also done from within the PowerPoint team itself. PowerPoint was also located in Silicon Valley and this was the first time we had embarked on sim-shipping deeply integrated code across a plane flight.

While the debate over Escher was intense, the debate over the core or primary user interaction (meaning the user interface) in apps was even more so. The core user interaction in Office took place through toolbars, which were a primary source of app innovation—so much so that the image on the box and most screenshots in the press were of the toolbars. In an effort to build a suite, one sold with a value proposition of consistency and muscle memory, it was only natural that we tried to share toolbars—do them right, do them once as Lotus claimed to do.

In modern context, this might seem trivial, but at the time this was a key innovation. With the different teams on different schedules, but with a shared DNA and understanding of potential solutions, it was no surprise that there was some common evolution, along with opportunities to be a little bit better, or different, depending on perspective. Toolbars proved legendary in this regard.

One of the first battles we found ourselves in was over the design of toolbars. Word and Excel had each designed and tested their own toolbar implementation and arrived at different heights—15 versus 16 pixels. Trivial to mention, but research done separately by Word and Excel, surprisingly, showed that Excel and Word users had different preferences—obviously due to test design or some other factor since it is ludicrous to think this differed by app. This might not have mattered except that the main marketing demonstration of Office showed Excel embedded charts within Word. Clicking on the chart loaded the Excel toolbars and caused a one-pixel shift in the document. As if that weren’t enough, there were equally divergent views over the design of the tooltip, the little text that appeared when the mouse was held over a button explaining what the icon might be. This invention had those that believed the tips should be white and those who fought for yellow, not to mention debates over the delay, stickiness, amount of text, whether the keyboard shortcut should be there, and whether there was a choice to disable them. Even the simple features, no matter how new and clever, were impossibly difficult to coordinate.

Ever the diplomat, Andrew Kwatinetz (AndrewK) spent the better part of the product cycle ironing out, negotiating, and pleading consistency across the the products. Andrew was already deeply experienced, as an intern and college hire, in both Word and Excel user interface design and had already proven himself to be one of the next-generation leaders of OPU. Early in the product cycle, Andrew sketched out all the places across the product that lacked consistency and coherency as an original volunteer in the newly formed OPU (and its prior form, the Apps Interoperability Group), and he had begun to map out plans to bring the product together and innovate in user experience.

Having committed to sharing the code, we finally had in one place all of the buttons, menus, and commands for all of Office—thousands of entries in a single place. Pete Morcos (PeteMor), a recent college hire, arduously managed them all by maintaining a database of every icon, command name, tooltip, menu string, status bar text, and keyboard accelerator in the product. The difficulty and attention to detail required was only matched by the long-term value for consistency, localization, user assistance, and most of all ease of use. One of the most significant differences between Office and most other tools, even today, was the sheer breadth and simultaneous depth of features, something that would become even more apparent as web pages came to the forefront. Each application had over 1000 commands (buttons, menus, etc.) with something over 2500 unique commands in Office96. The scope of the product would be further amplified by the platform APIs available through Visual Basic for Applications, another major shared effort that enabled developers to build custom applications based on Office.

The sharing was enormously difficult, taking a toll on the OPU team and frustrating the Apps teams. We were a year or so into the project and, while we were clearly making progress, we were also moving more slowly than we needed to. We had not taken the time to adapt the organization to sharing nor did we really consider the breadth of the undertaking.

The team was so frustrated that JonDe and I decided to have a meeting with VP ChrisP and SVP PeteH to discuss “the situation.” It was a combination of us asking for help and us being called to the carpet for the situation bubbling up to them from the Apps teams.

My own memory refers to this meeting as the one when JonDe said, “People think Jon has lost his marbles” and thus I recall the meeting as the marbles meeting.

I had put together slides with some basic philosophical problems we had been dealing with across primarily OPU, Word, and Excel. There was nothing really new in the deck. I had previously sent a couple of really long emails basically warning that things were challenging, and progress was slow. PeteH was hearing the other side of this from the Apps leaders—how things were slow because of OPU’s shared code that wasn’t needed and features they didn’t want slowing things down, making the products bigger and slower, while taking time away from doing features that could win customers and reviews. I’m not exaggerating.

The key moment in the meeting was when JonDe explained how crazy things had become. A year earlier, Jon was leading the Excel team through a hugely successful release and prior to that he had been a key leader for the entire history of the product. He epitomized everything about DAD culture. Yet all these developers that idolized and looked up to him suddenly believed he’d lost his mind and somehow gone crazy, drunk off the Kool-Aid of shared code. His old team stopped believing his schedule estimates or even architectural approaches. Jon had clearly “lost his marbles”. We were deadlocked by the “Word users are different,” “Excel users are different,” and “OPU is wasteful” mindsets.

We vented and PeteH listened. Still, it felt like there was not going to be any immediate change. I had hoped they would do something simple like send mail to everyone saying to listen to us and this is the way it is. In hindsight, that was desperate and totally the wrong way to solve the issues, but our frustration levels were intolerably high.

Somehow, things did change, though. PeteH and ChrisP worked quietly in the background doing more to reinforce both the strategy and execution of Office96, the focus on shared code, the consistent experience, and the notion of one team working together to make Office. This happened in all the right ways through mostly small or 1:1 meetings. That was the DAD culture. Pete was savvy enough to know the team would not react positively to some sort of commandment or over-the-top edict about sharing. The subtle persuasion and repetition were what the team needed and got. Eventually, the Apps leaders were reaching out more, and over the following weeks we saw the how the climate changed.

Our view was that BillG would be quite proud of the sharing. We thought for sure the idea that breaking down the barriers between apps and improving the architecture of everything would be viewed extremely positively.

The product was still impossibly difficult to run, though we had stable daily builds due to sheer force of will from JonDe, GrantG, and the development and test managers, but there was two years of work ahead as things started feeling better. Even with bumps on the road ahead, I was feeling good about it all.

Every month, I gathered up the status from across the project for an email report. Each team (Word, Excel, and PowerPoint as well as Escher and all the OPU contributions) contributed a section with information on progress—the PDL, or product development list, in reference to the spreadsheet of all active projects. The individual apps also created PDL reports, even though our goal was a single product release. There were two important items to cover. First was the project on time. Office96 appeared to be generally running on time, at this point, so the update was benign though unknown to us we were also naively optimistic.

The second part of this update included the process that was near and dear to DAD, which was adds/cuts. Throughout the development, particularly after an eight- or ten-week milestone, each team, at a granular level (individual developer), reevaluated the list of work items (tasks taking about a day of development or so) and considered the progress made versus progress required. The result was almost always feature cuts—removing proposed features from the product. There was also learning along the way. There were also adds: enhancements, new options, or reworked features. JeffH had always taught me that transparency and completeness were critical to how BillG thought, so my PDLs were works of art in those attributes. I worked super hard to bring the product to life with some clarity.

Upon receiving one PDL for Word, BillG replied to let us know two things:

First, we were cutting too much. “the number of cuts is truly amazing to me” he asked in red text. In fact, in the effort to be honest, my PDL looked like we were gutting the product every month. That was not the case. In DAD, the basic approach was cutting is shipping, so in order to ship we would scale back features as we learned more. That was how the process worked and everyone was comfortable with that, at least within DAD.

I felt horrible for the team and certain the email would result in people quitting and Apps using it as a chance to say, “OPU was a bad idea.” That concern was followed by worry that I was going to get fired. Were we on a path to a bad product? Was I leading us in the wrong direction? Was I messing up? Or perhaps this was all a communication problem.

Separately, Bill chose to highlight some specific features that he felt strongly about. This inadvertently (honest, it was unintentional) allowed the Apps teams to say that the OPU efforts and resources were robbing the apps of features that Bill would prioritize. Ugh.

The right thing to do was to show BillG some progress, but without the ceremony of a full review.

We were early in the development of Office96 and most features were merely crawling. Most of us were not running the product on a daily basis as it was not ready (called self-hosting), and certainly it was neither ready for BillG to use nor was it a polished demo. Nevertheless, I took it upon myself to set up some time and march over to BillG’s office with my laptop, talk through the PDL, and show him some carefully curated features. It was a risk, but so was debating in email or letting the issue fester.

It was a quick 30-minute “drive by,” and one of many that I routinely did over the years. I made clear I was not showing features specific to Word, Excel, or PowerPoint—the dynamics of the DAD organization would not have looked kindly upon that as I had no responsibility for those features. Rather my goal was to put Bill at ease over the investments of shared features. I showed off the toolbars (called command bars as they brought unification of both toolbars and menus), Escher drawing, highlighting the depth of the work we were doing. This was enough to put him at ease for the time being. It was a good lesson on how the verbose nature of the email status report was mostly undermining the goal of showing off progress.

The demo went so well that we separately held another demo session at the end of the milestone. In this one we filled the room with members of each team and everyone got to show off the work of their team. It also served as a reminder that while there were plenty of shared features, a large part of value of the release came from the domain or app-specific features across Word, Excel, and PowerPoint. We had a new saying now, which became “we’re selling Office, now we’re making Office, but people use the individual apps”.

After the meeting, I nudged Bill to send a nice note summarizing what he saw and served to solidify the progress we were making across the team and undo some of the earlier nonsense.

And it was a good lesson that working software beats a status report. Onward.

On to 042. Clippy, The F*cking Clown

Welcome to Chapter VII, 1995 to 1997 and Office 97. As PC sales surge, growing at a rate of 60 percent in 1996, the enormity of the internet becomes widely realized and will soon dwarf the impact of everything that came before it.

The Apps and the Office team were 110% focused on what should have been the last months of Office96 as part of our 12/24 plan of parallel releases. The product turned out to be much more difficult to finish and the new Office-centric organization met with much more resistance than planned. On top of that, Office 95 took our entire Test team to get out the door, putting us behind on quality. In other words, the 24-month project was going to take longer but we did not yet know how much longer.

Something about Windows 95 shipping changed Microsoft, especially at the top and how the company thought strategically. It was as though with the success of Windows 95 came the need, though not necessarily the ability, to think big thoughts and to develop big plans for the future. The products we were working on were a given, but just not interesting. Everything interesting was yet to begin.

Or was that really the case? A post about planning for a big future while trying to build a product that was already late.

Back to 039. Start Me Up

It was as though we had not been working on Office96 for the past year. With all the excitement of Windows 95 (oh, and Office 95) the conversation quickly turned to asking what would Office do next, after the release we hadn’t even finished and was late. It was kind of weird.

In a relatively short time many things changed. MikeMap retired and with that a slight change in the organization to accommodate, with BillG taking on product groups directly. Microsoft Research was a few years old and occupying more and more of BillG’s headspace. Windows NT 4.0 was on a path to completion and with that a solid spot in the minds of IT leaders, especially for the most anticipated business product of all, Microsoft Exchange email. The much-anticipated Cairo project began to fade in interest and what became more interesting (and ultimately much more important) would be bringing the Windows 95 user experience to the Windows NT operating system kernel. The browser war between Internet Explorer and Netscape and the broader competition over back-end server technologies for the Internet was well underway. Windows would kick off a series of updates to Windows 95 primarily for the benefit of holiday or back-to-school PC Sales (Windows 98, Windows 98 SE, and finally Windows Me). For Office, by many accounts it appeared as though Office had successfully taken the leadership position in the new product category of suites. We were still paranoid about competition especially that Lotus was now owned by IBM and had a huge sales motion behind it.

That seems like a lot of work going on and it was, but from a company strategy perspective it was as though that was all known and thus, for lack of a better word, boring. The real excitement and interesting work was answering the question from BillG “What is Next?”. There was an almost insatiable demand to know our plans for a few years from now, not our current development efforts. It was rather sudden, but soon the altitude of our company dialog was less about the products under development and more about what products should be under development. The concern or even fear was not losing in the next release cycle but in the ones that came later. Intellectually that seemed prudent, but practically it was enormously frustrating as I would alternate between significant execution challenges and vague discussions about an infeasible future.

There were people in parts of the company that had what were considered great visions for where to go, but it always seemed to me like there were practical ways to get to 90% in much less time. Others had ideas for how things should be done, but clearly there was no way to build those now because of some limitation like how different everything else would need to be to be able to build that. Innovations like work from General Magic captivated BillG and everyone but were not selling well (even with a big IPO). As I’d become accustom, a failure in the marketplace was not a failure for BillG so that meant we needed to treat it like a potential competitor. I needed to find a way to engage in this dialog and to represent applications and productivity effectively as “thought leadership” (a popular buzzword).

We were still deep in building Office96, the second part of the 12/24 strategy of working on a pair of releases in parallel. In fairness to me, this was occupying every cycle I had. We were almost two years into the project by the end of 1995 and it was clear we were going to ship much later than planned. Yet, no one really wanted to talk about Office96. Rather, everyone wanted to talk about what would be next. What would be big and bold. To us, Office96 was huge. The scale of the product was greater than anything we had ever done, greater than anything done in the industry.

Office96 did not have any of the a priori constraints of Office94, other than shipping as a suite all at the same time. At the start of any release in early 1994, product teams were thinking big. This time, in addition to each app, there was also the new OPU team (Office Product Unit) team thinking big. Aligning these big thoughts would be add to the challenges.

Our Desktop Applications process was a unique expression of a product development lifecycle. It was not the historic and inappropriately applied moniker of “waterfall”—a legacy process where first requirements are gathered then specifications written, and then code developed until testing signs off. It is also not what would be thought of as agile, in more current terms, when products are increasingly built up over time constrained by short cycles or sprints (primarily because we took a long time, though some also would say because we did not change the software in response to external inputs along the way as well). Throughout the development schedule the product was kept stable and usable by the team but not in a shippable state until defined milestones or beta tests.

The Apps/Office process of setting large aspirations that span 18 to 24 months and scaling implementation as the project evolved was unique at Microsoft and clearly the source of the stability of the products and the position in the market that continues to benefit the company today. Apple remains a lone exception and has brilliantly mastered a delicate balancing act of consistent yearly releases (unbelievably amazing) and long-term product plans patiently released over multiple years. Business is a social science and as such drawing causal relationships between processes used at different companies is risky thinking.

Whatever one might call this process (it just became known as the Office process), the assumption BillG had was that whatever we were able to articulate to him was already booked. On the one hand, this was great and it meant he could count on us to deliver. On the other hand, it was incredibly frustrating for him for two reasons. First, the ability to articulate a product extremely concretely—literally with early working code that he knew would ship, screen shots, and endless specifications—meant it was going to feel done and immune to his tweaks and inputs. Second, the very existence of a working and reliable product meant that it was time to move on. It was almost a curse of being perceived as reliable and focused on execution. Still, we were very late and didn’t even know how late we were.

BillG and NathanM leading Microsoft Research were focused on 5 years out or more. There was nothing special about that time, other than it was longer than anyone was already working. We used to joke that if from the very start a project took 3 years to complete then everything beyond that was infinity years away. A project that someone said would take 5 years would never finish. The world would be so different by then and the choices we would make so different why solidify plans now. That argument did not hold water at all. We had to do something to move this discussion forward. We started writing more and taking risks in talking about the future, a future we were not quite working on yet. It was uncomfortable.

First, we set out to cast Office96 in more futuristic language and goals. In other words, re-skin Office96 not as what we were doing but as what we could be doing next on top of it. We called this Project X. Nothing about Project X existed at all. It was simply a name and a memo to have a discussion. Design manager Brad Weed (BradWe) and the design team even mocked up the ideas in Project X and we demonstrated it at the Company Meeting and in a vision presentation at COMDEX in 1995. Brad began hiring designers from the new programs in interaction design popping up in Europe, particularly in UK and Netherlands, including from the Royal College of Art (where Apple’s Jony Ive has long been affiliated). To kick off the process I made my own demo—a single screen illustrating the concepts I thought we needed to show off. It is comical in the use of clipart and PowerPoint but it was a good conversation starter with design.

Project X took over the desktop with a series of new metaphors. There were filing cabinets that contained binders that could be constructed by searching across all your documents, not just physically storing them. Calendaring with a timeline view and task management would be easily accessible. It would be easy to have small notes (Post-It like) attached to any item in the system. People were the center of activities not just documents, with easy access to contact cards. A little teddy bear, a loveable precursor to a paperclip, was always there to help you as an intelligent agent. There were also virtual desktops so each project a person might be working on could have its own set of tools organized appropriately and quickly switch between them. All of these were rooted in Office96, but projecting out years if we had more operating system services and synergy.

Working from this sketch the designers (after deservedly mocking me) created an interaction sequence that was an ultra-modern skin, so to speak, on the features of Office96. The designers were the same ones designing the real menus and dialog boxes, so it made sense. And like that, everyone was far more excited in what was to come than in anything we were currently working on.

That might seem like a success, but in fact it quickly blew up and many across the company became either concerned or needed to know more so they could adjust their plans to fit in with Project X. In some parts of the company this would be viewed as huge win. For Office this was a problem. We not only had to finish Office96, but we were a big business and the last thing we needed to do was to need to explain to customers that the Office 95 they were thinking of buying would be obsoleted by the new cool Project X. So, I quickly wrote a memo explaining Project X. While I spent most of the memo explaining the features shown at the Company Meeting and how they related to the real work of Office96, I also used it as a chance to try to align the work of Windows (still called “Systems” by many) and Apps.

Although this sounds totally drastic, this memo will make it clear that we were really building Project X all along, though we lacked a shared vision of how it all fits together. In this memo we will detail the various technologies and architectural components that make up Project X, who is responsible for the design, and who is tasked with building them.  

While a lot of people were excited by Project X, they were less excited by the prospect of trying to align all of our products again after Windows 95 given all the work already going on. In particular, I was learning that the job of aligning fell to Office to align with Windows, not the other way around. Office needed to do a better job of using the new underlying technologies in Windows to build applications. Except there weren’t any new underlying technologies. What BillG wanted to do strategically was repeat the GUI Windows-Excel innovation cycle, but what was the next GUI, the next app?

So back to writing. Realizing that the problem seemed to be not as much a lack of big thoughts, but a lack of ideas for evolving the whole of the platform, meaning Windows and Office. In my memo “On the Evolution Of Office” the key thing I put out there was that while we just finished 12/24 of two releases in parallel, then why not “12/24/48” and start working on something four years from now! I wrote that while Office96 was slipping and the team was reeling from the trauma of trying to do two releases in parallel. We weren’t being political as much as just trying to put forth some framework for talking about the future that was infinity years away. NathanM loved it!

By betting all or a portion of a team on building 48 month developments into the current product, we are doomed to failure.  No group is smart enough about our industry to know what bets to make now in our products today in order to have them pay off in four years, all in the same product.  One way to think about this is to ask what features were worried about four years ago in Excel and compare that to what ended up in the product.  Although there are some things that have been perennially on the list of adds, and then cuts, the marketplace clearly did not miss them (though perhaps we regret not having done them for development efficiency reasons).  We can continue to explore how to just “extend” our 24 month cycle to a 48 month analogue, but it would be hard to convince me that we would find a process by which we can work on meaningful features in parallel with our current products.

What is needed, though, is a redefinition of the 48 month aspect.  Instead of thinking of it in parallel to our current process, we should consider the 48 month time frame to be an independent bet on something that we think (strongly believe) will pay off handsomely in the four year time frame.  In other words, while we should continue to bet largely on the code, process, and architectural aspects of 12-24, we must look hard at the current state of the marketplace and products and spend some of our efforts on a completely different effort.  As PeteH likes to remind us, we must be sure that the “generals are not fighting the last war.”

What was most important to me was helping not just BillG and NathanM but the rest of our team to see that we were not crazy. So to do that we took a concrete technology approach to describe all the places in the applications that we made assumptions about how PCs worked and why those needed to change. The reason assumptions needed to change was because Moore’s Law was firing on all cylinders across CPU, RAM, disk space, along with Metcalfe’s Law on connected networks becoming increasingly powerful clearly describing the growing internet. Designing our software for an old world was just dumb. I really like the idea of documenting the context and assumptions of a product to force a rethinking of what still makes sense, or not.

The analogy I used was that “code is like a dinosaur” implying that the comet that hit our codebase was the Internet. The assumptions baked into Word, Excel, and PowerPoint make for a long list of potential points of competitive weakness (disruption was not yet a word in business vocabulary, but that would fit). These assumptions included:

* Stand-alone applications dominate

* Categories consisting of spreadsheet, word processor, presentation graphics, database

* Testing software was an afterthought, or a small portion of development at best

* Teams were started with 2-3 programmers, but we reached a limit at about 40

* The product architecture was really the work of “one guy”

* Sharing code is hard

* Disk-based file formats

* Networking limited to file/print sharing

* CPU bound applications are the norm

* Virtual memory not available

* Operating system services are slow

* Users can run setup on their own

* Documents are primarily printed

* Images in documents are primarily adornments

* Macros were run in process and for a single application

* Most information is stored locally

* Document structure manipulated and created by the user

The dialog now shifted. These were topics we could discuss across teams and meetings. In a parallel list, the memo offered some ideas for new assumptions we could make about building productivity software. I realized that Project X had not done enough to incorporate the Internet and so we focused much more on how that changes everything:

* Drawing and graphics are the norm, not an exception

* Virtual memory replaces disk-based file formats

* Multi-stream documents are the norm, along with progressive rendering

* Interoperating with Internet protocols is a requirement

* Programmability should start from higher abstractions than the user-interface

* Documents will be viewed on-line

* Documents will contain more active, user-encoded behavior

* Applications need to be easier to setup and install

* Knowing the structure of a document is of paramount importance

* File formats need to be tagged for upward compatibility

A few more months would pass and the Internet would be more solidly represented in our products. In fact, we were well into building and innovating in Internet Explorer, Internet Information Server (Microsoft’s web server), Internet capabilities across the Office applications, and more new products than we could name. This led to a final manifestation of these ideas with a decidedly web-centric view. So a final memo before we got around to actually shipping Office96, was “Web-Centric Productivity”.

In this memo we articulated many ways that we could build applications to take advantage of the web, across storage and management of documents, personalization, collaboration and annotations, solving our setup and deployment problems, and more. We did yet another prototype called Project Stretch to visualize these ideas. As mentioned many times before, I had a disdain for code names, so this is a tongue-in-cheek reference to a famous IBM project that was not commercially successful but led to many core technologies for later mainframes.

The click-through prototype of Project Stretch. It is fascinating to consider this in the context of today’s Internet. At the time we made this, a browser could render just a few dozen text formatting tags and images, with most user interface being done as big click buttons. Scripting was new to browsers by just a few months. ActiveX was the big bet the browser was making, but this was something that raised concerns given the Apps experience with the underlying OLE technology.

Stretch envisioned an Office available all the time, from any device, running in an industry standard browser. It was mid-1996 while Internet Explorer 3.0 was being developed, and as such it predates technologies that became essential for creating richer, desktop-like, user experiences (even scripting was only months old, technologies like DHTML were years away). HTML as it currently stood had only the most minimal text rendering capabilities, which we found troubling in Office though we were determined to adopt it. The most interesting strategic bet being made (in Internet Explorer 3.0) was what became ActiveX, which was rooted in OLE and thus something that concerned me while also saluting the strategic flag. The prototype became a way to articulate what would eventually lead to products such as SharePoint and OneNote, as well as underlying technologies for sharing and collaboration.

With this executive level, long-lead effort going on in the background, the real work of building Office was taking place. Each and every day was a new challenge in the face of ever-increasing scale. What was once three independent application teams in Word, Excel, and PowerPoint, along with a new product for email and a new team called Office building shared code, had to grown to be a single, well-functioning product team. Still, we were not yet where we needed to be.

Office was late. The team was not gelling. It was painful.

On to 041. Scaling the Office Infrastructure and Platform

It has been 26 years since the Windows 95 launch and still no launch from any company has come close to the global scale and impact of the event. There have been big events and massive opening weekends for many products, but nothing like August 24, 1995. Even from our supporting role in Office, it was an event of a lifetime.

While we signed off in July, our focus immediately turned to continuing to build Office96. The world would treat Office 95 as though it was a major new product from Microsoft, but we knew we had put most of our development efforts into the next release of 12/24. We were also behind because one thing we learned about parallel releases was that 15% of our engineering still required nearly all of our resources for testing, marketing, and the rest of the product pipeline. We could in a sense fool the market that we did a full release but we could not fool ourselves.

The other industry-shifting event happening at the same time—in hindsight, perhaps foreshadowing—was the Netscape IPO. Windows 95 was big, but the Internet and WWW would prove even bigger. In the years that follow, it became much clearer that Windows accelerated the adoption of the Internet long before it was threatened by it, and more importantly by mobile phones. . .and Apple.

Back to 038. Designed for Windows 95

Please feel free to leave a comment or memory about the Windows 95 launch and impact on you. For this post comments are open to everyone, not just subscribers.

By late July, Word, Excel, PowerPoint, the Office 95 suite (called Office Standard), and a number of other products from all over Microsoft were off to manufacturing. This only left four weeks for the manufacturing and airlifting of retail product all around the world. The baton had been passed to marketing and logistics.

Just after sign-off, I got a call from my mother that my grandfather was ill. I flew back to Miami immediately. Pop was 90 years old and up until then had been perfectly fine, walking miles every day around his North Miami condo complex, Point East, (Seinfeld fans picture Del Boca Vista). Sitting beside his hospital bed, we talked about a lot of stuff. His biggest frustration was that Microsoft was not paying a dividend. He was a depression-era person with little faith in the rise of equity. He would often send me newspaper clippings and earnings press coverage via postal mail, something many of us experienced from our Greatest Generation relatives. That said, he also would place a bet on anything with a starting line or a clock and we had spent most of my vacations at the Hollywood Racetrack betting his numbers, 6 and 7 or 4 and 8 (the birthday he shared with Grandma). His winnings paid for my nursery school and summer camps growing up. When it was time for me to leave, lying in his bed, he wished me a happy birthday (my thirtieth) and flicked his wrist at me and said, “Get out of here, don’t worry about me.” Two days after the Windows 95 launch event, I flew back for his funeral. We celebrated the full life he lived.

Planning the launch event consumed DAD marketing (development team was still mostly working on Office96), with product availability, newspaper and magazine ads, all the tools needed for retail point of sale, and especially public relations. By 1995, the tech press had become a mainstream phenomenon and all major newspapers, magazines, and even television networks had dedicated technology reporters. I had no idea how much time I would end up spending supporting our marketing team as the “product” person in all sorts of interviews, demos, lunches, and more. This was the release at which I met most of the industry beat reporters and established relationships that still exist.

Everyone was writing stories and reviews of Windows 95 and Office 95. Everyone.

Shipping Office 95 as a single product was a huge accomplishment for the Desktop Applications Division, and it was only fitting that it was a small part of the myriad accomplishments under the leadership of Mike Maples. As the previews were going out, Mike announced that he was going to retire from Microsoft and live full time in the Hill Country of Texas. While many of us stayed in touch with him for decades, in 2016 I had the privilege of coteaching a class at Stanford with Mike—teaching alongside my teacher was a great joy.

Without Mike, Microsoft would have become a different place. Mike brought to Microsoft, especially to Apps and Office, a culture, attitude, and strategy that perhaps more than most any other person were responsible for the success of Office, a success still felt decades later in Office 365.

The Redmond, Washington, launch event was set to be the biggest and craziest event ever hosted on Microsoft’s campus. The entire sports and grass area, about two football fields, was tented that third week of August. Most Microsofties ended up watching in the conference rooms all around campus.

For the tech press, the event was the culmination of months of writing about the ever-expanding impact of Windows 95 on computing. For most, however, the rise of the internet and Microsoft’s new and more critical competitor, Netscape, fresh off its public offering a few weeks earlier and worth over $3 billion was getting equal, if not more, attention.

Even the conversations we had with each other inside a tent on the field were internet related. At one point I ended up in a conversation with BillG and his new technical assistant over “internet search.” Because of the work on the Office 95 “personal Lycos” feature, there had been a newfound interest in internet search (Google was still almost five years down the road, and many “search engines,” including Lycos, came and went). I was making a strident argument with Bill that the future of search would be full text indexing and not the currently dominant index hierarchy of Yahoo, which was all the rage. Bill loved libraries and hierarchy and he asserted there would be a hierarchy. We went back and forth on this for months, but there’s some irony that we debated this at the launch of Windows 95.

My official role at the launch was tech support for the demonstration of Office 95.

The demo fell to Office product manager Sarah Leary (SarahL). Sarah joined DAD marketing straight out of Harvard and was already a veteran of several major launches. Sarah was mostly focused on the business motions and strategy for the launch, and she also happened to be the best demo showperson, probably in the company.

This was not just any demo. She was flanked on one side by BillG, a frequent demo companion, but on her other side was Jay Leno, who was then the relatively new host of The Tonight Show and the clear leader of late-night TV.

Sarah scripted the demo to show off the key integration between Windows and Office. There was a nail-biting moment when it was time to bring up a print dialog. Normally, a demo would never include anything that could possibly “hang,” like printing, but she pulled it off and skillfully showed some of PowerPoint’s new animations and used PowerPoint’s new Top 10 animation to create a Jay Leno Top 10 list.

We didn’t hire professional writers like a giant company might—we wrote the jokes ourselves. My contribution to Top 10 List: Windows 95 and Office 95 was “OJ Says, ‘Office 95 fits Windows 95 like a glove.’” Cringeworthy years later, but Leno loved it since OJ was a late-night staple. The crowd laughed and that joke made it into a box on the front of the USA Today newspaper.

There were countless parties all around campus as the launch event was, in fact, the ship party for all of Microsoft. The evening after the main launch event was filled with parties, dinners, and drinks all around Seattle. I had dinner twice with two different groups of reporters. Then at the old Capitol Hill home of B.P.O.E., the coolest after-party was hosted by the marketing and dev evangelist team, many of whom were the first people I demonstrated the Internet to just 18 months earlier. In the most hyper-self-aware fashion, the party was a sea of blue and white cloud-covered cups, plates, napkins, Koozies, frisbees, and more, each labeled appropriately in Franklin Gothic, the official font of Windows 95. There was Plate 95, Cup 95, Napkin 95, all while hip Seattle grunge music (mixed in with ‘80s cover band fun) played late into the night.

Ultimately, as the reviews revealed, Office 95 represented the last release where individual apps would be evaluated versus suites. Word, Excel, PowerPoint, and Access more than held their own in category reviews by and large, handily winning the roundups. When it came to suites, the combination proved even more formidable. We achieved this using only 15 percent of our development resources, something that was not lost on me. The reviews mostly treated the release like a big deal, even though it was almost a side project to our team.

As we were finishing, Hank Vigil (HankV), the leader of DAD marketing, told JonDe and me he was so excited that his biggest worry was that Office96 would finish too soon, frustrating customers who would be asked to buy another release. Because Office 95 was delayed by the Windows 95 schedule, he was worried that 12/24 would end up being 18/24. Jon and I shrugged, knowing the realities of our schedule at the time. But to think there were business worries we could release too much new code too soon was interesting.

It is difficult to imagine today, but the idea of an excess of software was top of mind of most corporations. Customers were overwhelmed by the quantity of software being produced by vendors. And to be honest, customers were underwhelmed by the quality. The burden was not as much new features and fixing problems, but the dreaded Total Cost of Ownership and the ability for customers to deploy and manage PCs and train end-users who were still not always computer capable. While it is difficult to imagine this predicament, it would also profoundly influence the next ten years of how we built and released products and how Microsoft established relationships with customers that would supplant those built by IBM over the past 25 years.

Despite some low-level rumblings of best of breed versus suites, customers moved on, preferring an integrated set of applications. The suite competition simply wasn’t there. Lotus delayed building apps for Windows 95 and was the only vendor with a full suite. Borland and WordPerfect teamed up, but two companies building an integrated suite proved to be challenging. Corel would soon be the owner of those assets, choosing instead to focus on the low price and individual market.

In competition it is said that it is not enough for the competitor to drop the ball, but someone had to be there to pick it up. The strategic bet on Windows 95 and the strong execution of Office 95 were a great combination at the right time, when competitors were focused elsewhere. Windows 95 and Office 95 provided further evidence of the virtuous platform-apps cycle that was such a part of Microsoft’s history.

The internet and shift from document creation to communication and collaboration was next for Office and would prove challenging for Office96.

Windows 95, even with the unpredictability of the development cycle, proved to be arguably the defining product for Microsoft and the PC industry for the next decade. Reviews around the world were fantastic. The only people who didn’t like it were in Cupertino (and a few in Armonk). The explosion in computing at home and work could be directly attributable to the ease of use of the product, ecosystem of partners, and availability of multiple varieties and price points of PCs. Just as BillG had strategized, adding Office 95 to the launch despite the reservations of our team further validated not only the capabilities of Windows but Microsoft’s commitment to GUI, Win32, and the developer platform overall. With Windows 95, the PC ecosystem or flywheel as it was frequently called was in full effect. The economics of hardware, peripherals, software, training and consulting, custom business software, and support for all of those were present and growing at a scale that was unprecedented in business.

With Windows 95 and Office 95 shipping that day along with probably a dozen other new products, the event was really the launch of Microsoft 95.

On that day, August 24, 1995, Steve Jobs was still a couple of years away from returning to Apple, and what was once Microsoft’s most intense competitor, the PC, left the adolescent era of computing and was entering early adulthood. The fact that Apple chose to make a brief appearance with a full-page ad in the Wall Street Journal (and Financial Times and their hometown San Jose Mercury News) mocking the old 8.3 filenames of MS-DOS saying “C:\ONGRTLNS.W95” (I still have my copy framed!) was looking like a rout. Oh, and a giant sign in tow behind a truck also made its way past the soccer fields. Apple even had a fairly snarky four page insert that made up a series of billboards at the airport touting new features of Windows 95 such as long files with the tag like “Imagine that.”

I walked (or stumbled) a few blocks home from Party 95 feeling a strange sense of completion but realizing that Office96 awaited me as my year of multitasking would give way to a chance to focus completely on what was ahead.

Windows 95 was a new start for PCs. The PC emerged from a hobbyist tool or a tech novelty, to truly something for every desk and every home just as BillG and PaulA envisioned. We were so focused on making everything work and getting the products to RTM that for many of us our accomplishments would not sink in until we went back to visit family for the holidays. Those were the holidays nearly every one of us would forever remember as the start of family tech support.

The PC had indeed matured.

On to 040. Creating the first Real Office [Chapter VII]