070. Office.NOT

Welcome to the only project I worked on that had the plans upended at the last minute after one executive meeting. This is a journey that starts back at the 1999 Company Meeting and the unveiling of “Software As A Service” bet the company strategy. With many excerpts and artifacts, we will go through planning Office.NET where you’ll really get to experience the product planning process in Office. Followed by a last minute change putting all that work at risk.

Back to 069. Mega-Scale, Mega-Complexity

In the fall of 1999 Microsoft held its annual Company Meeting at the old Kingdome (a stage was set up over second base). While most of the world was fixated on the rise of internet sites or more likely the looming Y2K crisis, both SteveB and BillG used their time to begin a transformation of Microsoft—the transformation to a software services company (this would later be called cloud computing). Few even in the industry knew what this meant. Pioneer Salesforce.com was just months old and the original cloud infrastructure company Loudcloud started by web browser pioneer Marc Andreessen and former Netscape executive Ben Horowitz was incorporated just a week before the Company Meeting. This was very early, but it was also very big. Even though Microsoft was at the peak of success and the most valuable company in the world, the company was going to be reinvented. It was powerful.

BillG spoke first. His opening was dramatic—a reinvention of the core mission statement for Microsoft—the title slide was “Changing the World of Software”. From the meeting transcript:

The vision statement that many of you have heard, year after year after year, we actually decided to change. That statement, a PC on every desk and in every home, running Microsoft software, is still true. It’s a great vision. It really drove the company for the twenty-four years that we’ve been in business. But in some ways it’s outdated. Not outdated because it’s wrong. But outdated because it’s not revolutionary. When you hear that statement today, you say yeah, of course, what else is new. PC’s are in sixty percent of U.S. homes already. The prices are coming down to a point where increased penetration is very, very easy to predict.

But Microsoft is a change agent. We’re not just about taking the software we’ve done and making it a little bit better. We’re about changing the platform. Taking the kind of risks we took when we bet the company on graphical interface or bet on a Windows NT. We’re embarking now as big a bet, or I would say, a bigger bet than any of those. It’s captured in this new vision statement. Empower people through great Microsoft, internally we say Microsoft, externally we just leave that as implicit thought, great Microsoft software, any time, any place and on any device.

Now when some people in the company heard that they thought is that all really that much different? Is it something completely new? And just in the last month, Steve and I with a lot of help, from other people, have come up with a way of taking this vision and explaining what it means to our software in a way that is quite revolutionary. And that is by saying that from 1975 to 1998 the whole vision centered around the PC. It said the PC is getting more powerful, there is more and more things people are doing with it, just get the applications on to that PC and we’ll continue to lead.

Well, now we’re saying that although the PC will continue to be important that it’s actually the capabilities that are delivered through the internet, the services across the Internet that people will be thinking about.. They won’t be thinking about managing their files on an individual machine. They’ll want all their information stored in the network in such ways that any device that they pick up, a PC, a phone, a TV, a small screen device, they have access to the information they care about. That takes storage of file system that was purely PC-centric and makes it much more internet-centric.

This was classic Bill. There was a bold statement. An assumption that the company was willing to take on huge risk. Embracing the success while saying we could do much better. Then pivoting to a very specific technical scenario, and no surprise it was data storage. He did this exact pivot when celebrating the Office XP launch with the team—great job, now about unified storage. There were demonstrations of web scalability on Windows, the new collaboration features in Exchange (including the Web Store discussed in previous sections). In something unusual for Bill, he ended his keynote by going through the newly created Microsoft Values, talking to Innovation, The Customer, Partners, Integrity, Diversity, Community, Entrepreneurial Culture, and People. A memo was authored describing these values, distributed to the company, and leaked to the local press (who often hung outside the Kingdome listening to the meeting anyway).

These ideas did not spring up for the meeting. A couple of years earlier Bill wrote a memo where the concept of a WinTone was put forth—something akin to a dial tone where your computer was always connected to a Microsoft server (actually called a MegaServer in the memo) where files would be stored and where PC updates could be distributed. Technically this sounded a good deal like a typical Unix workstation and was similar to ideas being espoused by Sun and NeXT.  By the time the Company meeting rolled around, these ideas had been much discussed and the Orwellian nature of them toned down. It is interesting to note that these perceptions would change dramatically, and the same ideas introduced today are not only typical, but expected.

SteveB came next. Going from Bill’s almost monotone delivery to Steve’s energy filled enthusiasm was always fun. Steve’s keynote was titled “The Power to Be Strong: The Wisdom To Be Wise”. Where Bill was describing what we should aspire to, Steve was providing the emotional call to action, the aircover to go and act on what Bill said, while also taking us through the detailed business reasoning. Steve came bounding on stage to some song that meant a lot to him that he carefully picked to get him in the perfect mood. Where Bill was measured and deliberate, diving deeply into technology, Steve pounded on “services”. He said the word almost 200 times in the keynote. The key slide was “Reinventing Microsoft: Software As A Service”. Like Bill he started off describing our success, though Steve was even more hardcore from a business perspective:

As Bill said, the PC is not new to the revolution anymore.  People wanted to know in some senses, what is it?  The PC has been it for us for twenty-five years, and we have exploited it, and we have built it, and we have designed it and we did it better than any company in the history of the world! One vision, one technology model, one revenue model, one partner model, and we just went, and we went, and we went, and we went after it!  And you know what?  Here is the good news, it’s still got some mileage left in it!  And I like that a lot.  But it doesn’t have as much mileage to come, perhaps as the mileage it has brought to us in the past.  And so when we talked about a new vision, people kept asking --but what is the new it?--  The PC has been it, and the PC will remain it, but what’s the new it?

I don’t really think people expected that at all. Here we were on top of the world and Steve was telling everyone the party was over. This was Steve and he was going to take us on the emotional journey and was working towards showing us all the opportunity that was ahead. Steve pitched the company on the why of both services and PCs (an echo to “software and services” that would follow). He explained that Applications Service Providers (ASPs) were the new developers to focus on. Then using the model, he was most comfortable with, he went through each Microsoft customer segment—enterprise, small business, consumer—and described the value proposition and how we would approach the opportunity. Who are the competitors and how would Microsoft compete? Steve had a list and made sure even in the face of regulation challenges, it was OK to compete vigorously. He even had a pro-forma P&L describing the way revenue would transition to services. Like Bill, Steve also concluded emphasizing the new company values.

It was a remarkable presentation and strategy. The presentation and details were the first draft what would become the months of meetings for the Next Generation Windows Services (NGWS) task force and presaged the Forum 2000 strategy day the following June. The 2000 wave of products (Windows, Office, Exchange, SharePoint, and many more) were announced at COMDEX just two months after the company meeting to over 340,000 people and created the product foundation for the company that would carry us forward as Steve described. These new products—the foundation of Microsoft for a decade—were positioned as old news before they even shipped. I loved it.

Unlike the internet strategy, especially the Internet Tidal Wave memo, this services strategy was ahead of the market. Microsoft was leading and no big company was heading there yet. It was, at best, a Silicon Valley startup strategy. When it came to services, Microsoft was incredibly early. Were we too early?

Windows and Office both created the XP products over the next 18-24 months while theoretically the new services infrastructure was built up. That wasn’t quite the plan, as really both teams were polishing/finishing the 2000 wave, but it worked out that way. There would be an absolute ton of meetings about Services over the next two years. The big project being worked on was Hailstorm, also known as .NET MyServices. The services topic and getting more done and sooner was top of mind.

In Office we had already spent a couple of years on SharePoint and FrontPage and were more than convinced that services were the future for us—so many of the scenarios described by Bill and Steve were easily enabled by using a browser, HTML, and a web server. It was abundantly clear that any remnants of the old way of working were in the rear-view mirror (file servers, “net use” to share files, directly connecting to databases from Win32 apps, having all your files on one PC, even obscure features like roaming settings and customizations were better suited to a web way of thinking).

We had many difficult balancing acts in front of us such as how much could work in a browser (very little in 2001) or who would buy services from us (we had no idea) or how much would a service cost (would it cost more or less than a box of Office). We had been talking for the whole of the XP product cycle about a mythical product “FrontPage.NET” (every next version product or code name had a .NET suffix by summer 2000) which would be an app-less app. Simply go to a web site and sign in and start creating a new web site. We’d seen self-service collaboration sites take off with SharePoint Team Services. I compiled a list of a dozen or more competitors who were making browser-based products for sharing and collaboration. No one was really doing anything significant for document creation, yet. Outlook was achieving a huge level of interest in the browser version being done by the Exchange team (so much we’d move that team to Office to better align Outlook in the browser and Outlook on the desktop). We were ready for services.

In the spring of 2001 after Office XP released with the rise of the new .NET developer platform inside of Microsoft, Office shifted its gears to deliver what BillG referred to in an earlier memo, Office as a Service. Customers loved the idea of infinite clip art, endless templates, ever-expanding online help, even sending Microsoft bug reports. We had so many more ideas.

As Steve and Bill set the stage to transform the company, it was my turn to transform the Office team. We had almost 2000 people on the Office team. That’s a huge management challenge, even with the air cover from the company meeting two years earlier. There’s only so much a few hours in a stadium can do. My job was where the strategy and words needed to start turning into code and product.

To get there as a team, we needed to scale our planning process. Our mantra for planning had become “the best of top-down, bottom-up, and middle-out”, but in truth we were far more tilted in the direction of middle-out, meaning gaining alignment across the various app and shared teams, and bottom-up where everyone contributed to feature ideation and prioritization. The top-down planning we did was around resource allocation and the big shifts to the suite and enterprise. The transition we’re talking about here needed a much more prescriptive top-down effort. Somehow, I needed to find a way to do so without being rejected out of hand or worse being called “too much like Windows”. Finding an enhanced way of planning that allowed for more senior management coordination and, yes, control, was hugely stressful.

I settled on a process of memos over a course of months that would lead to increasingly detailed priorities and ultimately an organization (aka a re-org) to execute on the plan. Along the way there would be countless 1:1s, skip-level 1:1s, group meeting presentations and Q&A, email threads, and hallway chats. Drafts were shared. Changes were made. The idea was that even the top-down was a product of bottom-up and middle-out. I admit that is an idealized view and some would disagree, but the goal and the work put in was intended to do that. At the very least we were running a version 1.0 process.

The process would take a bit more than 12 months from the first memo to the team meeting rolling out the vision (the plan), starting well before the current release even shipped. That seems like an insufferably long time in today’s environment. Aside from the obvious notion of “boxed” software versus an ever-changing service, there was a crucial difference with today. Office was a single product, with a single strategy, which would all be made available on the same day, spanning the work of some 2000 people each of whom would deliver their contribution on that day, complete and working. There are many enormous, far bigger, projects today, but they are rarely delivered in this manner. Even today Office itself no longer delivers products this way. Today, a single new feature in Office might roll out over the course of a year even in one module, and the same feature might come later in another part of Office (for example, dark mode). It isn’t just that the feature is released before it is done, but even after it is done there is a long tail of delivery.

In April 2000, 11 months before Office XP shipped, I sent out the first memo in the series, Next Generation Office, or NGO. Essentially on the heels of the Company Meeting and just before Forum 2000, I wanted to offer the Office analog to NGWS. The fact that this was just after the dot com bubble was important context. While the stock dropped precipitously, it was nothing compared to most of the tech world. The introduction set the stage for a big change:

Office is at a crossroads—we are on the brink of shocking changes in the technology priorities of our customers and are facing a substantial disconnect between our product and what customers want. For two releases customers have been telling us that they don’t have the need for upgrades and can’t imagine what else is left to do with Office. At the same time we have continued to innovate roughly along the same path started back in 1992 with Office 4.x—improving the basic document process. As we close upon the development of Office10, the signs are upon us that we are truly at the end of one era and at the start of another, and if we don’t act deliberately and precisely we run the very real risk of missing the transition. We have accomplished amazing things with Office, especially Office10. Over the years we have developed a product that is in daily use by perhaps 200 million people and each one of those customers gets tremendous value from our work.

It went on to describe what I called “The Big Bet” which was about developing an “internet user experience” for Office:

The Next Generation of Office is not just an incremental addition to our “client-side” code, nor is it about developing stand alone server applications, or isolated “free services” [This is a vague but pointed reference to the dot-com crash and all the companies doing free software and planning on making it up in volume]. The Next Generation of Office is about creating a compelling Internet User Experience built on top of the Next Generation Windows Services (NGWS, an early document from SteveB). NGO is a product that is the seamless integration of our client, our server software, and our services. When we speak of “Office as a service” we mean that Office is the combination of a Windows application (like the world knows and loves) plus a wide variety of hosted services (extrapolate from Office Update) plus a range of significant server software (such as OWS or mail boxes). Although we might also include some element of support or custom engineering, “consulting”, or other people-based services, our bet does not explicitly require that—we are a software company through and through. We will fail if we do not deliver on that powerful combination.

The memo paints a complete picture of the many challenges Office 2000 faced in the market. I referred to this as the innovation disconnect. The perceived cost to deploying, training, absorbing new features continued to rise, while the perceived value of those features declined. In other words, we were digging a deeper and deeper hole for ourselves by simply doing what we were doing by adding features. The bottom-line on this observation was a dramatic number I placed on what were termed traditional innovation, or features in the desktop apps, which was only 20% would go to “guarding the core enterprise agreement”. Such a statement proved to be enormously controversial with our team and as the marketing team (at the time they reported to me!) As we’ll see the controversy did not end there.

As I came to learn, in a big company (and especially Microsoft) when people read memos from executives there’s an ever-present expectation of a reorg. In Office our re-orgs had become routine and predictable. After a release we’d realign resources, shuffle the shared feature teams in Office proper, and make sure everyone had a chance to do something new or sit tight. It wasn’t stress-free, but it wasn’t a scary free for all. In reading NGO, many suspected a much bigger change. There was not. Instead, what we really needed was to create a whole new type of job. Our historic reliance of the magical trio of dev, test, and pm (software design engineering, software design in test, and program management) could not account for the important role of operations (the contemporary title of devops was a decade away). Part of writing this memo was to have guest speakers come to group manager meetings and to share industry practices from some of the hot startups. For example, Tim Brady, the first non-founding employee at Yahoo spoke about prioritization, keeping services running, and the like (I met him at a Harvard Business School event when I was there on sabbatical teaching). In many ways the biggest change in NGO would be creating not only an operations team, but an operations mindset.

The real purpose of NGO was not to provide answers to what the product was, but to tee up the questions or to frame how the release should look. In the next iteration we’d call the memo at this stage the framing memo, because it framed the release. It wasn’t nearly as prescriptive as BillG would have written because it was more of a management tool than a bulleted list of features that he tended to favor. In that sense, sending these memos up the chain was often frustrating for the recipients and a bunch of work for me. I had to learn how to use the memo to gather their feedback on the framing, not features.

Over the next months there would be any number of offsites and discussions about what should come next. Teams were using many new startup products out on the market, reading a great deal, and learning new technologies (like .NET). This enabled the next turn of the crank and many more specifics. Rather than putting forth a framing, the next memo said at a high level what we would build. It was still not features, but themes. I called it Creating Office.NET: Next Steps in Creating a Vision for Productivity. It was clear that the vision, the actual plan would follow, and this was not the plan. The goal, however, was to be something of a rough draft of the vision. The team would begin to fill in the details and thus own the actual plan. Again, this is solving for the lack of accountability that comes from simply telling people what to do. Plus, I had no idea what every feature should or could be.

This memo is about creating the next generation of Office.  Not a vision statement, this memo outlines the business situation and the clear direction we are taking the Office product, and the bets we are making (a vision statement will follow soon).  This memo is also about creating a new product—one that takes the enormous success of Office and melds it with new functionality and new technologies to create an exciting new product.  We will call this product Office.NET.  Office.NET is the essential set of tools and services that empower individuals to get their work done with a personal computer.

Without saying what the product did, the memo defined what success looked like. Again, this was either empowering or frustrating depending on the mindset of the reader. It is easy to lose sight of the work going on to change mindsets, not just accounting for what features to do. Office had almost no developers working on .NET, HTML, XML, and other new technologies. The memo continued:

• Customers move beyond the view that Office is “just” a word processor, spreadsheet, email client, graphics, web authoring, and database. Office.NET adds whole new services and applications to the toolset that we build and sell as Office.  Think of the service and services elements of Office.NET as “puzzle pieces.” When we release Office.NET people will use our product to get work done in new ways that they might not have thought of and certainly did not think of using Office.  Office.NET is not “Office 11.”• Customers not only use our new suite of hosted services but customers come to rely on Office.NET services as a critical element of getting their work done.  Office.NET services are not about gimmicks or “dumb PC/internet tricks” but about being simple, elegant, and useful additions to getting work done.  For customers, Office.NET is about saving hours, not mere seconds.• The glue that holds Office.NET together is integration and integration is what makes the value of our product greater than the sum of the pieces.  Customers using Office.NET see an unprecedented integration between their tasks—whether those tasks are Office.NET services, desktop productivity tasks, browser-based services, third-party services affiliated with Office.NET, or Microsoft’s own MSN services.  Integration is the key that allows a customer to solve real-life problems, such as sharing a document with a partner outside the firewall or merging a work calendar and a private calendar.  Many would say that one beauty of the internet is the elegance at which a large number of valuable tools interoperate saving time and effort—we will bring that elegance to Office.NET’s services.• Office.NET provides a new level of “customer service” by keeping the software updated, enriched, and “running” for customers.  No longer will customers feel like they are “cut off” from Microsoft after they buy the product or feel like they have to wait a year for a 30MB patch to fix things.  Of course, Office.NET doesn’t change this from the first day a customer gets the product, but we will over time build up the service relationship.  Customers no longer view buying Office as a one-time transaction, but rather customers subscribe to Office.NET because Microsoft is making a commitment to back our software and services with the highest level of support possible.• Customers who use Office.NET can do so with full faith and confidence that Office.NET provides a safe, secure, private, and reliable service. We will go to extremes to insure that customers can trust their important work to the tools and services offered by Microsoft. Everyday one hundred million people trust their work to Office, so we’re in a good position to extend this trust to a new level of support. This will not come easy, but we will make it so by making it the highest priority in everything we do.• Office.NET is good for business.  The great American philosopher, Steve Martin, once had a moment of enlightenment when he realized “it’s a profit game.”[OMG this should be “profit deal”  a mistake 20 years old.] For most of the history of Office, it has been more than good enough to maintain a clear focus on improving our engineering and building products that more often than not continued along the path of incremental improvement and that led to an amazing business. Office.NET is about building a new product and selling this product in new ways.  We are making these choices because everything we know says that they will be good for business—just as we thought building Windows applications was going to be good for business. We will run a service business with the same focus on efficiency and cost that we have had in building our packaged product business.

The text is rather self-explanatory today. It reads like common sense. At the time, each one of these points had controversies. Even the mundane such as providing software updates was broadly unacceptable to enterprise customers that wanted full control over what changed and when (and they still do). While writing the memo and talking (and talking) I could sense an increasing level of excitement. Bringing the excitement of the rise of the internet home to what we work on and how we work in Office was motivating. To put things in the era, many people were just starting to order books from Amazon and track stock quotes and news on Yahoo, though we were still 5 years from the rise of Cyber Monday.

Important to this memo was setting a bounding box around some important project attributes. This is the pure top-down aspect of the plan. This included setting time frames for the release, the number of milestones, system requirements, and more. The real deliverable (as with the operations team from the previous memo) are a set of carefully worded and coordinated “Focus Areas” which would be used by program management. These will anchor the process of feature ideation, prototypes, and scenarios. The memo outlined the following planning focus areas. These came with brief descriptions to answer the why, but were designed to ask the question how, not define the specifics of what we would do:

• Accessing My Information from Anywhere, Any Time • Creating a Personalized Office Experience• Building Effective Communities and Teams• Growing New Opportunities for Office• A Note About “Traditional” Features

The framing memo went out to the team in October 2000, about 5 months before most everyone was done with Office XP. A few weeks after that, the third memo in the series went out which was the adjustments to the organization. I like to remember this as relatively uneventful, though no org changes ever are for anyone who gets a new manager. In fact, the team had gotten so good at this re-shuffling after the release that it became somewhat of a game to go from the framing memo to the new org—clever people could guess the new shared teams or realignments that would happen from the way the focus areas were lined up and how the ideation progressed.

Program management created working teams based on these themes, and smaller groups based on specific scenarios. The features would emerge from these efforts—this is the bottom-up and middle-out planning work. PM led by HeikkiK drove this process, working across teams. If there is one magical step in all of Office, it was this particular part of our elaborate process that I came to value the most—we came to call it participatory design. It wasn’t just that features and scenarios seemed to emerge as if by magic, but the scale and alignment that came with those features. Anyone can (and did) have great lists of features they planned on doing. In Office when we published a list or specifications, we viewed them as team commitments. Heikki was coordinating a couple hundred PMs, designers, product planners, who in turn were partnering with developers to make sure that what was being talked about could get built. Everyone above mostly just watched. I’m not exaggerating. I will learn just how special this process was when I try to import it to Windows in a few years.

By May 2001 we had a full product vision—a product plan—for Office.NET. This whole time I had been sending the memos and talking with BillG and SteveB. In the middle of this process the executive VP leading Office changed from BobMu to JeffR and I walked through this process and all these memos with him. I realize now that must have been like sitting down and trying to untangle the true meaning behind the sales Mid-Year Review (MYR) process in a few meetings and by looking at 100 country and segment-specific slide decks. This oversight on my part will reveal itself shortly.

The pillars of Office.NET included:

* My Office

* Team And Corporate Productivity

* Keeping in Touch

* No-Brainer Upgrade

* Unlocking Information via XML

Phew. We were getting close.

A side note on the process described above is warranted. In talking about what we did I have always struggled to express the iterative nature of the ongoing work. Almost universally, the process is viewed through the artifacts (the memos) and that has the unintended effect of making the whole of the process seem like a traditional, and loathed, waterfall (as described in Chapter VII). When the process is illustrated in PowerPoint, I tended to use a lot of arrows to show off the constant state of iteration. The memos are not the work, they summarize the work. The work is best thought of as the communication, alignment, and learning constantly taking place.

The other concern often expressed by taking an artifact view is that there is so much planning time, or even dead time while people wait for the plans. In reality, the process came about to avoid any dead time at all. Many in PM are able to peel off while dev and test are finishing the product (in the above case a year before). From the end of Office XP until the vision is in place was only two months, and two more months until coding the project started. During even that four months, the engineering tooling is updated, the codebase is cleaned up (the removal of so-called technical debt), and because of Watson we initiated a mini-milestone devoted to addressing top issues. The waterfall versus agile debate would follow me around for many years, an irony for sure given the ability for the Office team to promise and deliver, compared to so much overpromising going on. I even created a slide that attempted to convey the iterative natures of the process and what we felt was unique. I used this slide for many years.

After a decade of offsites and memos about subscriptions and annuity, we finally worked our way to a product that could truly be offered as a subscription. Quoting from our vision, “Office.NET is a software service consisting of the best combination of software and services that provides a personal experience in creating, communicating and collaborating anywhere and anytime.”

The learning from the Office XP services emboldened us to embark on plans to host a broad set of productivity capabilities on the internet. We assumed if the MSN team could do it, then we could as well. We set out to define a new role on the team, on par with development, testing, program management, and design, called operations and led by Arthur de Haan (ArthurdH) as described months earlier in the original NGO memo. Arthur was leading the testing of enterprise cost of ownership shared team in Office and was one of Office’s most senior test leaders with many years on Excel previously and international. He brought with him a calm demeanor and the attention to detail required to grow a new job function for Office. He was eager to learn and the mental model of testing and operations were, we believed, a great match. We were all learning.

SharePoint Team Services anchored Office.NET. Every subscriber to Office received his or her own team site, much the same way IT enabled a self-service setup to create new sites on demand in our enterprise product (for a new project or something). We called this site My Office. From My Office, a subscriber received the features of SharePoint (a place to store documents, calendars, surveys, to-do lists, and more), all accessible from any web browser. In addition, subscribers could download Office (Word, Excel, and PowerPoint) and “activate” it with their subscription. Hotmail offered email. Imagine how cool it would be if files were stored in a website, available from any PC with a browser (if Office was needed it could be installed). In 2002, when we were dreaming this up, it was entirely workable but seemed like science fiction to customers.

We thought we were on top of these new challenges for the business and customers. We were naïve.

The first and marquee pillar of the vision was My Office, a home page for every Office customer available in a browser integrated all the information relevant to their Office experience (documents, mail, calendar, SharePoint lists, and more). From the start the intent was to support analogous features for enterprise customers installing and managing their own Windows Servers. Today we would say this is having both cloud and on-premises offerings. IT could set up SharePoint servers, could distribute Office via browsers, and, in addition, have much improved email with major improvements planned for Outlook. My Office was a gateway to all the communication and collaboration features in the product. The adoption of hosted services by enterprise customers was so early as to not even be in consideration yet.

The plan was great. We were days away from our all-hands vision meeting that HeikkiK owned. We created the vision document (all posted online), a one-page summary everyone received at the meeting, a mock press release, and design built elaborate full-motion demo scenarios to illustrate each of the main themes.

Throughout the process, I sent drafts of the documents and status updates to JeffR, BillG and others. I met 1:1, requested feedback, sent mail, and so on. JeffR told me that it was critical that we schedule a review meeting to again go through the vision with SteveB. This made me uncomfortable because I had already learned the difficulty of reviewing an entire product plan in one meeting. I watched Windows fail at this many times going all the way back to working for BillG as technical assistant. This was nothing like reviewing the goals of an entire subsidiary in 8 hours. It would be more like reviewing every account manager’s plan for their accounts and how it mapped to the subsidiary marketing plans and then to those goals—in 2 hours. Navigating a meeting of this scope—the work of 2000 people on a creative endeavor with a ton of unknowns that would be resolved over the next 18-24 months was, at least in my view, impossible.

While we were incredibly comfortable with our plan and the team was marching almost on autopilot, I wildly misunderstood my job description and accountability. We were planning this product since long before RTM of Office XP, with the elaborate process of memos and public milestones I discussed with JeffR 1:1. Reviewing a whole vision in one meeting at the end is an impossible task—the document was a work product of the team with nothing surprising by the time we rolled it out. Any changes this late, however, would be a surprise to the team. The empowerment that came with our participatory design process meant that management was not allowed to spring things on the team. Any big changes that the team did not participate in would be, um, poorly received.

Jeff and I took the shuttle over to SteveB’s office, the other big office next to BillG. Once the discussion got underway, I quickly realized this was not a casual check-in.

I began to run through the vision slide deck and the demos—the materials that would be used at the team meeting in just a few weeks. The first demo was My Office. There was enormous tension in the room. All I heard was, “We can’t do this product. . .it will put us out of business.” The rest of the meeting remains a cloudy memory.

I was perplexed. This was not simply a feature, but it was the core of Office.NET delivering Office as a service, as planned and described for months. It was just what both Bill and Steve described at the Company Meeting over 18 months ago. Our capabilities were not being doubted, rather it was the strategy. Was it a statement about subscriptions? Or was it a bet against SharePoint services? Did we not even want to do an internet user experience?

It was clear that a collective mind was made up, and perhaps had been long ago. The idea of offering internet-dependent Office was deemed simply too big a risk to the enterprise business. Essentially, they were concerned about what might happen if an individual started using this and then it was appealing to enterprises but not sold or supported by our enterprise sales force. It could even undermine Enterprise Agreement growth. It could cause customers to question the role of enterprise servers and cause troubles for the new and fast-growing Windows 2000 business.

I tried to craft answers explaining how I was certain that enterprises were not ready for this sort of service, and that our sales and marketing effort was aimed at small businesses and individuals—a long underserved market. The idea of internet hosting SharePoint offering downloadable Office was exactly what we had communicated earlier as a long-term goal for what was branded bCentral (an internet product for small businesses that included among other things email and communication), only adding productivity tools, Office code, and data center that could deliver that—done by the Office team as a core business bet, not a separate offering off to the side attempting to build new capabilities around Office rather than into it.

Could this moment have been avoided? I don’t think so. In hindsight, SteveB and JeffR were both focused on the enterprise sales motion—big accounts needing to close deals, enterprise thought leaders from Gartner, and most of all the field leaders. By their accounts, Office needed more “enterprise value” not what the IT industry had dubbed consumer services on the internet. And Office needed to reduce bloat. There was great love for the XML features, so more of that.

Should they have raised these points sooner? I incorrectly gauged their need to have more in person discussions. Their expectation from the field was that the process of planning and getting approval was a series of meetings. My expectations were based on writing (“writing is thinking”), and I found it ineffective to use a process that tried to agree on vast plans of thousands of people in person, with uneven engagement and unpredictable focus. My history, and that of BillG and MikeMap, was writing and communicating with strategy documents, detailed status reports, and transparency of process. But that wasn’t the field’s preferred method of engagement.

I failed to understand how much I was supposed to be managing up. This was my fault entirely.

At scale, a field organization is a much more top-down and prescriptive process than a product team. While a product team needs to scale execution (shipping quality code on time), defining what code to write is a different type of creativity than account planning or sales resource allocation. Field organizations tend to scale with HQ-centric strategy and planning teams that are there to work directly with executives—generally a clear separation between strategy and execution. Development organizations generally avoid distinct roles—those planning the strategy also execute it. As a result, there was a lot less bandwidth and interaction with management. We designed that into our organization, and it was appreciated.

In my case, it meant that I left a big gap in the way I managed the strategy up the organization, especially considering what they were used to.

As the meeting went on, I answered the concerns expressed, but I had mishandled the process. We would address bloat by not adding a bunch of features and keeping the core products the same. In other words, I unintentionally pointed out there would not be many new features in the core apps, except for enterprise capabilities (such as using the new-fangled XML technology). We intended to expand the value of Office with entirely new modules, one for pen and tablets and one for business processing and forms (a deeply enterprise scenario). The enterprise product was a superset of the Office.NET style product that would be deployed and operated by IT.

To be clear, I had said the enterprise product was the product. We were not selling a subscription, but we endeavored to beef up the free services offered with Office. I said the right words about the right priorities, and it was made clear that there was no subscription for Office that competed in the enterprise. But discussing that was not in the cards. Never had a product feature or strategy received a straight verboten before, so I left the meeting saying I was on top of it.

The vision for “Office.NET” reads well even today. In hindsight I should have seen this as a lesson in moving too soon or being early in May 2001.

Office.NET represents a major new vision for Office: integrating web services with the rich client to deliver unprecedented value to our customers. Office.NET also represents a major shift in how the product team approaches the Office product development cycle. Office.NET is not “the next version of Office.” It is an entirely new focus for Office where we will start fresh and extend our software into new and unexplored areas—software services. Office.NET will introduce a new business model, integrate with other strategic Microsoft technologies, and make much of the company-wide .NET vision real.

As of this writing, I still find the time the most puzzling few days in my career. I was too worried about the team and my constant fear of unraveling (as the Windows team was doing) to spend any effort on figuring out if there was a gap in understanding. I viewed this as an edict from above and executed as such.

I came back to the office and discussed these changes with Heikki. My state of mind was such that I did an exceptionally poor job of explaining what transpired. He was as puzzled as I was.

Since everything was essentially baked, we changed the body language of what we were doing. Where once again we started by planning the release not building the next Office, we ended up feeling incremental again. The step-function changes in the product—a subscription and internet offering—were scaled back, and our focus was back on IT and strategic enterprise value, to the exclusion of other work. Most everything we planned on doing as a hosted service we kept on doing, only as a server product using SharePoint. We would have many services as part of the core experience of the product (as previously described, such as templates, assistance materials, bug reporting, updates) and we would develop many new services along the way that would get us ready for a future.

For now, the snazzy sign up for a subscription with a credit card service was going to be the job of the bCentral team creating services exclusively on small business customers. Ironically this team, and its descendants, would spend the next 10 or more years working to scale SharePoint, Exchange, and various telephony products to work first in Microsoft hosted servers (essentially as an application service provider) first in a product called EHS, Exchange Hosted Services offering security and reliability services for a customer’s Exchange servers, and then a suite called BPOS, Business Productivity Online Service. By the end of 2008 there were about 500,000 mailboxes protected by EHS, with some big names driving a large set of those. Then by 2010 there were about 1,000 paying companies on BPOS with 2 million mailboxes (again, highly concentrated).

Therein lie the roots of today’s Office 365 offering Exchange and SharePoint services. The browser-based implementations of the Office apps would come with the next full release of Office.

Hindsight is super clear for this issue. The timeframe for enterprise customers to be ready for Office.NET was not early 2000’s. It would not even be 2010 or even 2015. Running essentially the same enterprise products but on Microsoft servers, the cloud as we call it today, would have in fact been insane in 2000. The killer application for the enterprise cloud was…simply scaling and running Exchange email for large customers. The product had become so complex and yet so mission critical that essentially only Microsoft could effectively operate it. It would take about a decade to build a product that customers would even begin to evaluate.

But in 2001 sitting in SteveB’s office, the enterprise was in no way ready for the cloud model—not even close. In fact they were uniformly against the model. That’s how early we were. Would it have put us out of business? Probably not as most customers would have ignored the offering and thought we were crazy. That’s how most felt even after 2010, and BPOS was essentially running dedicated servers for each customer. Steve was right, however, in that it would have been confusing to customers just as BPOS was in 2010.

The immediately visible change was that we re-codenamed the project Office11 instead of Office.NET. For the moment, at least the corporate branding people were relieved. We presented the vision, only finessing the idea that the design sketches needed to be representative of an enterprise aesthetic.

Office.NET as an internet experience for consumers was essentially dead.

Personally, this was a really tough few weeks in early 2001. Around the same time, Steve was pondering making changes to the Windows CE/Mobile group. He spoke to a lot of people as he always did. Among those, he spoke to me and two other good friends that were also “product leaders”. We also spoke to each other, that’s how we know we all had basically the same input on what to do. We were getting killed by the new Blackberry and our phones were nowhere near credible even though we’d been at it for almost 10 years. Unknowingly, we all said the same thing to Steve—we need to build our own phone and completely reset the operating system for that hardware. That was not the answer the company wanted then as we were totally committed to building out phones as we did the PC ecosystem. That meant no first party hardware and a software-only business selling the operating system to many phone makers. That also meant none of us would have been welcome additions to the team.

As a postmortem, I met up with one of my friends for dinner to talk about the situation and the state of the products, especially the phone situation we found ourselves in the middle of. I managed to inhale an entire slice of Metropolitan Grill 9-layer chocolate cake. Yeah, I was in a bad spot. I managed to inhale an entire slice of Metropolitan Grill 9-layer chocolate cake. Yeah, I was in a bad spot.

A few years earlier I had a wonderful and enriching sabbatical teaching on the east coast. I gave a lot of thought to the idea of switching gears. It didn’t get to the point of discussing it. I’m glad I kept quiet, but that didn’t make it any easier.

We had a slightly different product to build.

On to 071. Resolving NetDocs v. Office

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