052. Alleviating Bloatware, First Attempt

“Microsoft’s Office 97 contains 4,500 commands for features both useful and arcane.” in “Microsoft May Face Backlash Against ‘Bloatware’”—WSJ, 11/18/96

What happens when your biggest strength and greatest asset as a product development organization becomes your biggest weakness? Perhaps that is inevitable. With so many potential disruptive forces, at least that’s what we were hearing, it was almost too much that the very thing we really excelled at—building new features—would become a problem. While the idea of software bloat or even the phrase bloatware was hardly new, it was being applied increasingly to Office. This is the story of the first attempt at doing something about this issue.

Note to readers: Substack introduced a new feature this week—free excerpts with the remainder of the post for subscribers. I’m trying this out to see what subscribers and potential subscribers think. I do welcome feedback. The proceeds of this work do not benefit me, and subscribers can also join in the comments and discussions.

Back to 051. HTML: Opportunity, Disruption, or Wedge

---

This Wall Street Journal article became a symbol of what we needed to fix about Office when it came to bloat. “Feature Shock” and “4,500 commands for features both useful and arcane” not to mention “[IT director] couldn’t care less” were enormously painful to read. This article was one I carried with me all the time for my entire tenure in Office. (Source: personal collection, WSJ November 18, 1996)

Features. That’s all we ever talked about. Adding features. Fixing features. Missing features to be added or fixed. Office achieved the position it achieved, as precarious as it seemed now with the rise of the WWW and Internet, by adding more features with more regular releases of new versions than competitors. Reviews focused on features and we won reviews. We had built a team, an engine to add features.

As fast as Clippy could appear after hitting the F1 key, it seemed as though our greatest strength and our most significant asset—features—had become a great weakness. We went from dominating competitors with more well-executed features to being crushed by the perception of the weight of our products. The industry latched on to the expression bloatware to describe products that seemed to have too much—too many features, too many megabytes, too slow, too difficult to use, or simply too much.

It was one thing to develop a strategy to address a customer problem we had created, albeit inadvertently, when it came to total cost of ownership. We even committed to building fewer productivity features, despite the internal backlash over personal productivity moving to priority six. It was entirely another thing, however, to look at what we built and be pressured into admitting customers didn’t want or need it. They were buying it by the millions of copies.

Were customers, press, and analysts right? Did we have a product problem, a technology issue, or a marketing challenge, or some combination? Of course, the development team was convinced marketing wasn’t convincing people how amazing the product was. Marketing was certain the dev team was not delivering business value. Press and analysts were relentless. What could we do?