043. DIM Outlook

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)

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