080. Progress From Vision to Beta
"Our business is in the midst of a broad change in customer attitudes and perceptions. These perceptions can be summed up in two words: good enough." — Office12 vision opening sentence
This section tells the story of a plan coming together and the breadth of the release. We did have a bit of a speed bump early on. I was told to align schedules with Windows Longhorn (the next Windows release). The difficult reality of Longhorn had not yet sunk in. The new user interface for Office12 had surprising upsides. While we were confident, we did not know at the time just how positive the changes in Office12 would prove to be.
Back to 079. Competing Designs, Better Design
Organizationally, we had become a (relatively) well-oiled machine. Procedurally we knew how to work. We also knew what was required at the high level and individual teams knew how to fill in the details with plans. Writing this all down and communicating to the organization a product vision—the vision for Office12—was the next step.
Transitioning from Office 2003 to Office12 was happening across more than 2,500 engineers. In every respect we were building a coherent and collaborative plan with little dirt flying and no injuries, as the old MikeMap description of Office went.
By spring 2004 we had a complete product plan in addition to the user experience redesign described previously. Even with excellence of execution, this was not a lather, rinse, repeat release. Collectively, we learned some lessons from the previous releases. We learned more is not better, and that it was time to rethink, or, as we said in the vision, redefine the user experience. We learned that blindly following the enterprise path could lead to stasis, and in technology failing to innovate or standing still was equivalent to going backwards even when the best customers were telling us of the high costs of change. And finally, we had a firm grasp of how the product was going to evolve beyond document creation—the role of servers, services, email, and more were all important parts of Office12.
The question was not whether we had a good plan or even if we could execute, but would the results live up to our goals. . .finally. There was also a huge risk to making a big bet on changing the user interface of the product—an incalculable risk. It is the kind of risk you either accept and go for or don’t try at all. Many people inside the company, and even on the team, immediately saw the risk of such a big bet and absolutely wanted to know the risk mitigation plan. There wasn’t one. Any risk mitigation plan would only result in a compromise design, because at every step someone would be saying not to worry, we always have a fallback. Backup plans on big bets have a way of permeating the whole product development process and ultimately deny the resources required to achieve the goals, reduce the appetite for risk, and simultaneously dilute the efforts to achieve the bet itself.
From my perspective Office12 was all about that opening sentence of the vision document and a single slide shown at the team meeting for the vision. It read, “No More Good Enough,” with a big red circle slash. Surrounding that PowerPoint SmartArt on the slide were reviewer quotes about bloatware and competing with Sun’s free OpenOffice, along with some juicy analyst quotes about technologies that still weren’t going to pan out. It was not that we set out to compete with a free product that had yet to make inroads, but we needed to reset the narrative that Office was complete, old, boring, and, worst of all, bloated. We had to show that there was deep thinking in the product and the paradigm of document creation was ripe for innovation, and by doing that we could demonstrate to the market that productivity tools were not commodities.
In the conventional wisdom of the day, Office was ripe for disruption. There was a less capable product claiming to be a substitute for less money. We took the initiative, intent on doing the disrupting ourselves and not letting something like OpenOffice, or our old products, do it to us. Not to race ahead, but one thing they don’t tell you about in disruptive theory is that losing to a head-on competitor is almost never what happens. Head-on competitors end up, well, running head-on into the entrenched product and that is exactly what happened with OpenOffice. Google’s future suite would initially make this same mistake, but we were at least a decade before they would begin to address that false start, and three years before even their first release.
The redesign of the user experience was more than one part of the product or strategy. It was so visible and so potentially disruptive that we knew no other aspects of the release would rise above it, certainly in the initial product reception from beta through release. Managing the team and project knowing this reality was JulieLar’s mission.
The overarching importance and the inherent risk of the redesign was not lost on the team. We had become accustomed to working together and collaborating. This was the sixth major release of the product and we’d been executing as a single team, not siloes of app teams, for a decade. The team was not fighting the shared redesign effort as much as it was rallying around it. As teams saw the design make it into the product, rather than point out how it might not work and cause it fail to make the point, teams came together to make it better. It wasn’t everyone at first, but over time that was the case. Among thousands there would always be doubters and honest skeptics, but mostly there were legitimate concerns that required more work.
Success has many siblings and failure is an orphan as the saying goes. Time has certainly reduced the number of doubters across the team and company. Those working on the Ribbon have many stories of people across the rest of Office and Microsoft expressing extreme doubt and risk, but those too have softened over the years as people came to realize the different roles people play during a time of change. Suffice it to say, some of the doubters were hardcore and neither quiet nor necessarily even-handed in criticism. The same could be said of supporters. Anyone going through a big bet with massive downside would need to learn this lesson. It would come in handy for me.
The product vision process really came together. After the very rough start for Office 2000 followed by the over-correction in Office XP, and then again by another over-correction back to enterprise in Office 2003, we hit stride. The process very much became our culture and defined a new way of building Office. The output of the process, after just a few months of planning, included a robust vision document—the plan—over thirty-five pages containing details for all critical stakeholders. We covered the breadth of the 4 Ps of the marketing mix across product, price, place, and promotion. From a culture perspective we dove deep into the core tenets of the release, the non-debatable points meant to streamline discussion and reduce debate. We did so in a unique Office manner by offering tenets that themselves often contradicted each other. I had a favorite example of that. We had one tenet “Security trumps everything” followed immediately by a tenet “Privacy also trumps everything” which was a clear message to the team to be smart about resolving issues even when they contradict. The goal of the vision was to communicate the product but to also serve as a decision framework—it was not a detailed product specification, intentionally so. The full set of tenets is quoted below.
Security trumps everything. No feature will be important enough that it justifies exposing our users to malicious code.
Privacy also trumps everything. Office12 will not compromise our users’ privacy for anything.
OS and Hardware requirements remain the same. Office12 will target the same versions of the OS as Office 2003.
No new system components. Office12 will work with the Office 2003 level of system components and redistributables.
Instrumentation for all features. Any work that doesn’t include usage instrumentation will be considered incomplete.
Performance counts. Performance of key scenarios will not degrade with the new version of Office.
Flawless forward compatibility. Solutions, documents, and other content from Office 2003 will migrate to Office12 flawlessly.
Office12 is a true language-independent binary. No language-specific work will be built into the Office12 binaries.
Full accessibility. Office12 will comply with the current and future accessibility and privacy regulations flawlessly.
Watson throughout the lifecycle. We will be addressing Watson issues throughout the development of Office12.
The main themes of the release provide insight into the cross-organization nature of the plan. We worked hard to keep the plan from reflecting the org chart. While obviously different scenarios had a locus of technology in the organization, by and large everything important involved multiple teams across Office. One challenge this process always had, and Office12 showed this as well, was addressing scenarios broadly defined as database or data access. This deeply technical area had many strategic partners across the company, but also a unique relationship to Excel, which organizationally shared an executive within Office. Interestingly, we always struggled the same way most modern-day data-intensive applications struggle. All data eventually ends up being pasted or opened as a text file into Excel. Figuring out how to avoid that manual step eluded us just as often as it did for customers or third-party software.
As with previous releases the teams created sketches of the vision by each product pillar as will be described. These sketches serve several key purposes. First and foremost, they are a tool for the team that owns an area to commit to delivering what is shown. These are not aspirational or directional but are supposed to represent commitments. The rest of the company was swimming in prototypes with a lack of clarity over when or if they were planned products or simply documenting thoughts. Second, the sketches served to inform the team about what everyone was working on and to provide a holistic view of the product end-state. Finally, these sketches help us to see the product end-to-end in a way that helps us to evaluate the plan for each customer segment. Ideally the sketches are not far off the final release of the product, just as the mock press release we created should be close to the real thing at the launch. With all the changes to the user experience, we did not have the production bandwidth to make sure each sketch had the most current designs, making the sketches a bit uneven in this regard. When I reflect on this, I’m glad we never over-produced the vision and importantly did not delegate the production to a distinct group, but rather we kept the low production values and saved our energy for the product.
The new user experience encompassed two vision areas. The first was “Redefining the Office Experience” representing the mechanisms and mechanics of the interface design. The second, intentionally the second, was “21st Century Documents” which emphasized the customer facing benefit of the design and the kinds of cool and important new documents that could be created. Having two big, bold, and modern goals as the first two was an intentional effort to up the ante.
The next vision area brought together our collaboration efforts for teams and enterprises, mostly SharePoint. By this time, the business of SharePoint was still catching up to its strategic importance. We still had far more traction with sales, marketing, and partners than we did with deployment and usage, but that wasn’t going to slow down iterating. It usually takes three times to get something right, and this would be the third release of the product.
For brevity, the remaining items are quoted below, including investments around data access which encompassed XML (again) and connecting data in SharePoint to desktop tools.
Redefining the Office Experience. Office12 will redefine the experience of using our applications through a bold new UI, more streamlined tools, and a deeper integration with the shell for system and document-level tasks.
21st Century Documents. In Office12, documents will not only look dramatically better but will also integrate much more efficiently and dynamically with the systems and processes of which they are part.
Effective Teams and Organizations. Office12 will fulfill the promise of group productivity, making organizations more effective through enhanced collaboration tools, better access to corporate assets, and stronger integration with the desktop.
Manage Your Time, Work and Relationships in One Place. Office12 will bring together improved e-mail, calendar, task, and contact management tools, enabling our customers to manage their time, work and relationships in powerful new ways.
Unlock and Incorporate Business Information. Office12 will make it easy for customers to collect, find, view, and analyze relevant data, communicate their findings to others, work together to make decisions, and measure the results of their actions.
Breakthrough Quality and Satisfaction. Office12 will be the most trustworthy and easy to deploy version of Office ever, and will mark a leap forward in increasing the value of our digital connection with our customers.
The Office12 Vision from March 2004 (not formatted for printing originally)The schedule started in May 2004 (after shipping Office 2003 in late summer / early fall 2003). We presented the vision in March, giving everyone about 8 more weeks to finalize the specific features and development schedule for each milestone. While we were anxious to begin, a big risk landed on us at the last minute. The primary reason for this would be our old friend Windows and Longhorn.
Days before releasing the project schedule for Office12—not a schedule I just made up in my Office or DonGa the Office development leader dreamed up, but a consensus across the leadership—there was a panic about Office missing the opportunity to align with Windows. JeffR, the executive vice president of Information Worker products, called me to his office to talk about the late-breaking issue. We just finished Office 2003 and at the start of that release there was a fire drill to align schedules between Windows Longhorn and Office 2003. Here we were again being asked to align around that same Windows release, with our next release of Office. The optimism Windows had in late 2000 now had a couple of years of work and it was abundantly clear the project was not where it needed to be. My head began to throb.
The elephant in the room was once again the Windows schedule only this time it was their alignment of the Windows desktop and Windows Server releases. The Server just finished a release in April 2003 and Windows XP SP2 was still about six months from completion (partially why Longhorn was adding risk as well). While the core operating system was the same code for both the desktop and Server, the differences and additions created a bottleneck to getting both done on the same schedule. As a result, Windows had to admit that getting both the desktop and Server products done at the same time—something highly desirable from efficiency and go to market perspectives—was not possible. They put together a schedule with Longhorn desktop finishing in the second half of 2005 and the server shipping 6-12 months later, or second half 2006. Since Office had both server and desktop code, trying to synchronize that presented an immediate problem, besides the reliability of a schedule with multiple 6-month ranges built in. This seemed to me to be a rather theoretical discussion given the history of Windows ship date ranges (versus actual ship dates).
The approach I took was to suggest releasing in sync with Server (aka Longhorn Server) which aligned with our proposed RTM date based on the detailed vision plan of May 2006. That seemed reasonable given the stated goal of alignment with both. Most everyone was really irritated with me for lack of flexibility, which seemed odd given the constraints. Much to my frustration this came across as a desire to ship above shipping the right thing, even given the realities of the situation. I just had to accept this characterization and let events play out.
Writing this I am sure some recall what ultimately happened, at least the headline. The Longhorn desktop project would go through a big “reset” (they called it the Longhorn Reset) and eventually shipped in late 2006 for an official street date of January 2007 for Windows Vista. The Server team became frustrated and chose to ship Windows Server 2003 R2 (comprised of a Server 2003 service pack and optional components) in December 2005. The full Longhorn Server released in February 2008. As for Office, our May 22, 2006, date turned out to be aggressive and we ended up shipping on August 15, 2006. We were 12 weeks late.
Looked at another way, from the start of planning releases after Office XP in May 2001 and Windows XP in August 2001, Office shipped both Office 2003 and Office12 (Office 2007) before another release of Windows or Windows Server shipped. It is not unfair to say I received a ton of grief at the time for putting us on both the Office 2003 and 2007 schedules, which I still think was unfair as it was abundantly clear at the time how the schedules would unfold. Nevertheless, there is no joy in being in the right when others ran into problems.
The most interesting aspect of this type of history is to consider an alternate scenario. What would have happened if Office just slipped along with Windows? Would it have mattered if we never shipped either of those releases and just eventually aligned around what became Windows Vista (Office Vista)? From a business perspective, it is almost certainly the case we would have continued just fine due to the compelling nature of product-market fit as described earlier. Office XP could have carried us for another ten years, just as Windows XP could have (and sort of did). From a product development perspective, however, I could easily make the case that it would have been disastrous for Microsoft. Technically, we would have lost out on the long-term investments in servers and services, and a host of other important architectural efforts (including alignment with Exchange Server and the browser-based apps) so incredibly key to the anchor of today’s Microsoft Office 365. The much deeper impact would have been to the lack of maturity we gained in the product development process to operate at scale. The team would have just been wrecked. I don’t think I’m being dramatic to put that out there.
Rather than point out that we read the landscape correctly, I wanted to share what it felt like to plan and execute in this environment. These challenges were one thing faced from my position in Office and little did I realize at the time how important this experience would become as I moved to Windows.
With our plan in place and the whole team charging ahead with a great deal of energy and excitement, what followed was night and day from Office 2003. Where Office 2003 felt like a slog, perhaps bloated like the product, Office12 seemed to cruise along. While there were daily debates over the ever-changing interface, the fact that the product was changing so dramatically was, for most on the team, incredibly energizing. It was also nerve-racking. There were exciting moments along the way such as seeing the first right-to-left Ribbon design, as we’d ship to Hebrew and Arabic speaking countries.
Two of the more substantial issues the first two vision areas had to work through were performance and exposing more features of the apps in a manner that truly tapped into the potential of the new user-interface.
In terms of performance, we were pushing the limits of what thought would work in our apps. For the history of Office, formatting and changing the appearance of documents happened one single command at a time. Developers worked super hard to optimize this to be as fast as possible, but the user would only perceive it in extreme cases (for example changing a chart type with hundreds of datapoints). Live previews, a feature of the Ribbon, proved to be an enormous engineering challenge—never before had the products computed so many alternatives while a user simply hovered a mouse over choices. With a live preview, the Ribbon showed dozens of potential outcomes of applying a command in a gallery, while also showing the results live in the document, to save users from endless loops of trying and undoing commands. There were many opportunities for the product to be slow and non-responsive. Some on the team said the design was too difficult and we should abandon the hope of delivering previews. It would have been easy to give up. From a pure engineering perspective, live previews were an incredible accomplishment. For the press and reviews, the feature brought the strategy of results-oriented front and center making it very easy to visualize the concept. End-users could experience a whole new level of trying out a look without the dreaded undo-redo command sequence. Features such as paragraph styles in Word or new graphics capabilities in PowerPoint were brought to life in a show-me-first manner never before available.
Releases always have surprises along the way. Usually, the surprise is that the release is taking longer than planned. Office12 was the kind of release where the surprises were how much better things were going to be than even we thought. The battles, and I’m using that word on purpose, between the UEX team and the Word, Excel, and PowerPoint teams over how much to use the new user interface and for what features were difficult and really stretched the teams. The longer debates raged the less we could get done, and if you’re looking to not do something then a delay tactic is a great way to get to a point of “would love to talk about this more but at this point the schedule is locked anyway”. That’s an awful “process win” we did not like. Each time a new aspect of the user interface came online in daily builds, internal friction was reduced a bit and some cross-group cooperation was unblocked.
BillG always complained about the fact that each Office “module” (he always called them modules and we called them apps) had some form of tables, with different features and substantially different user interfaces. The Ribbon gave us a chance to bring similarity to these while also showcasing the depth and capabilities latent in the product simply because the user interface was too complex or inaccessible. By latent, the features were unused because people could not find them or did not know they existed. The Ribbon gallery made it so simple, trivial even, to have a fancy table with colored rows and columns, even totals by columns (who knew Word had spreadsheet formulas?). These were also consistent across the applications as well. It was easy to change and customize. Since almost every document and deck had a table, it was easy to spot an Office12 document from across the room simply because of the cool table formatting made possible by the Ribbon. To eyes like Bill’s, it looked like we had more shared code and aligned the implementations.
Across Word, Excel, and PowerPoint, documents were dramatically cooler and more modern (that was the word we used, and overused). The process of creating documents was blazingly fast, mistake free, and easy to change. Not a day went by when we were not blown away by the new capabilities of Office.
The design had a fascinating effect on new features. As the Ribbon was implemented, many features simply got better because of the way the Ribbon could expose them. In using the product over many years, Excel users developed clever ways to make cells red, green, yellow, or some other coding, depending on the values (if sales growth was negative then color the cell red). The manual steps required were laborious and automating this mysterious at best. The Ribbon placed new conditional formats front and center—with clear, colorful labels showing exactly what could get done with the gallery. Suddenly everyone easily added color coding based on cell values with a single click. This only made the new features even better such as cells with small up/down/sideways arrows or miniature graphs of values.
Surprisingly, ancient features were given a new lease on life and brought front and center. Generations of writers had long been traumatized by the ritual of pasting a picture into Word and trying to understand how to wrap text around it, or not. The Ribbon exposed the existing features for images and using the gallery made it trivial to select a picture and then choose among the set of choices for flowing text. It only took 20 years, but finally everyone could easily paste pictures into Word and make the text wrap around or align with the image.
This Ribbon dividend significantly improved the ability to market the product as both new and improved as well as getting more out of what was viewed as underutilized.
The team also set out to quantify the results of the Ribbon. It would not be enough for us to simply feel good or just know. The usability team explored every aspect of the design in our test labs. Hundreds of tests were conducted at the most micro and macro levels.
TBriggs on the user research team repeated earlier eye-tracking studies over the course of development, revealing how much less tiresome it was to find features. The deep red blob of eye-tracking marks was replaced by a calm and ordered browse of the Ribbon. Subjects left tests talking of how much less stressed they were using Office12 compared to the previous releases and how much less time they felt they were blindly searching for what might work. In general, people expressed much more mastery of the product rather than confusion or frustration.
Any change comes with a cost. While we knew learning would take time, encouraging news emerged. After the one- to two-week learning curve that caused diminished productivity, there was a significant productivity increase. People created richer, more expressive (and more modern) documents in less time. The increased use of the product translated into better work outcomes and more success with the very work they intended to do. This went beyond fancier documents, too—people created documents for a reason: to persuade, deliver bad news, sell products, run projects, and more. Doing so more effectively was a huge benefit to the information worker, even if economists were not able to measure this for a generation of PC users.
We loved the Ribbon.
By the fall of 2005, about 18 months after Vision Day, we were ready to show the work to the world, or at least beta testers.
These early adopters would have some feedback for us. If we expected them to simply fall into line and cheerlead, we were mistaken.
On to 081. First Feedback and a Surprise
I recall the UI Effect Curve coming from Tim Briggs who conducted the majority of user research on The Ribbon. I remember he presented this to Bill as evidence of the effect of both the 'productivity trough of hell' (2) and the ensuing 'rise to the promise land' of productivity.