048. Pizza for 20 Million People
“And, believe me, if we could put the keyboards in this closet we would.” –Ford Motors IT professional describing the best way to reduce complexity of a PC
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.”1
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
After publication, the member of the OAC representing Ford contacted me to say that he recalls this very story, but not from Ford rather it was from another major industrial customer. Such is how anecdotes about customers end up making their way through to become legends. My recollection of the story comes less from Heikki and more from how SteveB relayed it to me.
Great article. As a member of the TCO team, I remember much of this history. Not only did we get to know the OAC members, but they got to know each other. At the beginning there was a lot of skepticism among the members thinking that there is no way that Office will ever get what we do, nor will they ever really understand what our needs are, but we'll go along for this ride to see where it goes.
Toward the end of the cycle when we were presenting the breadth of the TCO features, one of the greatest compliments was hearing that "you guys really do get what we do" and seeing all the heads of the OAC members nod in agreement.
The OAC also helped us create a better version of the next ORK (Office Resource Kit), as well as what we needed to present at the worldwide Office Deployment Conferences. Because of the OAC, we had a lot of confidence in what was created.
These articles or chapters, especially the last two, have instilled in me a sincere and deep admiration for your and to a good extent Microsoft’s commitment to methodically addressing the problems of software development. Whatever the outcome, the process (at least so far in the story!) never seems to slip into reductionism or defeatism. It takes some grit to stare down these issues and dive into these acronyms and situations. I think many younger tech companies could stand more of this sort of direct engagement with customers.