Hardcore Software: When Microsoft Office Went Enterprise

This is an edited excerpt from Hardcore Software: Inside the Rise and Fall of the PC Revolution, a Substack “memoir” from Steven Sinofsky about his time at Microsoft during the rise of the PC. This post includes parts from entries 55-57, shedding light on the transition of Microsoft Office from an end user–focused product to an enterprise product. Although enterprise sales and multi-year contracts proved incredibly lucrative, they added unforeseen complexity to product development.

Over the course of two decades, Sinofsky held a variety of roles, beginning as a software design engineer in 1989 before eventually leading the development of Office and ultimately serving as president of the Windows division.

It was 1999, and Microsoft Office was riding high. Millions of people around the world used the product, and the company had just released Office 2000. It was a legitimate cash cow. Inside the Office team, however, we had our share of challenges. 

Office 2000 was released during a sea change for Microsoft and the technology industry. Office was not the only place (or even a place) for excitement at the time. Individuals were excited by web browsers, MP3 players, and new gaming systems — not laptops and productivity software. And enterprise IT teams weren’t excited by anything that caused them work — they were spending their cycles trying to stabilize internal infrastructure, convert legacy client-server applications to the web, and prepare for Y2K. 

In a sense, Microsoft was losing competitively … to itself. Office 97 was a good product that individual consumers, office employees, and IT teams really liked, especially after investing the time and effort to deploy it across the organization. Switching to Office 2000 came at a monetary cost to consumers, and with a time-and-energy cost to enterprises that already owned it via multi-year licensing agreements. What’s more, Office 2000 represented the product’s hard pivot into an enterprise-first product. That move meant lots of new features that end-users didn’t want, and new licensing approaches designed to better suit the enterprise business.

It was a double-edged sword: The enterprise reviews for Office 2000 were extremely solid and, really, couldn’t have been much better. The consumer reviews were not so positive. The Wall Street Journal’s Walt Mossberg — a star among tech reviewers at the time — wrote an article headlined, “Microsoft Updates Office Suite, but It’s Not for the Little Guy.” The sting was real.

I was hurting. Did we really mess up? Should we have seen this coming and adjusted along the way? It seemed so obvious. On the other hand, we did exactly what we set out to do. In Microsoft performance review lingo, this was a 4.0 (on our 2-5 scale of the time, where almost no one got a 4.5 or 5).

The answer, regretfully in some ways, was that we did not mess up. The Office business depended on building a product for business customers. The reviews were positive in that regard. The consumer reviews were not the key to the success we were achieving and needed to achieve going forward. We built what we could sell. And we were selling what we built — one of just-appointed CEO Steve Ballmer’s favorite sayings. 

We should do both was a constant refrain during discussions — we should have a great consumer product and a great enterprise product. On paper, that is the ideal situation. In practice, it was not that the needs and desires of each type of customer were diverging; they were increasingly in conflict. It was not that consumers wanted different features; they also explicitly did not want the features of the enterprise. This worked both ways, as enterprise IT decidedly did not want more features, but rather fewer. 

Practically, any time someone tries to take on two conflicting perspectives in one product, the product comes across as a compromise. It is neither one nor the other, but a displeasing mess. The hope I had at the start was that by deprioritizing our traditional retail-customer focus on personal productivity at the start of the release, we avoided the messy middle. We succeeded at that, but I was struggling with how unsatisfying this felt.

Enterprise Agreements and ‘unearned revenue’

Most quarters, our Office finance lead would come to a senior manager meeting, discuss the earnings announcement, and put it in context. As a giant public company, these discussions were not news, but as we transitioned Office into an enterprise-first business, they were useful to help the broader team understand where the money came from (and how much we were spending). Each quarter of results had a new entry in the filings and disclosure went something like this, from Microsoft’s 2000 annual report:

At June 30, 1999 and 2000, Windows Platforms products unearned revenue was $2.17 billion and $2.61 billion and unearned revenue associated with Productivity Applications and Developer products [Office] totaled $1.96 billion and $1.99 billion. Unearned revenue for other miscellaneous programs totaled $116 million and $210 million at June 30, 1999 and 2000. 

It would be an understatement to say that finance was almost giddy over the unearned (i.e. contractually guaranteed, but not yet realized) revenue renumber. It was growing at a crazy rate and the numbers were in the billions of dollars. Sometimes it felt like the world’s largest rainy-day fund (even though Microsoft’s cash on hand was also astronomical) or like we could stop selling software and run the company on unearned revenue for a couple of years. The company had come a long way from Bill Gates’ founding principle of maintaining a full year of cash on hand to weather economic uncertainty.

Revenue was no longer as simple as how many copies of Office were sold. The turn of the millennium was about selling multi-year contracts for Office (and other Microsoft products, often all together). While Office for $100 or even $150 seemed low, gone was the angst over upgrades. The largest companies in the world were buying our software for every PC and committing to keep buying it for the next three years. It was effectively a massive increase in revenue per customer; in exchange, customers received the full enterprise treatment of support, sales teams, strategic partnering, and more. Those benefits were known as Software Assurance or SA.

Instead of booking the revenue for one box of Office entirely in the quarter it was sold, revenue was formally recognized over the life of the contract (usually three years). Contractually, the revenue was guaranteed, but accounting rules meant Microsoft had to wait to recognize revenue. It is easy to see why this is a good idea, as absent that we could conceivably have monster quarters only to fail to sell more products in the future. 

This created a radically new problem for how we thought of the business, and as quickly as these enterprise agreements took over, we had to change how we thought about product development. Unearned revenue (almost an oxymoron, and certainly not a phrase coined by marketing) could sound like an accounting gimmick and was especially tricky for the teams in headquarters that had no real insights into pricing, number of agreements, or even the promises and terms. We only had one important rule, which was that we could not (ever) disclose the future release date of a product. Doing so would potentially turn unearned revenue into earned revenue as the rights to buy an upgrade went from “if” one was available to “when” one was available. Disclosure would also cause customers to attempt to time their deals so as to maximize the number of upgrades they received.

From a few years later, this is from an insert Microsoft ran in most of the tech trade press explaining the mechanics and describing the benefits of Enterprise Agreements. Software Assurance was the branding that captured the benefits available to volume licensing customers.

Microsoft’s enterprise server products evolved to “focus on customers,” as the team often said, which really meant veering off into increasingly IT-centric strategies, making it difficult to surface these features for end-users in Office. The problem was that selling Office to retail customers was a big business but was going nowhere compared to enterprise licensing. Easily half the business was new volume licensing products, and the switch from retail, especially for medium and larger businesses, was progressing rapidly. Soon the bulk of all revenue would be volume licensing and retail would simply be, for lack of a better word, a rounding error.

Still, the Office 2000 product felt too enterprise. I was determined that Office maintain both end-user excitement and broad horizontal appeal — those were our roots, and people sat in front of Office hours every day. Microsoft was rapidly becoming a company of extremes, with Xbox and internet services targeting the latest consumer trends and servers at the extreme of enterprise. Office, used by most everyone with a PC it seemed, occupied a broad space in the middle as products used by individuals and teams, at home and at work, but purchased and managed by IT professionals. This was our product design challenge — how to build a product where the buyers and users differed so dramatically. 

Nonetheless, creating the Enterprise Agreement, or EA, was one of the most brilliant decisions in all of Microsoft history, right up there with the MS-DOS license or committing to Macintosh applications. It is why the company today could so easily transition to selling Office as a modern software as a service offering. Microsoft developed and used a muscle, so to speak, for changing the business terms while maintaining product compatibility. Once again, we see the foundation of the company today forming decades earlier. The EA, which got its start in the late 1990s, was also quintessential Steve Ballmer, combining exactly what the customer wanted with just enough nuance and complexity that Microsoft could stay ahead on the business side, and yes it was also ahead of where we were in the product groups too. The EA started as an “offer,” as Steve would say, and then we worked backwards and filled in the details, or the SA benefits.

Multi-year contracts complicate product development

Key to all of this when it came to product development was that new releases seemed to be able to bypass market validation to appear successful. Customers already purchased the next and latest release, which meant we could easily fool ourselves into thinking the product was a hit by looking at the revenue numbers. Customers were buying a sales and support relationship with Microsoft, as much or perhaps more than the software itself, even when running old releases. While this was not a short-term issue, over time the lack of individual buyers acquiring specific products seriously clouded Microsoft’s collective product judgment. In many ways, the mostly captive Windows OEM model (Original Equipment Manufacturers, the makers of PCs who buy Windows), selling to a very small number of enormous accounts, would presage this product-market challenge.

Unaware of what was possible, end-users never really demanded specific new features, but IT professionals were aware of the possibilities, and what they wanted was not necessarily representative of what individuals valued. Individuals, however, seemed to have a decreasing voice in what software a company used as IT gained control of the chaos that PCs unleashed. EAs were the tool IT needed — in their mind, they paid, so they dictated every aspect of the PC. The divergence of the target buyer from the target user increased with each new enterprise agreement. 

The complexity of enterprise agreements was often comical. There were hundreds of thousands of different deals and price permutations. There was no easy way to sell billions of one thing, just like Coca-Cola didn’t only sell 12-ounce cans of Coke — so went the conversation I would have with those on the team tasked with implementing and tracking seemingly endless and ever-changing SKUs. Not all companies (customers) were on the current release; in fact, most were not. Not all customer EAs started in the same year or at the same time. 

Collectively, customers were equally spread into three cohorts expiring that year, and each of the following two. This meant that any given release was deployed by, at most, one-third of customers. When buying new PCs, the oldest customers upgraded from a version two releases back, a version none of us were running that Microsoft had long forgotten about. Seemingly overnight, EAs created a complexity matrix based on the outside chance that the most out-of-date customers might upgrade to the latest release. We were committing to upgrading from software potentially six or seven years old because at any given time, the current and previous two releases of Office were each used by about one-third of customers — a fact that remained stubbornly true for a very long time.

PCs were also starting to last longer. The first decade of the PC was marked by software consuming every bit of hardware that could make it to market (CPU, memory, or disk space). By 2000, typical PCs had ample specifications for business productivity. The guideline most businesses followed was that new versions of software rolled out commensurate with new levels of hardware. Many companies were trying to get on a cycle to regularly update hardware, but they were finding that doing a refresh of the software load got another year or more out of a PC. Whereas people previously wanted a new PC at work so much they would spend their own money, a practice eventually disallowed, everyone eventually grew content with whatever their workplace provided. PCs and software seemed good enough. 

This dynamic was entirely appropriate to the middle age of the PC era. Instead of moving to a new home, it seemed far simpler to repair the existing one. As central as the PC was to the workplace environment and health, businesses were slowly making different choices. EAs were the perfect way for a business to make one decision and not worry about it again, even if it meant paying a bit more.

EAs also created a crazy environment where concerns over hitting a ship date for retailers and OEMs were secondary to those of IT professionals trying to time the start date of their enterprise agreement. They knew they owned the current version, but if they delayed purchasing for as long as possible, the next two versions might be released and ready to ship as they signed. They deployed the current release and owned the next one, and if Microsoft hit a target ship date, then they’d also own the third. As the renewal dates for a given customer approached, the pressure from that account team to the Redmond marketing team for a public commitment to a ship date only increased. This was all invisible to the broader market, but the idea of renewals was front and center for the entire sales and business leadership.

These IT customers assumed that Office continued to improve, but they were only marginally interested in the product strategy. They really wanted to know if a new release was due within their EA subscription window. For customers, even a month error was a massive dollar-value issue. If we were a month late and a customer didn’t qualify for the product, then every impacted customer sought compensation. Plus, a date range was a joke. Inside Microsoft, if someone said the “first half” of a year, as they often did, then other product groups might assume June 30. Customers hearing the same likely assumed January 1. 

A ship date is a date, not a range. A quarter is 90 dates. A half of a year is 180 dates. I hated this game.

Convincing customers to upgrade from ‘good enough’

EAs came about to maximize an available revenue opportunity and customer relationship (thinking back to a 1993 retreat where we talked about filling the void left by IBM — this was it), even if the product or product development process had not caught up to that opportunity. As we bundled already successful Word and Excel into Office, even though the products were not yet integrated, we were selling enterprise licenses even though our processes (and product) had not yet matured to that level. We were selling subscriptions long before subscriptions were cool, or even built — this is an important and hugely significant legacy of Steve Ballmer’s enterprise sales leadership (eventually, these EAs would be called recurring revenue).

Given this, Office needed to create features that delivered so much value to IT professionals in the enterprise that they outweighed the cost of deploying (and, in their view, training) employees. Simply making Office more enterprise-friendly and easy to deploy was nice, but it was still more difficult to deploy than to do nothing. We needed to accomplish this on time and within the magical three-year window.

I genuinely believed that we had created an unsolvable problem — creating enough business value to justify an upgrade in the eyes of the gatekeeper. Imagine trying to make Word, Excel, and PowerPoint so much more valuable that the new features were worth more than the sum of all the old features? Difficult enough, but what made this even more absurd was that the IT people were actively customizing Office to disable features they deemed to be of low business value. It was not surprising to see companies disable access to HTML, templates, Visual Basic programming, or data connectivity features simply for concern, or fear, that they might get misused, waste time, or generate support calls. While this was acute for Office, upgrades were an industry-wide challenge.

Failing to create value, some in the industry moved to upgrades by force by changing the file formats, creating proprietary connections between servers such as Exchange or the Windows web server, or by requiring the new version for patches or updates. Office generally resisted these artificial growth methods.

This ran counter to new internet-era companies, which were not about such tightly coupled software but about loosely coupled software. This philosophy was the exact opposite of how Microsoft created new features. The connection between Exchange and Outlook was as tightly coupled as could be — each required the other, and without both there was no value at all. Internally, there was increasing pressure to make the Office Server Extensions (OSE, built with FrontPage — the code that made possible collaboration using Office and HTML) less about the browser and more about the core productivity apps (Word, Excel, PowerPoint) like there was pressure to more closely connect innovations in Office to the browser.

Enterprise agreements were making it look increasingly difficult to build the right product. How ironic.

If there was one lesson building the apps business, it was that great releases empowering individuals and helping them to create compelling documents pulled Office into companies. There needed to be some balance. Achieving that balance was our goal for planning what would become the next product, Office10.