With the Office Product Unit in place, and the outline of a plan to release with Chicago in about a year (whenever Chicago was finishing, which was unclear) and a second major release of Office a year after that, we still had to sell the team on the whole approach. This included allocating resources both to OPU as well as the app teams. From the Windows (and thus Microsoft) perspective, anything less than betting 100% on Chicago was seen as a hedge, yet that was exactly what DAD intended to do. This was decidedly about managing the applications business instead of viewing that business as simply supporting evidence for a new release of Windows. Many firmly believed in a wait and see approach to Chicago which was already, and customarily, very late and the existing Office products would run great anyway. This post wraps up the chapter on building the organization and plan for building two releases in parallel. Looking ahead, the chapters tell the story of building those products.

Back to 033. Creating the Office Product Unit (OPU)

The use of year-of-release code names was not arbitrary but reflected a broad consensus within leadership that Microsoft needed to move to product releases that reflected more of an annuity or subscription relationship with customers. The idea of using the year moniker was based on how car companies used model years. We had yet to prove software could be released in this fashion, reliably, and we still lacked a way to distribute products so quickly, but the idea became a cornerstone of planning what to build and how to articulate value. The early naming research for Chicago was heading down the path of using a year name, and similarly Office 4.x would be the last “version number” release.

Marketing had mixed feelings about the year names. The biggest issue was that for some period of time customers would hold off purchasing a product knowing the current version was old. It was also quite stressful for the development teams that had no idea how to ship so much software so frequently.

Taking the idea of one release in 12 months and a second one 12 months later, both starting from the same date in late 1993 led naturally to naming the releases 94/96, or Office94 and Office96 (no spaces since this was all for file names and source projects). The 94/96 plan was in place. Sync within 30 days of Chicago in the spring of 1995 or thereabouts. Then Office96 12 months later.

The team’s passion was around Office96, with Office94 being somewhat of a strategy tax while at the same time being viewed as an excellent opportunity to prove out Office as a product and OPU as a team. The plan covered what was necessary and sufficient, albeit with a huge risk—what if Office94 took too long as Windows slipped, bumping up against Office96? You can see the schedule chicken already being played with the assumption that Windows would slip their schedule but Office would not, though there was little history across Word, Excel, and PowerPoint to think Office schedules were that robust and zero experience shipping the entire Office suite at once. History would show that no matter how far off Apps might be, Windows was going to be further off.

To execute required employing a great deal of finesse and some game theory. A plan emerged prior to me joining the team but one I sold to BillG as his TA. The Office team’s 94/96 plan split the resources across releases substantially in favor of Office96. Each Product Unit (Word, Excel, PowerPoint, and OPU) devoted one “feature team” to Office94 and the remaining teams were on Office96. A feature team is the organizational unit of a dev team and it is made up of a software development lead and anywhere from three to seven software developers. There was an equal amount of testing and two to three program managers. This was phrased (marketed internally) as “15 percent of the resources dedicated to Chicago” or “85 percent of the resources on Office96.” See what was done there? Everyone got something. When talking to Windows we emphasized the dedicated Chicago team. When speaking across DAD and especially to marketing, we emphasized the 85% on Office96.

Depending on perspective, this was either a relief, albeit still a high cost to pay to get moving on Office96, or a total snub aimed at Chicago. “What, only 15 percent of the team!?” One view was that the unreliability of the Chicago schedule was such that to “sacrifice” any more resources would not be prudent. The worst case would be, ironically, if Chicago did hit the date then too many people trying to do too much in Office would never finish within 30 days.

A different view was that 15 percent was hardly sufficient. Chicago was aiming to be the most important release for consumers (Windows NT was for business) and since the Office business was still a consumer-driven phenomenon it didn’t make sense to be so frugal. In the 15 percent there was a lot for Systems to dislike. If the requirement was to ship simultaneously and reliably with Chicago, then a small team doing the minimal amount was the most prudent, though such thinking was never in line with how Systems worked, which was an “all in, or not in” mindset.

More importantly with DAD, the major challenge with the Office96 part of the plan was the general view that 15 percent of the resources, reductions on top of the shift to OPU, would significantly impact the ability to be competitive within categories, a further reminder about the teams being reduced to “fund” OPU.

If your head is spinning reading this, then you can see why the whole plan of 12/24 was causing heads to spin and adding in the animosity (or just complexity) of the new OPU and shift to suites only made things worse.

We still needed a way to structure the detailed schedule. Normally we would have three milestones of about 10 weeks each. Given the mandate to sync with Chicago the schedule worked out to a single development milestone, instead of the traditional three-milestone schedule. Not only was a small portion of the team on the project but they would be doing a lot less work. Aside from syncing up the final date, the other issue was being available for pre-release testing on the Chicago schedule as they were going to want reviewers to see proof of 32-bit applications. This requirement further justified the schedule and resource constraints. That did little to appease Systems that felt we were totally hedging.

Without a feature list or specification written, things seemed shaky. Picking dates with resource levels set is the first rule of shipping.

Up until this point, most Apps releases had been dictated by the improvements in ease of use while adding productivity features that were the most logical next steps—there was innovation in category features across Word and Excel, but there was also a decade of history in the category, whereas PowerPoint was still establishing the category and faced different challenges. While most of 94/96 was chosen on business and customer grounds of the apps, the prioritization of what to do was heading in a new direction with the emphasis of the suite. There was a great deal of momentum in both the organization and the processes. It was easy for apps, even with fewer people, to keep going down the same path, and it also seemed right from a business perspective. A new product category demanded new investments and new priorities.

Office94 was about Chicago, that was clear, but what did that mean for the category? It would also be the first release of Office to ship all the products on time, which was unique at the time. Office94 would provide marketplace evidence of an integrated suite of products by shipping at the same time with some specific work aimed at demonstrating its suite nature. Reviews were still written by category, though that now included a new category called suites. By and large the yearly issue of word processors or spreadsheets was one of the top sellers of magazines. It would seem we needed category features to fill those pages and indirectly meet demands of customers.

Times were changing, though. The key insight for building a suite, versus selling a suite, was that customers were placing value on the integration and consistency across the component products. Given the origin of suites as product bundling plus discount and the penetration of business software at the time, it was no surprise that the early value propositions from all the vendors centered on ease of use just as the category products did. For suites, however, ease of use was evaluated by user-interface consistency, the idea being that consistency made products easier to learn and thus easier to use. Technologically the idea was that if the products shared code between them to accomplish consistency, then using more than one product would also consume fewer system resources, like memory. It was still all too common for Windows users to see “Out of Memory” error messages and those became more common as users were encouraged by suites to run multiple products at once. There was an architectural synergy, minimal memory footprint, and code-sharing that BillG championed.

Office94 had no time for any major architectural investments. In need of constraints, another constraint was added: Office94 would not change the file format (.doc and .xls) and would rely on the same format as just released for Office 4.x. This became the mother of all constraints, as both a positive and negative. I recognize today this seemingly obscure issue, the details of a .DOC or .XLS file seem far removed from anything that could matter, but in reality that was not the case at all.

Here’s why: Through the entirety of applications on PC from the start, new releases of products nearly always meant new file formats. With that change came the pain of making sure old files could be read and displayed and the experience of saving new files as the old format (to a floppy, for example, to give to someone) and alerting users when something would not work on the old version. While many assumed this was a conspiracy and some sort of theory of obsolescence, in reality changing formats was directly related to the underlying implementation of files. For the most part the file formats of apps represented a direct mapping of the internals of the product and what was stored in memory—in fact, in Word the file format was literally a type of virtual memory. There was neither a level of abstraction nor a mechanism to interpret data that the app did not know about. This clever invention was from CharlesS and something he brought with him from Xerox PARC and was a huge favorite of BillG, who knew all the details of the architecture.

Decades later, the idea of a file format seems rather arcane or even crazy. For the first two decades of the PC era, files were everything—files on hard drives, files on floppies, files on network drives, files on the Windows desktop and in folders, files on USB memory sticks, files in email attachments, files burned on to CD-ROM discs. Files were synonymous with work and files required a program. Without one match the file work could not happen. Thus, file formats created a virtuous cycle for users (or network effect in modern jargon). The more people used an app and shared files, the more their coworkers benefitted from using the same updated version of the product. And yes, Microsoft benefitted too. To many in the regulatory world this looked and smelled like locking in customers. To us it seemed like a natural and beneficial feature. Over time there would be diverging views internally at Microsoft over how critical or even appropriate leveraging this feature would be, as we shall see.

Today many have probably tried to explain files to a student who has only used Google applications and found doing so about as awkward as explaining linear television or fax machines. Except for the occasional PDF or those companies still operating with attachments in email, files are seemingly extinct for non-engineers.

What this constraint implied to the members of the Office suite was that Office 95 would not have any features significant enough to justify a file format change. People could hardly imagine what features might be dreamed up without a way to save them to a file—every interesting feature was tied in some way to saving it in the file.

Fortunately, the needs for Chicago started to echo the needs of 32-bit native applications on Windows NT. The list of work was short and easy to articulate and measure. Everything seemed doable, though there were many concerns about the customer value beyond validating Chicago. I spent a lot of time shuffling across the street to the Chicago dev hallway sort of reverse engineering what would ultimately become the “Windows Logo Requirements” or the minimal set of features that an application needed to implement to pass a third-party certification and receive a “Designed for Windows” logo for the box. Bill was anxious about the specifics of a list of features that apps would implement to be purpose-built for Chicago. The next chapter goes into details.

Apps needed to move to 32-bits. Chicago was going to represent the transition, requiring 32-bits and a 386 processor (which could come from Intel or AMD). While this sounded easy enough, there was a big problem.

Requiring 32-bits and a ‘386 meant that Office94 could only run on Chicago and new Windows NT PCs. Much of the market (and marketing) for Office was to get existing customers to upgrade—that consumed most all of the outbound efforts. The cost of a new PC was significant and adding on the cost of Office at the same time seemed exorbitant. For example, upgrading a 2MB of memory machine to 4MB might cost $200 in chips (often specific to the computer) plus the time and effort to install and configure (PCs required screwdrivers to open and often memory was tricky to install). This added up to a release without many new features that required a new computer purchase, which felt like a loser, or at least risky. Fortunately, it was only 15 percent of the team. Office96 continued on this level of commitment as well, which created a good deal of angst. So 100% of our resources were committed to 32-bits.

In order to believe in this choice, one had to believe that the number of new PCs and the number of people new to computing with Chicago would be so great that the upgrade market opportunity would be much smaller. That was an enormous bet. In the world of business this was the kind of bet known as burn the bridge. Once placed, there was no turning back. It was also the kind of bet BillG loved to make for Apps, as he did with Excel on Windows and with the internet. What we (and everyone at Microsoft) did not know at the time, was that getting a first PC with Windows 95, specifically to “get online”, would be a generational force that would make all of these conversations and concerns look downright silly.

This was a huge choice. Importantly, it was not the same choice our primary competitors were making.

From summer of 1994 through the release of Office94, the DAD leadership team, sometimes called the gang of 10, wore two hats, Office94 and Office96. Every day, every moment seemed to be a context switch between releases.

What we did not anticipate was how that 15 percent would consume so much of the team.

What I didn’t anticipate was that we somehow ended up being so successful at convincing people not to worry about 12/24 that soon people like NathanM were suggesting a far better strategy was something like 12/24/48/60—that we should be building four different products in parallel including one that was 5 years out. It was too soon to be intoxicated with our own success, but such fantastical discussion was just getting started.

Far more important was actually delivering Office 95 as one product for the very first time.

Leave a comment

On to 035. Windows 95, August or Bust [Chapter VI]