074. Outlook Pride, Finally

Each module of Office deserves a shot at being the hero of a release. That’s how a healthy product bundle should move forward, rather than relying on a single anchor. Excel 5.0, Word 97, PowerPoint 2000, Access 2.0 anchored Office Professional. While Outlook was top of mind for IT infrastructure managers, it remained complicated and frustrating for regular end-users. Embarking on a radical redesign of a major product is a career opportunity and also a big bet for a critical business that continued to be half of Microsoft. That would be difficult enough, but nothing is that straightforward. Outlook would still face internal pressures of strategy and alignment that have made building a breakthrough release so difficult previously. Would this be the moment for Outlook to shine?

Back to 073. **DO NOT FORWARD**

Outlook barely worked. Still.

Such was the product-market fit of Outlook that enterprise customers owning the latest in all the Office tools were routinely deploying the newest Outlook while leaving old versions of the core Office apps on the PC.

Five years and three releases from the debut of the product, Outlook remained fragile, bloated, and too difficult to use. It wasn’t as though the team hadn’t executed, releasing Outlook 97, Outlook 98, and Outlook 2000 in the span of just over three years. Rather the team, through little fault of their own at least after Office 97, whipsawed through strategic initiatives. First, they had to split the product into internet and corporate modes. Then they had to merge the product back together while attempting to integrate with Office and the deployment tools of Office 2000. Then they had to charge up the hill of unified storage for the second time, only to cut the feature again at the tail end of the project. As if this wasn’t enough, the past couple of years saw the rise and unveiling of NetDocs which pivoted to a potential Outlook replacement, only to see that vision meet reality.

Marc Andreessen, founder of Netscape, wrote in 2007, years and a generation after the release of Outlook and long after the demise of Netscape, “The Only Thing That Matters”. This short piece codified product-market fit. Essentially, he said that the market pulls a successful product out of the company, “[t]he market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.” Outlook was such a product. Coupled with Exchange the market simply needed the combination to exist and to be provided by Microsoft. No matter what, the market was going to make the offering successful. It simply didn’t matter what Microsoft did or did not do, Exchange and Outlook were going to be successful. Once customers saw enterprise-grade email running on Windows Server with a single integrated mail and calendaring solution, all from Microsoft, everything else was set aside: bugs, bad user-interface, poor performance, and missing features. The combination clobbered IBM Lotus Notes. The rest is history.

We (or I) could not overcome the internal forces driving Outlook’s strategy in order to give the team space to focus on building the product it needed to be. It was weird to achieve so much success with such a challenging product. That really throws one off balance. Product people, so to speak, like to think that being a great product is what matters in the market. This belief drove so much of the dialog internally and across teams it is hard to think of any other factors that were ever discussed—the battles were over what makes for a great product. We battled features, architecture, performance, competition, and more. We never really debated the other aspects of the 4 P’s of the marketing mix beyond product: price, place, and promotion. Outlook was the right price, available through the right channel, meeting an articulated need exactly the right way. Oh, and Outlook email and calendaring kind-of-sort-of worked.

Still as a product development organization and leader, I really wanted to make Outlook work. We really wanted a release of Outlook we could be proud of in a product sense. It was a mission.

Standing in the way, more strategy.

The stars were aligning to allow us to focus—Exchange 2000 shipped and was stable, and Windows simply moved on from Outlook Express to aim for a grander and more unified Longhorn plan, the successor to Windows XP in the early stages as of this time. Yet, we found ourselves in the middle of a Hailstorm.

Hailstorm was the code name for a set of services announced shortly after Forum 2000 that built on the announced .NET strategy. Hailstorm would provide email, messaging, notifications, storage, and more, aiming to be the foundation for a broad set of consumer internet services.

That hardly stopped the corporate strategy motions. No sooner had Office XP shipped than the Hailstorm juggernaut took aim at Outlook. Once again, the classic Microsoft platform play entered the picture—a platform needed apps, and apps needed to demonstrate the value of the platform as the first and best adopters. Plus there was that other part of the strategy play, which was that the platform wasn’t even close to complete. Pushing apps to support a new platform sooner accelerated its completion. Such a dynamic worked once, with Excel for Windows 2.0, but Windows was under development for several years before Excel really began to drive the platform with feedback. Plus, Excel had already made GUI work on Macintosh. This approach did not work with OS/2, though maybe IBM shouldered some of that blame. It could be said that Outlook contributed to Exchange success, but that was not a feeling shared across teams who did not see Exchange success as a client as much as success of a server (I disagree). Hailstorm managed to get a mandate for Outlook support, old-school Windows-Excel style.

Outlook was going to get beaten with the strategy stick once again. There was, however, one problem.

The Hailstorm platform was marginally more than memos and specifications, and few understood how it would diverge from Exchange (or Hotmail)—in other words Hailstorm implied supporting a new mail protocol for a client that only understood Exchange and was still not very good at internet standards. There remained an old-school belief that the world would accept a new proprietary mail protocol for internet scale email. Hailstorm was going to build on Hotmail infrastructure, but somehow introduce a new scale platform. Underlying this was the assumption that Outlook was architected to accept plugins supporting any email protocol so long as some small amount of protocol-specific code was written. This classic Microsoft miscalculation on the utility and viability of such architectures caused many cross-group skirmishes and much finger-pointing.

What many never really understood about Microsoft’s email strategy and execution was that Outlook and Exchange were tightly coupled, just as Lotus Notes and later Gmail were for their respective clients and servers. They are essentially one product built by two teams. Even though Outlook could sort of support other mail servers, such as Yahoo or Hotmail, using those was never as good as when using Exchange—many features in Outlook required Exchange, with users mostly shouldering the burden of figuring out which features worked or not. Importantly, vast numbers of features were not expressed in the industry standard email protocols that existed and exist today. Hailstorm tried to build a mail server without a client. Supporting Hailstorm amounted to rewriting Outlook to support whatever it was that Hailstorm decided to implement as email, calendaring, contacts, and more.

What became clear was that the three-year Enterprise Agreement train that the Office11 schedule demanded would not be enough time for Hailstorm to deliver a working, solid, and scalable platform for Outlook. Hailstorm needed more time. Beyond Outlook even, Hailstorm proved to be too much, too soon for the many partners it needed.

The world of consumer companies was starting to warm up to advertising on the internet and saw the internet and software broadly as an extension of customer awareness and acquisition. The digital transformation that came to characterize most industries a decade or more later was far beyond what most companies were considering. Hailstorm concepts such as digital payments, customer identity, and even customer support happening through an array of software tools seemed wildly out of step, and, more importantly, concerning, as most companies were not looking to trust 2000s era Microsoft with those interactions.

In fact, many companies and organizations were so concerned, the thought of Hailstorm generated complaints to regulators resulting in a series of Congressional hearings. While many theories about regulations gumming up Microsoft existed (I disagree that was the case), in practice Hailstorm was an example of the specter of regulatory oversight slowing down or even outright killing product development. Whether Hailstorm would have been a success or not is easily debated. Certainly, all the capabilities described continue to exist.

The primary failure or resistance, however, came from customers and their concerns about owning data and customer relationships. These same potential industry partners eventually found themselves in the web of Facebook, Amazon, Google, and the likes of PayPal.

It was a grand vision that proved to be exactly right—and about 15 years too early and from exactly the wrong company.

By the time the fate of Hailstorm was sealed, we were only through the early stages of Office11. This gave the Outlook team time to regroup and renew the focus on making Outlook work. The team was already deep into the designs and features but cutting support for Hailstorm was a gift of development schedule hours to the two main innovations in Outlook11: rearchitecting the basics of mail delivery and reshaping the user experience.

Like many technologies in Office, from working on long documents in Word to recalculating large Excel spreadsheets instantly, delivering and storing mail was not the most electrifying feature in the product, but getting it right was something that Microsoft accomplished uniquely well. Before the rise of cloud-based email, mail delivery systems meant downloading email to a PC where it could be read and filed away—mail was stored locally on a PC and everyone was responsible for backing up their own email. It is not difficult to see how problematic that might be. Such effort was required primarily because storing and backing up mail on a corporate server was expensive (very expensive and time consuming) especially for a corporation with tens of thousands of employees. As an indication for how routine it was for IT to offload critical business functions to end-users, few considered the distributed costs and risks associated with every end-user at a big corporation acting like their own IT department. During the early days of corporate email, another limitation was connectivity (Wi-Fi was not yet ubiquitous)—employees were often disconnected from the network, especially information workers with laptops. Routine business travel was a constant hunt for hotels with wired networking in rooms or guest network cables at customer and partner offices. Of course airports and airplanes were disconnected experiences. Customers were offline and disconnected quite frequently.

The previous two Office releases attempted to address offline using the idea of a new storage technology, the Local Store, or LIS. Outlook supported a clunky way of working offline (rooted in old-school dial-up support), which the team improved marginally, but it needed much more work to be broadly usable by road warriors. Working online was how Outlook was built. By online, I mean Outlook worked best when it was connected to an uninterrupted, reliable, high-speed network.

As mobile work increased, working offline became much more the norm. This reality is difficult to imagine today, but two decades ago connectivity was the main topic of conversation almost everywhere there was a laptop. Connectivity, or lack thereof, was a major point of contention at sales Mid-Year Reviews (MYR) where country managers genuinely believed Redmond’s product designers had no idea how poor connectivity was in other markets. They were mostly right, and even when we visited would had no problems paying $35 per day for wired connectivity in a business hotel. It would be ten years before Starbucks would offer free Wi-Fi.

Offline was the key to making Outlook vastly more reliable and responsive. Everything that a user experienced in Outlook would operate on data that was already downloaded from a server, which was not how it previously worked. If there was no network connection Outlook was still snappy and responsive and every feature just worked. When a network became available, Outlook seamlessly and silently connected, receiving any new mail, sending all the mail that was drafted while disconnected, and filing away emails in the right folders. A key detail was that an individual’s PC was no longer the only storage for email but was a copy of all the email stored on the server. If a laptop was lost or a person wanted to use two computers, mail remained up-to-date and exactly the same. Outlook was a cache or copy of Exchange, which is why we called this cached mode. Through today’s perspective, this is exactly how the Mail application on an iPhone works when connected to Gmail.

In Outlook 97 through 2002, online mode, when it worked (which was not always), worked incredibly fast, and instantaneously. When the server received new mail, Outlook instantly showed the new mail on a PC. That mail was fetched from the server then displayed, which, if the network was perfect, was snappy. Even a small network hiccup (as the CEO of Boeing experienced on a business jet) and Outlook would hang, and almost never recover gracefully. Email was novel and speed of delivery was a feature, so even then customers remembered how fast it all seemed during demonstrations. The important detail was that the mail still existed in storage only on the mail server. The PC was a rendering of the server. That’s why mail delivery seemed so fast—the mail itself did not travel over the internet, just the visible portion of the screen.

With cached mode, Outlook11 changed how email felt. Suddenly, when new mail arrived on the server, the PC silently fetched it, waiting for a good network connection. It was fast, and not always instant, but predictably mail arrived when it could. When it did, the entire mail message, including attachments, was there. Mail with larger attachments took longer to appear. To big customers impressed by the speed of previous Outlook, Outlook11 felt slow and sluggish. With the rise of Wi-Fi on laptops, Outlook could sense when connectivity was available and, without crashing or hanging, continue to work seamlessly.

We were caught in the middle of crazy conversations with customers who could not get past it feeling slower, even though it was not, and it was more reliable. BillG even complained to me several times about how slow Outlook seemed, wondering if we would fix it as product development progressed. Again, we faced how changing small factors in a running system led customers to believe the changes were bigger and worse. Word introduced background printing and saving, and sure enough the absence of a progress indicator scrolling across the screen led people to believe Word slowed down as well. Cached mode, background save and print, and many more changes that improved Office in an absolute sense convinced customers it was slower, more difficult to use, or different and thus worse. At least that was the case initially.

When I was working on the first release of Visual C++, we were deeply concerned about performance when creating Windows programs, new for most developers, especially compared to the speedy Borland Turbo C++. I added a feature to rapidly display a count of lines of code as they were processed or compiled. Much to my chagrin, my code to draw that ticker technically slowed down the process. In usability tests, however, developers always thought being able to see the line count whiz by was perceived as faster. So, we left the line count in, even though overall processing time was slower.

Perception matters. The performance of an interface can depend on perception of the design as much as stopwatch time, though it isn’t always obvious which matters more.

Outlook 2003 was so critical to Enterprise customers and so complex to make work reliably and correctly, that along with volumes of detailed documentation for system administrators we released a 27 page “Outlook 2003 Performance Guide” detailing all the improvements and capabilities for performance, security, reliability.

Office was no longer in the realm of tech enthusiasts anxious for every change. It became business infrastructure and like the floorplan of a factory or cost centers in accounting changing infrastructure was not done on a whim.

The middle-age of the PC was a period during which each change, obvious or not, was viewed with skepticism. It used to be that Office was difficult to upgrade because of the cost of upgrading disk space and memory, but such expense was viewed with a bit of excitement or even pride of accomplishment. Then upgrading Office became difficult because customers did not want it to change at all. Change was different and different was assumed to be bad, especially for Office, which was not the cool place IT was willing to invest time and effort. The complexities embraced on the server and in the datacenter were driving a movement to maintain status quo on the desktop. Change was actively discouraged when it came to the desktop and Office.

Still the user experience of Outlook remained horrible. It was Byzantine and bloated and had the reviews to prove it. Even today, searching for “Byzantine Microsoft Outlook” yields almost one million hits. Outlook11 aimed to recraft Outlook based on what we had learned over four releases and four years since Outlook 97. We were going to take the time to make it right so it could properly share the stage with Word, Excel, and PowerPoint. Each app in Office deserved to have a release where it stood out and was recognized for being great.

Jensen Harris (JensenH) was asked to lead program management for the first broad, and much-needed, reshaping of the Outlook user experience. Hardly the typical computer science hire, Jensen joined Outlook from college where he majored in music. Previously, Jensen attended Interlochen, the prestigious performing arts school, with fellow classmate Jewel. When not composing for all the instruments in a piece or performing, Jensen was programming. Jensen was among the best of a new generation of program managers on the team and he seemed to know as much about how Outlook was coded as even the most senior developers. These skills were put to the test in sweeping changes to Outlook11—a process that, if successful, could prepare Jensen and the Office team for even bigger changes in the future.

While we made many small or incremental changes in user-interface in each release of Office, Outlook11 would be the biggest changes to any one product to date. We would also make these changes in the context of the change-resistant enterprise customer base, especially the email administrators in IT that saw Outlook as a necessary evil supporting their beloved Exchange servers.

To say the changes were sweeping and high-risk only makes sense in the context of the time. First, many small features of Outlook that piled on over the previous years were rationalized, sanitized, streamlined, and in general made better and more accessible. Second, and more importantly, they came at a time when email was the most critical and mainstream tool being added to the workplace. Using email and Outlook often meant taking a training course, buying a book, or simply struggling to master a few scenarios and little else. Email was still in an expansion stage, leaving ample opportunity to make it better for new users not just change the user experience for existing users.

That context is important because so many of the paradigms we think of in email today were pioneered or refined in Outlook11: message flags, preview pane, switching between calendars, contacts, mail, message thread view, junk mail filtering, integration with instant messaging, and much more.

The most acute pain point in using email, any email not just Outlook, was unsolicited mail, junk mail, or SPAM. The rapid rise of email brought with it an exponential rise in the morning ritual of deleting unwanted mail offering everything from get rich quick schemes to fast college degrees, and even offensive sexually oriented offers. Everyone felt invaded by the onslaught. Unfortunately for Microsoft, the rise of Hotmail with hundreds of millions of accounts was both a source of junk mail and the target of junk mail senders. The junk mail problem on Hotmail was so bad that @hotmail.com addresses became synonymous with spam. It wasn’t just an inconvenience, but email was losing its utility for businesses to communicate with customers as primitive junk mail technology too aggressively filtered out legitimate mail.

In one of BillG’s most successful (and perhaps last) great cross-company technology initiatives, a working group from Microsoft Research, Exchange Server, and Outlook convened over many months with Bill insisting we collectively make improvements in junk mail filtering.

The work from Microsoft Research was one of the early applications of the same technology used in the Office Assistant, Bayesian probability, advancing beyond typical keyword filtering that falsely flagged messages. Junk mail senders adopted their language rapidly to get around filters, substituting alternate spellings for words such as S3X instead of SEX or S1NGLE instead of SINGLE. Exchange server pioneered some of the first cross-industry efforts at verifying legitimate senders. Outlook took advantage of MSR technology used in Hotmail to apply it to the desktop application so it could work for any email service customers used. The Outlook features were so well received that almost every review mentioned them, though they also mentioned Hotmail as the biggest junk mail headache.

So successful was the feature in the previously released Outlook Express that I found myself along with several lawyers in a San Jose courtroom defending the right of Outlook to even have junk mail filtering. A popular electronic greeting card company (yes, web sites that created a JPEG birthday card were a big thing for a short time) sued Microsoft for falsely flagging some of their free greeting cards as junk mail. I spent several weeks creating new mail accounts and collecting the junk mail that would routinely arrive even before using the account for legitimate email to show the judge as we entered arbitration. The lawyers made a great case for the right to protect consumers, but in the post-DOJ era the David v. Goliath environment was too difficult. We settled the case for an astonishing amount of money. The good news is that over time it paved the way for the industry to legitimately offer junk mail protection, if for no other reason than everyone with email recognized the junk mail problem.

In applications, the way to signify a major update is to change the user interface substantially. Doing so signals to the world how big the change is. BradWe, our product design leader, referred to this as the ten-foot test. Looking across at a PC screen ten feet away, could a typical customer see the difference in the product. This is surprisingly difficult as most people see typical screens as an array of meaningless graphics. On the other hand, when it comes to using a product up close even the smallest changes elicit massive feedback. The rise of Outlook in a few short years created a good deal of muscle memory, even though the product was awkward and complex. Most customers were not just learning Outlook but learning email, to many Outlook was email. Changing Outlook was changing email, and email had rapidly risen to be a core part of work. No one likes their daily workflow changed for no good reason. These conflicting goals set the bar high for JensenH and team to deliver on a vastly improved, and iconic user experience for Outlook.

The team answered this challenge with an entirely new layout for the main Outlook window, one that would pass the ten-foot test. The screen was divided vertically into three columns: folders, mail messages, and a single message open to read. It was a clean and logical design that was . . . broadly panned during beta testing. The visceral reaction to seeing a narrow column of the inbox subject lines and that the view was showing each message with two rows led beta testers to think less email was shown on the screen, and less email meant less productivity. Similarly, the relatively narrow reading view of the message led to a conclusion that less text of a message was shown on the screen. These observations were hotly debated on the newsgroups and the subject of many outcries from testers.

Yet, these observations were not true, and easily demonstrated. Jensen and team were hyper-analytical in the design and measured everything about the interface—in particular, the design showed a much higher level of information density on the screen, while apparently making people feel like less was on the screen, which would make it easier to read and less tiring. Brilliant. Over a few weeks the outcries were settled with volumes of screenshots and posts to the newsgroups, leaving a design in place that is routinely used by all email clients today. This was another example of visceral perception of user experience versus actual experience.

Outlook users tended to be either pilers or filers when it came to managing email. Pilers, like the BillG I knew, let their inbox grow, seemingly without bound. Inbox was where mail was read and also stored. When a piler wanted to find a message, they used Outlook search, which was slow and deeply unsatisfying, or more likely they sorted thousands of messages by sender or date or subject, which was fast. Filers created elaborate hierarchies of storage folders and messages. Advanced filers created email rules, moving messages to folders even before they read them. One reporter I knew maintained a folder for every company, and a folder within that for each contact at that company. He worked with all the folders visible and the whole hierarchy expanded, watching for unread messages.

There’s a challenge when customer knowledge of the past makes improving for the new, faster-growing base of customers super difficult. The customers we heard from in early testing were those with knowledge and time to engage. They raised issues and engaged in debates that others happily let product design work out for them.

We came to learn that many of the tech elites were avid filers, making use of email rules. When a customer goes through the effort to create a rule, mail messages are automatically placed in a desired folder as they arrive in the inbox based on criteria such as the sender’s name or company name, or perhaps keywords in the subject line. The general concept of advanced tech thinkers embracing hierarchy was consistent with how people made use of folders of files on their PC. Typical users often had desktops filled with files including what they were actively working on, whereas techie users tended to have elaborate folder hierarchies and store documents in the right place from the start.

Studying how customers used Outlook, rather than listening to how they thought they used Outlook, revealed a spectrum for how the onslaught of email was being handled. Customers tended to self-report how they wished to be perceived rather than how they used a product, something we learned over the years with the instrumented versions. As an example, customers routinely self-reported sending far more mail than they actually sent or would rarely get the number of messages in the inbox approximately correct. BillG, the piler, used to wax poetically about his love of filers as though he was one primarily due to his fondness for hierarchical lists, but also to make a point about the future of storage that would support hierarchy. He also exaggerated the amount of mail he sent and received.

Business books are filled with stories and strategies about learning from customers, getting feedback, and doing what customers want. In technology products, and in Office in particular, in the more than a decade I worked on the product, much of that feedback would have frozen our product where it was and prevented us from moving forward. Staying true to learning the reality of what customers experience was such a key lesson reinforced with Outlook11. The lesson was one for the ages and one that impacts every technology product, including, as I would learn, Windows.

Showing Outlook11 to the press and reviewers was not just a demo, but a story. We incorporated the data about how customers used the product in reality and showed the analytics behind the product. It sounds obvious, but it just wasn’t something done in the industry because prior to the internet no one really knew. We had surveys and focus groups, and the early data about quality, but with Outlook and Exchange we had real data about real people doing real work. This story-telling approach dramatically changed not only how we designed and communicated product changes, but our willingness to take risk to make bigger changes that met customer needs.

Outlook 2003 had its own “Reviewer’s Guide” that was provided to the press and Enterprise customers. It was 35 pages!

As the success of Office continued, we were fast approaching the point where most everyone that wanted Office owned it, legally or pirated. PC sales in 2002 (post dot-com bubble) were nearly 130 million units, growing at an anemic rate of 3 percent or less. There was a fear that we had peaked and that conservatism in making changes should have ruled how we thought of the product. Some thought we should have been focused on listening to customers and not rocking the boat.

Except we were listening to customers.

There’s a famous saying falsely attributed to Henry Ford suggesting that when potential customers of the Model T car were asked what they wanted, they said a faster horse, not a car. No customers wanted a graphical interface with a mouse, or an integrated suite of productivity tools, or even for those tools to evolve with the changing nature of information and the internet.

Finding a balance between listening to customers, while also moving forward with technology, is the most difficult challenge any successful technology company faces. Microsoft was no exception.

On to 075. Scaling and Transitions

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