057. Enterprise Agreements [Ch. IX]
"Unearned revenue associated with Productivity Applications and Developer products totaled $1.99 billion." —MSFT annual report, 2000
Welcome to Chapter IX, taking place 1999 to 2001 where the world realized just how dependent it had become on email and the PC when viruses became a mainstream part of the technology vernacular. In the halls of Microsoft, it became apparent that being early was as strategically deadly as being wrong. PCs sell more than 100 million units for the first time in 1999. Things start to heat up on the antitrust front. We are learning to plan a release in the context of a massive change in the business of selling software to the enterprise.
Back to 056. Going Global…Mother Tree
Enterprise wasn’t just the direction of the business—it was the only business.
But could we listen to customers and still fail? That’s what it felt like was happening.
Office 2000 had become entrenched in the enterprise, if not yet deployed it seemed inevitable. In the process, we left end-users behind. Those concerns over too much enterprise focus that were pushed aside to make way for Office 2000 became front and center. From a product development perspective, we were failing in the reviews that we had been trained to want the most to win. Starting with “nothing in it for the little guy” to “thousands of features, some useful and most not” the product was not something end-users wanted.
Business results told an entirely different story. Most quarters our Office finance lead would come to a senior manager meeting and discuss the earnings announcement and put it in context. As a public company these discussions were not news, but at least helped the broader team to 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 that 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 revenue number. It was growing at a crazy rate and the numbers were 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 that we could stop selling software and run the company on unearned revenue for a couple of years. The company came a long way from BillG’s 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 dollars per desktop PC seemed historically 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, called an Enterprise Agreement or EA. 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.
Wall Street had to find new ways to think about earnings. 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. Microsoft created a virtual line-item unearned revenue representing all the future payments yet to be recognized. Instead of topline, Wall Street was now focused on the rate of growth of the unearned revenue. Very quickly billions of dollars from Windows and Office were piling up in the unearned revenue line item. Unearned revenue would convert to plain old revenue on a schedule based on length of the agreement and would be added to the revenue line of reported earnings. As quickly as these 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. It felt super weird to be involved in this dance, but it was also very straightforward. There was even a regulatory investigation at one point because we started to deliver more software online and had to adjust the portion of revenue recognized immediately versus over time.
The problem was that selling Office to retail customers was a big business but 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/EAs 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.
We were years away from phrases such as “consumerization of IT,” or the idea that people wanted enterprise software that felt and worked like the cool consumer software they used outside of work. Office, however, always occupied that space. Used by individuals, even if sometimes purchased by organizations, the software was decidedly built for people who had better things to do. Office was unique software designed for work but used up and down and across an organization in a myriad of ways. Almost no enterprise software was used the way Office was, by every single person in an organization.
Creating the Enterprise Agreement 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 form decades earlier. The EA, which got its start in the late 1990s, was also quintessential SteveB, 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. The EA started as an “offer” as Steve would say, and then we worked backwards and filled in the details.
Office was not like a magazine, utilities, or cable subscriptions with regular flows of some consumable resource. Office never stops doing what it was purchased to do. It keeps going and going. PCs got messed up (all too easily) with poorly behaved software, but corporate IT figured this all out and created processes to clean install a PC and refresh it with known versions of software but none of the bad stuff gumming up the system. Tech enthusiasts knew this too. In fact, the internet became a hotbed of tips and tricks to cure a sluggish PC of ills caused by downloading software from the internet or playing around with the registry. The constant need for security updates had not yet become a reality, but that challenge is just around the corner and as we will see, the enterprise model only made it that much easier for Microsoft.
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 judgement. In many ways the mostly captive Windows OEM model, 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, 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 success created a new kind of problem—when people at Microsoft talked about “the customer” we needed to calibrate to better understand who we were talking about. Windows meant PC and hardware makers, the OEMs. Server products meant enterprise IT infrastructure. Tools meant developers. Office meant individuals and teams. Most of all, the sales force always meant the C-suite sponsoring a sizable deal with Microsoft, the higher up the better. By and large, customer really did mean the high-ranking executives with a direct line to the account team, the executive briefing center/EBC, and SteveB.
The complexity of enterprise agreements was often comical. There were hundreds of thousands of different deal 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 in a given 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. There was another decade or more left in Moore’s Law. It was Moore’s Law that kept people buying a new PC every other year or sooner, which was shifting to more like three years and, in the blink of an eye, to five. 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. Laptops were just a couple of years behind on the price and performance curves but were getting there quickly in a highly competitive market. 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. Windows gained the most by creating an incentive for new hardware, but they were more focused on the consumer and building a successor to Windows 2000 (what would become Windows XP) that equaled the legacy Windows 95 product and their product cycles were much longer. Whereas people previously wanted a new PC at work so much they would spend their own money, a practice eventually not allowed, everyone seemed content with whatever their workplace provided. PCs and software seemed good enough. There was only one customer segment larger than EA and that was OEM which meant by and large Windows continued to focus on OEMs and less so on enterprise customers, at least with the release under development.
This dynamic was entirely appropriate of 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, slowly businesses were 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 two next 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 sales and business leadership.
Wall Street analyst interactions were similar. Analysts maintained an unearned revenue number in their forecasts. They would work hard to extract from me a target ship date which gave me the uneasy feeling that I was just filling in a cell in their spreadsheet model for Microsoft earnings.
My own ability to interact with customers in settings like the Executive Briefing Center (EBC) became its own game of schedule chicken. Customers assumed that Office continued to improve but were only marginally interested in the product strategy. They really wanted to know if a new release was due within their EA subscription window. Every EBC I attended turned into a contest of how many ways can I get asked about the ship date without answering. Often the sales team prepared me for a strategy briefing only to find myself on my first slide dodging questions about ship dates. My standard line was, “We aim to ship a new release of Office every 24 to 36 months, and we last shipped . . .” This was wholly unsatisfying to customers, especially to a specific customer with a specific date in mind for their EA, asking a VP, technically by then a senior vice president. Account managers and country managers were getting increasingly frustrated with me and Office in general for not being more open and committing to ship dates.
Then there were those pesky accounting rules, so I just couldn’t say anything. Still, if I were to give a more specific range to customers (or to the analysts, for that matter, who as a proxy for customers also needed to know) then I had to be right. The problem was we were never right. 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 “first half” of a year, as they often did, then other product groups might assume June 30. Customers hearing the same range 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.
It felt as absurd as it sounds. Yet, it was the reality. It made me look clueless at best; at worst, coy. I hated pretending not to know. I hated acting like we were ineffective at our jobs. So many customers commented, “In our industry we make a big giant complicated thing and if we told our customers we didn’t know when it would finish we’d have no business.”
Every time, I thought about industries from Boeing planes to Ford cars to Bechtel bridges and how late they were. I repeatedly bit my tongue.
Then I stopped putting myself in the EBC. It wasn’t the best practice but I just wasn’t wired for this type of tap dance. I have some regrets.
EAs came about to maximize an available revenue opportunity and customer relationship (thinking back to that 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 SteveB’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 training employees. Simply making Office more enterprise friendly and easy to deploy were 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 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.
Enterprise agreements were making it look increasingly difficult to build the right product. How ironic.
Grinding out relatively on-time releases that shipped on a certain date and doubled down on enterprise features seemed perfectly achievable. There was little risk that we could mess things up with such a plan—I would achieve all my performance goals relative to EAs. The product would probably stink, though, for the people that used it for their jobs every day. We would try to create metrics across the company, incentives to achieve customer upgrades, but no teams controlled anything that could dramatically alter customer behavior. From the product group our job remained the same, to build a great product. We could make a better Office, but that would not dramatically change how fragile a PC was, especially one loaded with IT software and customizations. This wasn’t an excuse. It was reality.
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 Office10.
Hi Steve, another great chapter. Must have been super difficult to decide what features to add and what features to not add for each release. Will you have a chapter describing how the office team made these decisions?