032. Winning With the Suite

Strategically, the bundling-unbundling arc or cycle is one of the most common dynamics in technology. Something that starts off as a single product or category inevitably becomes part of a bundle of features or products. Only later that bundled product faces intense competition from a stand-alone product introducing a different point of view. Choosing when to compete with a bundle and how to innovate within category occupied our collective mind in Applications in 1994. A big bet was made to market the Office Suite (or bundle) while the categories were still in play. Organizationally and culturally, we were still very much a set of categories. Had the market settled on Suites or not? This is a question faced by most every company with a single successful product and provides some interesting experiences and lessons.

Back to 031. Synchronizing Windows and Office (the First Time) [Chapter V]

There were two major shifts taking place in the early 1990s together altering the market landscape for business software. The most visible was the move by the business market to Windows, beginning with Windows 3.0 but picking up the pace dramatically with each subsequent release, Windows 3.1 and Windows 3.11. Bringing networking to the operating system, a seemingly simple ability for PCs in an office to share files and printers, was becoming a force.

By 1993, Windows/DOS PCs were outselling Macintosh ten to one and Windows was on 30 million of the 120 million PCs worldwide, with Windows dominating new PC sales.

That transition itself did not instantly shift the Applications market, though. The leaders of each category, particularly WordPerfect for word processing and Lotus with its 1-2-3 spreadsheet, as well as Borland with both Paradox and dBase databases, were not only entrenched but had passionate customer followings. Law schools were using WordPerfect and newly minted lawyers were proficient in the inner workings of the mysteries of formatting a brief with reveal codes (WordPerfect’s mysterious codes that showed formatting before WYSIWYG, or what you see is what you get in GUI). MBA students were masters of the 1-2-3 slash commands for navigating a financial model. That Windows 3.x ran these products extremely well, because compatibility with MS-DOS was a key design point, only solidified them. Windows 3.x made running MS-DOS products even better by supporting multiple programs running at the same time.

However, the graphical interface was beginning to put pressure on existing MS-DOS leaders. The improved support for printing (supporting more printers from various manufacturers), as well as the ease at moving information from one app to another with the clipboard were tangible benefits. With the rise of laser printers, the era of producing business and school reports that included charts, graphs, and tables in-line with the text—all prepared camera ready—was a new baseline expectation. This was vastly easier with GUI apps.

As a result, product reviews began to evaluate the MS-DOS and Windows products in the same category. The word processor category, for example, included Word for Windows and WordPerfect for MS-DOS. The reviews would compare features but also compare ease of use at complex scenarios, often including the ability for documents to incorporate information from other sources. Even though the Windows applications were behind on features and had different user-interfaces from MS-DOS, there was an uptick in perception based on ease of use of GUI.

To be fair, the tech elites of the time greatly resisted the GUI—often claiming the mouse and all those graphics were counter to productivity. I had witnessed this myself in 1984 at Cornell when people looked at the mouse and shook their heads, referring to it as a toy, and to the inefficiency of lifting their hands from the keyboard. Working within the disconnect between evolving technology and entrenched elites proved to be a theme throughout my career.

At the same time, existing software leaders resisted or at least paced themselves with the move to Windows. Many over the years tried to either explain or rationalize this and much has been written. Microsoft committed a ton of energy trying to get the likes of Lotus and WordPerfect to be launch partners with Windows versions or to just commit to Windows, even as Microsoft was building Windows versions of its own apps. There was no head fake on the part of Microsoft—it was believed that Windows would be best with Windows versions of leading apps and the Microsoft apps would, as they had been on MS-DOS, do everything they could to compete and win. Even with all the effort, leading vendors viewed Windows as yet another platform and most were also not wild about adopting the Mac (this was the opening that was created for Microsoft) and were still focused on character mode platforms. The reluctance of betting on a platform Microsoft controlled with its apps was real, but in hindsight proved . . . limiting.

Ironically, the success Apps achieved on the Mac provided a winning strategy roadmap for Windows—both the applications and the operating system—in creating the right ingredients to take advantage of the market change from individual products to suites, the second shift of the early 1990s in business software. Whereas the killer app on MS-DOS was Lotus 1-2-3, on Windows it was really Office that proved to be that. The Excel team might say that they created the defining app, and that is arguably correct.

On the Mac, both Excel and Word had proven successful products on their own. In modern terminology, these products had clearly demonstrated product-market fit. PMF was coined by Andy Rachleff, cofounder of the legendary venture firm Benchmark. Product-market fit means a product so clearly satisfies a market need that the market literally pulls the product from the company, no matter any incidental flaws or execution challenges. I wish I had the term PMF to work with as so much of what I experienced is rooted in an understanding of what it means to work on something before, during, and after PMF.

PMF for Office on the Mac was a statement about the role of GUI in business (then only on the Mac) and the feature set of each of these products. Professionals were as passionate and committed, perhaps more so, to Word and Excel (and PowerPoint) on the Mac as professionals were to 1-2-3 and WordPerfect on MS-DOS.

The interesting business challenge was that a majority of customers were not purchasing both Word and Excel, and fewer were purchasing PowerPoint. We weren’t sure why that was—market size or price. Did fewer people need a spreadsheet than needed a word processor? Probably not. More likely, the retail price of $495 per product was the problem. The computer cost about $3,000 at the time. The notion that the software would become a significant portion of the price of the computer was perplexing at the retail counter, no matter how much Microsoft was spending on Research & Development or how much that metric might not make sense. The industry was not quite ready for software to become a bigger business than hardware—it was the computer business.

Creating the Office Suite was a brilliant move by Apps marketing. It created a new category of product while building upon the strengths of the existing products, and at the same time was a fantastic value for customers. The fact that no other company had all the elements of the Suite was a competitive bonus that would mostly not matter on the Mac but prove to be a significant advantage on Windows. The pricing for Office was an incredible bargain at $949 suggested retail. I remember buying copies for a professor back at Cornell from the Microsoft Company store where software sold at a steep discount to employees, essentially for the cost of goods. I don’t remember the exact price, but it was less than $100 though shipping it was costly as the box weighed ten pounds and was huge. Still, it was a popular holiday gift in 1990.

Windows Office followed Mac Office but with a slightly bumpier journey. Externally, with Windows, the challenge was first winning critical acclaim and customer love over the category competition. The journey would take years for some customers—not only were the MS-DOS leaders loved, but those products were hard to learn and customers invested a lot in the keystrokes, macros, plugins, and in the existing files, which were difficult to import and export with Excel and Word. The MS-DOS PC era was characterized by investing in a PC and software to the tune of $3,000 ($7,000 in 2019 dollars) or more, and then literally taking classes and buying books to learn to use the computer. I spent two summers in the mid-80s at Martin Marietta teaching people how to use WordPerfect and 1-2-3 (but never both to any one person as “secretaries” learned WordPerfect and managers learned 1-2-3).

For each customer, this would have to happen at least twice, but perhaps three or more times for Office to win. In other words, it wasn’t enough for Word or Excel alone to win, but both had to. In any given business organization, there were many lawyers using WordPerfect and finance people using 1-2-3 that made this challenge significant.

In evolving Apps to sell Office for Windows, the launch of Office 4 was a watershed moment. It wasn’t exactly a moment, rather a rolling series of releases that started October 1993 (while I was still Technical Assistant) and a massive wave of marketing and PR, including getting some major mainstream business press. The software was available as Office 4.0 for Windows. It contained the new Word 6.0 (the third release) and the existing releases of Excel 4.0, PowerPoint 3.0, Mail 3.1 (it was the fourth version of Office that began with Mac Office 1.0 in June 1989 containing Word 4.00, Excel 2.20, PowerPoint 2.01, and Mail 1.37). It took until the summer of 1994 and Office 4.3 for the full suite to be updated to include Word 6.0, Excel 5.0, PowerPoint 4.0, Mail 3.2, Access 2.0, and for it to also be available on the Mac. Including the time to translate the software into other languages, Office 4 released over the course of almost a year. I was still signing off on the releases at the tail end as GPM of OPU in late 1994 months after I joined the team. The version number chaos described above is intentionally included showing just how random it was for customers.

The idea of releasing all the updated products at the same time seemed to be a combination of impossible and undesirable from the perspective of each individual product following different schedules and with different category dynamics in the marketplace. The closest any product got to a ship date was Excel 3 by 11 days but imagine trying to get every product to hit the same date—it boggled the mind. More importantly, the GMs for each of the apps didn’t see any benefit to even trying such a feat.

The early days of the PC Revolution were characterized by two major product development forces. First, making things work at all was a huge accomplishment. Second, getting anything done on any sort of reliable schedule was not only difficult but almost an anomaly. Everything was riddled with bugs and late. What doesn’t get enough credit was how much DAD was beginning to figure out, and uniquely so, how to accomplish both quality and schedule. Excel, under ChrisP’s management, led the charge across the division.

Simply getting software out the door, releasing, was exhausting, and most of the burden for releasing Office fell to part of the new OPU program management team I had just started to manage. It was labor intensive and frustrating trying to create one product release from multiple product lines moving at different velocities with different engineering processes and levels of schedule precision, across both Windows and Mac. While the teams might have used the same words, the meanings differed, and the cultures built up attached a high value to those differences. Releasing Office meant combining all the floppy disk images across products on to a minimal set of disks (for cost reasons) and building a single installation program, while also maintaining efficiency in producing the standalone category products.

While Microsoft managed to create an Office release, we did so without a shared understanding of the basic steps each engineering team maintained. For all practical purposes, each of the product teams was almost like an independent tribe within DAD. Worse, OPU was viewed as just another tribe. Worse than that it was not even a major app on its own, just a bundle. Early adopters might have purchased Office, but they were clear they used Word and Excel, rarely mentioning Office by name.

All of this was happening under the constant scrutiny of product quality, the second major challenge facing DAD. Word, as solid as it was, continued to have perception issues (or a reality) regarding product quality. Like many products, Word 6.0 for example, was known to be one where customers were better off waiting until the first servicing update or point release, Word 6.0a, before it was deemed reliable. It was not uncommon for industry press to get caught up in anecdotes about bugs and quality. There was little a product team could do about that given that the only data that existed was what Microsoft recorded in private bug databases and haphazard customer reports or press anecdotes. Huge amounts of energy were spent by the marketing team to manage the perception of product quality. Often one reviewer would have a bad experience and for months not miss a chance to mention that in a weekly column. The fact that most writers in tech had started to use Word (along with Windows for the first time) and most had personally run across data-losing bugs, only increased the frequency and gravity of this challenge.

Across Microsoft and the industry, every product went through a similar release cycle including the market confusion over the quality of a new release. Every new product released later than some expected, certainly later than the original schedule. Bugs were reported and word spread that the new product still had bugs as though a product could ever have no bugs. NT was rumored to have thousands of bugs even when it shipped. Interviews and calls to reporters with the company followed, making clear the product was the highest quality ever. An announcement of an update always followed. Professionals concluded it was important to wait for the update. The press concluded the product was rushed to make a deadline that had passed. Marketing entailed a significant effort remind potential customers that there was no need to wait and the quality was high. Then a release or point release shipped, and the product was ready for market. In practice, it was quite typical for a product to become substantially better with these first updates. Such was the climate of these early days.

Creating the suite, as difficult as it was, had started to transform the business, and the bet being made in late 1993 with Office 4.0 for Windows and creating OPU was that the future of the business was the suite. Over two million copies of Office were sold in that fiscal year, and half of the overall DAD business (which was itself half of Microsoft’s revenue) came from suites compared to sales of single products. Office was itself a $1 billion business. An actual $1 billion dollars, not an accounting gimmick or allocated revenue. Each license of Office that was sold was essentially a retail sale counted on that day—it would be a few years before multiyear licenses would become the norm.

The creation of OPU, described in the next section, was a major effort in DAD and came a few years after MikeMap’s enormously successful and effective Business Unit structure. Still, any time something that people loved and was working changed, things became difficult. This was no different. Incredibly, what started as a marketing experiment transformed the business and the industry.

During this time, Lotus had finally and fully committed to Windows with a major update to 1-2-3 for Windows. Lotus had, through acquisitions, a full complement of products to create a suite known as Lotus Suite first releasing it in early 1992. Building Office was no longer a nice way to sell more stuff, but had, seemingly overnight, become a key entry in a major competitive battle.

Unfortunately, this meant BU leaders were in both a suite war and a category war. Or did it? The market was transforming, but how quickly? Would focus on competing come at the expense of competing in traditional categories? How could we tell if we were making a lot of money selling standalone products as all the competitors to DAD were doing? The answers were not readily apparent. Any time a business is in transition, decision makers can lose sight of the cause and effect of actions. Are today’s numbers secure? Are they relevant to the future? Did last year’s choices still matter? Is today’s revenue predicated on doing more of the same or a bet on the future?

There were some issues to consider. The industry had not yet bought into suites. While there was a wave of broad reach press about the transformation of the industry being fed by both Lotus and Microsoft, the product reviewers and industry analysts were rather undecided. Should customers get all their products from one vendor? Would customers be happy with a suite when one or more of the elements would not win reviews in a category? Why don’t the vendors focus on making their individual products interoperate? Would customers come to value consistency and integration across products more than specific innovations and experiences within a category? At the extreme, there was a view that suites were somewhere between marketing gimmicks and attempts at locking customers into inferior products that can’t stand on their own. The constant grumbling was “suite versus best of breed” and “most people don’t need so many products.”

Second, the category battles on Windows seemed to be just getting started (unlike on the Mac where it seemed Microsoft had little risk of losing on word processing, spreadsheets, and presentations). To those working on the categories, particularly BU leaders, the Windows competition and market situation felt decidedly different, and more precarious, than the Mac. Some believed betting on suite consistency and integration felt like a way to make a worse spreadsheet competitor just so it could do some stuff with the word processor—a feeling shared by many in the industry, not just the hallways of building 17.

Third, the notion that somehow magically all the products (and BUs) would agree to ship their products at the same time and meet these schedules with good quality seemed, well, laughable. The Office 4.3 nine-month lead up had been nothing but staggered releases of products so there was ample evidence to suggest such an alignment would be impossible. Nobody wanted to hold back the shipping of a single product because another product was out of control. We were there to ship not to stare at the finished work and admire it.

Strategically, one would have to make a leap to agree that suites were the future, especially on Windows and especially as a BU leader being held accountable for success against one category competitor. Operationally, the leap to designing these integrated scenarios and shipping them at once seemed nothing short of wacky. To each BU, it seemed like a case of taking on the most external dependencies possible and hoping for the best at a time when the culture was to reduce all external dependencies. The fact that this was teams at the same company in the same division in the same business did not make it feel any less external.

In the waning days of stand-alone apps versus the suite, a widely-distributed memo emerged from the Excel program management team by Lisa James (LisaJ) outlining a process to “manage” dependencies from the perspective of Excel. The approach was structured and hierarchical, with Excel sitting at the top of the hierarchy. Every other team was a dependency to Excel and Excel had the right (and obligation) to fully manage that process. It was the hallmark of shipping and hardcore. Ultimately the goal was to minimize dependencies whenever possible and if not then tightly managing a dependency using a rigorous process was required. This model worked for Excel and was critical for innovations such as Visual Basic but would prove challenging to scale. To any team on the receiving end of this process, it felt a bit intimidating, as in don’t mess with Excel intimidating. But it worked.

In building a suite, there were countless external dependencies as everyone involved was an external dependency to everyone else. The BU approach could not be operationalized for this to happen. Plus, it was suffocating. The rule of thumb was to basically have one dependency per project, which was impossible in building a Suite that was filled with dependencies. The idea of dependency management would ultimately grate on me so much we effectively banned the term and renamed all such relationships partnerships, while also changing the tone to be more congenial and less authoritative.

In our first Office-centric effort to shape the program management team, we actively evangelized the idea of partnership over dependencies with a new memo and training, along sweeping change in operations and even our vocabulary. In the process our team pioneered many of the approaches used to build products spanning divisions. We did away with dependencies and introduced the idea of partnering.

As it would evolve, the idea of betting on collaboration and partnering across the teams would prove to be a huge cultural shift within the Desktop Applications Division and the new Office Product Unit.

On to 033. Creating the Office Product Unit, OPU

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