One of the main challenges in leading a big team is that nothing ever seems to finish—there’s always more to building a team. Even at milestones, one looks ahead and sees more work to do. In the first few months I had been working on Windows so far, we re-organized the team in a huge way and shipped Windows Vista, only to then have to figure out how to plan a product release with this entirely new organization, while building an improved engineering culture. The planning work began in earnest in December 2006 and concluded July 2007. This is the story of those months and what it was like and what management tools we used to develop a product plan for what would become Windows 7.

NOTE: This post is free for all subscribers as we try out the new embedded audio.

Back to 087. Reorg! Why Are We Together, Exactly?

SteveB loved to talk about his discussions with engineers as he tried to better understand the company’s execution and culture challenges. He would say “I talked to this engineer on the team, and they told me ‘Look, everything is completely screwed up and everybody telling you how to fix it is wrong.’” Steve would continue to listen to a litany of problems and why everyone was being “dumb” wondering what he could possibly do. Then the engineer would look up and say to Steve, “But I [emphasis on “I”] know exactly what to do and how to fix it.”

My problem was I was also that engineer. I saw the problems and “knew” what to do. Except it was my job and I had to lead the team to fix the problems.

Fortunately, early on there was a set of like-minded engineers who were willing to sign up and take on the challenge of building a culture and now a plan for what comes next. From the very start it was not just me driving the cultural changes, but the set of leaders put in place from our big re-org.

Change across thousands of people, each of whom knows exactly what should be changed, is not a one-time event. Change takes repetition. It takes calendar time. It takes making some mistakes and using those as learning or teaching moments. While everyone was anxious for change, thousands of engineers must be given time to think and reach the point—on their own—of agreeing to a certain kind of change.

Every step over the next few months, from the time of putting an organization in place to starting the real building of products, we (the leaders) would be confronted with two realities. First, we had to remind everyone on the team consistently and repeatedly of the process we were using and how we aimed to work together. Every. Single. Communication. At times it felt like we were reading the inside of the box of a board game at every meeting. Second, every time we made a mistake and didn’t ourselves follow that process, expect someone to point that out and for that to become a moment of humility.

It was a constant push-pull with so many wanting to know what we were telling people to build while we were busy pushing back and saying how we needed them to figure that out. At the same time what we wanted to do would look radically different from the past. It wasn’t a top-down plan. It wasn’t a disconnected set of innovations. It was not about consensus of design as in design-by-committee, but a coherence of a plan. The investments (as we would say) were going to fit together into a holistic product plan across our new organization: WEX, LEX, IE, and COSD. After every step in the process, we regrouped as a leadership team and not only talked about what parts of the process we needed to improve, but we turned that into coaching and more outbound communication such as my Office Hours blog. At the same time, we were continuously adapting to what was understood, misunderstood, and especially challenged when it came to process.

An example of cultural change that was front and center was a desire to match the old Windows team in terms of scorecards or KPIs by automating or operationalizing key requirements. I would be out there talking about vision and scenarios and collaboration—abstract concepts that need to be made concrete by the team—only to find out some people were trying to make a vision scorecard or building an automated testing tool to check if scenarios were complete or tools to red/yellow/green dependencies between different teams. We’d come across this and then would need to course correct and talk about how accountability works without constant monitoring by others nor overwhelming bureaucracy.

Every email and memo, every team meeting, every 1:1 was a not just an opportunity to reinforce the new cultural norms, but a requirement for us to do so. The first and most important test was developing a product plan for the next release following Vista. For us to get to the finish line with a coherent product all at the same time and all on time we would need to get to the starting line at the same time.

First, we needed a product name. By now you know I was never a fan of codenames.

Windows had always had somewhat clever (too clever) code names with layers of meaning. As a consumer of these code names, they neither made for secrecy, as one could routinely read about the release code names in trade press, nor did they make it easy to remember what someone was talking about. “Is that in Nashville or Memphis? I can’t remember.”

Windows Vista was the sixth major release of Windows and it was version 6.0.6000 for techies. So, by fiat I christened the code name of the release Windows 7. I thought I was being the opposite of clever and we could simply move on, as we had done when we picked Office 9. Oops. Immediately I made two mistakes. First, did I reach consensus on this name? Second, did I even understand the ramifications of the name I picked unilaterally?

This sparked a debate that only geeks would participate in (at the time and once the name was made public), which was: How did we count versions of Windows? Technically, this was not the seventh major version, as some would debate. My view: Windows 1.0, Windows 2.x, Windows 3.x, Windows 95, Windows XP, and Windows Vista. But wait, there was Windows NT, and there was Windows 98, 98SE, and Millennium edition.

It turned out there were lots of ways to count and lots of ways to have more than six previous releases or fewer than six. Essentially, everyone could be right. I probably received two dozen emails with different algorithms for counting how many releases of Windows had been done, ranging from “well, it was really only four” to “at least a dozen.”

I stuck with seven.

Crisis averted by executive authority. Temporarily.

The test and engineering system team informed me that we could not possibly “bump the major version number,” as this would cause a whole slew of problems for application compatibility. It turned out many existing Windows programs were bad at checking what version of Windows was running and failed to run if the “major version” (that would be the first digit) was incremented. I knew this from Office 95 when we skipped several version numbers to align all the apps.

Marketing had input too: that we had to make it version 7.0 because if not the press would think we were doing a minor version and then enterprise customers would not see the need to upgrade. So even though the engineering system did not want the major version number changed, the marketing team did.

This whole notion of “major” versus “minor” as the press characterized releases would drive me nuts. It seemed as though a major release was one that broke a lot of stuff and finished late. A minor release was one that worked because it polished features and finished on time. My view, no surprise, would be based on resources. Did we have everyone working on the release or did we peel off a subset of people to work on something less for less time than a normal release? Windows 7 had everyone, 100 percent. And we were determined not to break things. And we were going to finish on time. It was a major release.

I had an urge to quit before we even started. If this trivial thing was going to be so consuming, imagine what the whole release was going to be like. Yikes.

Despite the uproar, we stuck with the Windows 7 code name, and the ultimate irony turned out to be that we eventually stuck with the name for the commercial product as well.

Planning moved forward, but it became clear that there was a new challenge at every step of the journey. There were two sides to every situation we faced.

Some people on the team wanted to be left alone, confident in what they would be working on and that there was nothing to be gained by delaying the start of the work. In some sense this was true because some parts of the product were known. We knew we needed to improve the engineering system, for example, and we knew we would do another turn of the crank on many areas, such as performance, device drivers, and security.

On the flipside, there were the people who wanted to be told precisely what to do, simply because they had frequently and repeatedly come up with ideas only to have the rug pulled out from under them by new strategies, scheduling, or resource constraints. Those people wanted to know what success would look like for them as individuals and on a granular level. The big picture was not their concern.

This made things tough.

It was tempting to remove constraints on the “correct” people and tell others what to do. It would feel quite good to be making progress and to be able to report work is happening, especially to the anxious executive team above me. Even identifying the right teams along these lines would fall into old behavior patterns we wanted to break, mainly, that there were always the elites in Windows who were given freedom to do what they felt was right, while other too often teams fell victim to management processes. I believed that we could do better if we followed the old Shipping Software adage and got everyone to the starting line at the same time. The goal was to get the maximum number of ideas on the table via broad participation of domain experts and create a holistic product plan from that—a Windows version of our Office approach to participatory design.

The planning memo was a tool developed in Office to begin the process of the release and to kick off a participatory design process. Over several iterations we came up with a format that provided a structure such that people could investigate what to build, without having the conclusion in advance and without necessarily having organizational ownership or structure in place. It was planning but without a pre-ordained plan arrived at by execs beforehand or retrofitted from known technology efforts already underway. It was a tool for empowering the team to ensure the best ideas came forward.

The organization needed to transform before we could transform the product and culture, but we would still need to avoid the perils of shipping a product defined by an org structure. Perhaps the biggest change we would make was the transformation of the next level of the organization away from the history of product units to a large group of feature teams of development, testing, and program management. Windows 7 (WEX, IE, and COSD) ended up being about 45 teams with about 1400 software engineers. In addition, there was a design and research team of about 100 people and about 20 product planners dedicated to Windows and reporting to JulieLar. We had a large team responsible for international versions of Windows coordinating the work with translation resources around the world.

The idea of less than 50 teams was important because each milestone would involve a meeting with teams and that needed to be manageable. I didn’t think we could scale beyond that, but frankly I thought we had more than enough by way of resources to build a great product. If we could better organize, we could simultaneously tap more creative energy from within the team while improving efficiency and causing the whole to operate smoothly and pleasantly.

In the process of organizing the team we moved several significant-sized teams to the division that makes Xbox, including the Media Center, music rights management, and the non-platform elements of gaming. Some other teams, notably what remained of Windows Presentation Foundation (Avalon) moved to join with the rest of the .NET Framework, putting an end to a cross-division skirmish. A small subset of Avalon that also moved was building a cross-platform browser-plugin that supported video playback and conferencing, codename Jolt. That plugin would eventually be renamed Silverlight and offered as a competitor to Adobe Flash while also serving as a developer platform for a new Windows Phone. The resulting Windows team became much more focused on delivering and building for Windows and these divisions were excited to have more control of key technologies that did not need to be part of the Windows platform. I was very happy to do these moves.

While some were amazed that we could create $150 billion in market capitalization with only a few thousand engineers, I still thought the team was a bit large. Office created as much with 20 to 40 percent fewer people. I wasn’t there to cut costs and never even thought about reducing headcount. Bloat, inefficiency, and lack of clarity in a product, however, come from too many people especially when poorly organized.

In the abstract, it is easy to see the attraction of small-focused teams tackling problems independent of each other versus a flexible and agile (though perhaps monolithic) group that adjusts to changing needs at scale. In practice, and especially at any scale, the small, multidisciplinary team rarely has an outsized impact in the context of a big business and always finds itself challenged to hire and grow deep engineering talent. Furthermore, when organized in such a manner the teams do not share in a larger mission and as a result the overall product loses the ability to shift resources around as needs arise. If a key feature team needs more resources, the head of engineering (AlesH or BenFa) can load balance across the whole organization without disenfranchising a multidisciplinary manager who would feel undermined by losing their resources to another manager. I was certain this would be important with Windows 7 because the teams had not previously done rigorous scheduling or hit a ship date.

This was a truism based on what Microsoft had achieved, not a theory or abstract concept, and was my rationale for why a structure of flexible feature teams wasn’t a management fad that would swing back in the other direction down the road. Windows was one product, and we would organize and operate like we were building one product.

JonDe, JulieLar, and I, with important contributions from marketing and product planning, wrote the December 2006 memo, Planning Windows 7, outlining the state of the business and putting forth product and business priorities. The planning memo puts a large bounding box around the release but is not yet the plan. It kicks off a process, inviting participation from everyone on the team. Using the familiar Harvard product development funnel, we were opening up the funnel to ideas.1

Who knew that hitting Send could be so stressful? Again.

Julie and her counterpart in COSD, ChuckC, would drive the planning process and own the resulting plan, which would be a document called the Vision for Windows 7. Julie, having been part of the process in Office several times, would be the key owner. Julie also wrote an outline of the overall vision process, a primer basically, that was sent and resent many times throughout the next few months. The first challenge was that a good portion of the PM team believed the planning memo was the plan, when it was a framework to think about what the plan could be. To others, this memo and process seemed to be bureaucratic or arbitrary process getting in the way of what everyone knew we needed to do. Out of the gate the need to talk about building a coherent and cohesive plan where everyone on the team was accountable to promise and deliver was our key leadership message.

The planning memo was over 30 pages, but the first two pages were essentially instructions for how it works or “the inside of the box” as we described it—another example of the ongoing repetition of how we will work.

The planning memo is where the business enters into thinking. With most of the team and audience engineers, we would use every product start to reiterate the business fundamentals and what levers were being explored.

It is in the planning memo we talk about the kinds of challenges the financial side of the business face, as we did in Office with respect to enterprise sales. In Windows there were multiple constituencies: PC makers (OEM) representing a huge portion of Microsoft’s business concentrated in just a few customers, developers who make use of API innovations in Windows, ecosystem hardware partners who supply components to OEMs and peripherals to end-users, enterprise customers that run their business by deploying Windows desktops and laptops, and of course consumers and end-users. Also critical was the role the core Windows operating system played for Windows Server. Nearly every aspect of Windows impacts two or more of these directly and generally speaking it was not the type of challenge that had been pushed down to teams the way we were working to do.

The first section of the memo focused on the need of Windows to bring energy and health to the PC business, especially by finding scenarios where home users would have more than one PC and where business users would see value in more feature-rich editions of Windows. Unlike the Office business, the Windows business was much more sensitive to the sales of new PCs rather than the core value proposition to enterprises.

It is worth keeping in mind that “renewed growth” and “health” were somewhat counterintuitive to any business metrics readily visible to the team—Microsoft’s history of paranoia was definitely present in our planning, and that was a good thing. There were no material signs that the PC expansion was slowing. We still had not seen the giant leap Apple would make in “personal computing” with the iPhone that was announced in January 2007. In the coming months (exactly 3 months) Steve Jobs would announce that there would be an SDK to build apps for the iPhone and iPod. Phones were getting smarter, but people were decidedly still reliant on PCs for the internet.

About three-quarters of Windows revenue came from sales directly to PC makers. While we talked about one billion Windows users, they were only our customers in an indirect way. People bought PCs and those PCs came with Windows, which was purchased by the OEMs. Even if a person had a problem with Windows on their PC, support was provided by the OEM and not Microsoft. Effectively, Windows is a business with fewer than 10 customers, but those happen to be Microsoft’s largest customers by orders of magnitude. This idea of a buyer and a user being different parties with different influences on the product development process was quite familiar to me from the rise of enterprise customers in Office. Where in Office we had an ever-present struggle over the needs of the enterprise versus the needs of individuals across the product, Windows had a much more uneven approach. Some teams were extremely focused on OEM customers while others were entirely focused on end-users.

Contrary to most perceptions, the cost of Windows on a new PC (that is the price to OEMs baked into the final consumer-visible price of a PC) was a fairly low percentage of a PC price and the price had remained largely unchanged for years. This would soon become an issue with the introduction of Netbook PCs (to be discussed in Chapter XIII), but by and large the Windows license was both unchanged and a constant source of frustration from PC makers because of that inflexibility. For a variety of reasons, Microsoft lacked the kind of pricing power one might have expected in such a market. This was in contrast with the price of the Intel portion of a new PC, which was much higher and had increased over the years as Intel provided more and more integrated capabilities and provided more pre-assembled parts of a PC with each new processor generation.

PC sales in 2006 were about 240 million units worldwide. That was an astounding number and our responsibility to do the right thing and better things for all those units. The predictions for 2010 and beyond (from analysts such as Gartner and IDC) showed no end in sight for PC growth, breaking through 400 million in the years to follow. However, as frothy as that might have seemed, there were concerns that the growth rate was finally starting to slow. In fact, 2006 appeared to be the first year since economic downturns when the overall growth rate slipped and never reversed that trend with any staying power. Nevertheless, PCs were forecast to grow about 10 percent (adding 25 million PCs, or about the size of the entire global PC-installed base in 1990). The most interesting trend was a bottoming out of sales of desktop PCs—the laptop had supplanted the desktop PC in work, and totally dominated the home PC market. Computing was becoming ubiquitous, and laptops represented both mobility away from home and in the home. Gone were the days of computers taking over a whole tabletop permanently.

As a reference point, worldwide PC sales for 2019 were forecast to be slightly above 230 million following a pandemic surge approaching 325 million that appears to have receded.

To say the business was entirely dependent on OEMs would vastly understate the potential with business customers who would add the enterprise version of Windows to both new and existing PCs, which represented a substantial uplift in pricing (and that translated directly to profit.). As important as this was, it was much more a matter of packaging and pricing as the company had long ago shifted to developing a wide array of business-friendly features for Windows, starting with security and business networking, with much more in the works.

A significant evolution of the Windows business, rooted in both upsell and competing with Linux, was the release of a low-end SKU, called Home, and a more expensive SKU, Professional. Where Office had different applications (or modules), Windows had different features. The emphasis on these SKUs began with Windows XP but was put into full force with Windows Vista. This is a classic product strategy, but due to the nature of the Windows business the financial upside is enormous. A small percentage in unit upsell from Home to Professional is a price increase of tens of dollars multiplied by tens of millions of units, and all of that is essentially zero incremental cost to Microsoft. The leverage was magical. [To those keeping track of present-day Microsoft quarterly earnings, there’s a consistent talking point about the role of business SKUs in Windows revenue.]

Unique to Windows was the desire to make sure developer APIs were consistently available in the most broadly distributed SKU. Everyone wanted every API to be in Home. This constraint is what made specialty SKUs like Windows Media Center or Tablet PC destined to fail with third-party developers—the APIs developers would use to target those PC form factors were only in those narrowly available SKUs (with expensive hardware.) Seeing the tiny sliver of market, developers would rather attempt to roll their own solution rather than ride the tiny coattails of a niche market. This would become important as we broadened Windows 7 to include touch, where most of that support existed only in the Tablet PC specialty SKU.

The Windows Ecosystem could be thought of as four sets of deeply dependent yet independent entities, each believing that they contributed an outsized effort when there was success while each believing the other parties had more than their fair share of responsibility when things were not going well: Microsoft, Intel making and selling CPUs and associated chips and storage, PC OEMs and hardware makers (Independent Hardware Vendors, IHVs), and software developers (Independent Software Vendors). The mutual dependencies are illustrated by a cycle:

1. PC and hardware makers depend on Intel and Microsoft to deliver a complete PC experience.

2. Microsoft depends on Intel to continue to drive demand with faster chips and new capabilities while enabling PC makers to take advantage of those.

3. PC OEMs depend on IHVs to enable all sorts of new hardware capabilities that will excite consumers and drive demand.

4. Microsoft courts the fourth leg of this stool, the independent software vendor (ISV or “Developers, Developers, Developers” as SteveB would calmly state) such as Adobe, Autodesk, Intuit, or PC game makers to make applications for a new version of Windows with new APIs or that require new hardware (such as faster graphics cards), which in turn require new PCs.

A new version of Windows without cool new PCs or new PCs without cool new chips or hardware or new software that didn’t take advantage of any of those were all reasons why the ecosystem could become unhealthy. This codependency created an enormously tense network made up of a small number of large public companies, each with quarterly earnings reports. Also, at the time, in the United States, Japan, and Europe, PCs sold through a large number of retail stores so companies such as Best Buy, Dixons, or MediaMarkt were also part of this equation, and they were ruthless champions of low price and opportunity for margin.

The second section of the planning memo outlined what were called big bets. We hoped this would engage the architects and long-term thinkers by laying out significant challenges that we knew would need to be scoped and refined. Intentionally, there was only a small number of these so as to scope them to a single release. The constant discussion on bets was about how to define a bet as a set of steps that could be accomplished over reasonable time periods and incremental success, rather than one giant leap a decade later.

One of the unique things about Windows being part of the PC ecosystem while also being an open platform was that when new hardware was available to integrate into PCs, PC manufacturers could build PCs with support for new devices or peripherals without built-in Windows support. OEMs would write their own code from device drivers through user interface to support a new hardware gadget (for example WiFi or a fingerprint reader.) Unfortunately, this created a problem. Too often, such support did not have great APIs for developers or was not always integrated into Windows in a way that allowed others to make the most of it. But with Windows releases not being so reliable and PC makers always looking for an advantage over the competition, waiting for Windows to figure out support for new peripherals never really happened. With Windows 7 we set out to get ahead of some classes of devices (such as printers, graphics, storage, and so on) with a big bet on hardware-driven innovation but would leave it to the planning process to identify areas where such an approach would work.

There were two other big bets of note. Virtualization was becoming a huge push across the industry. But on that front, Microsoft was falling behind. Interestingly, at many team levels, there was a deep resistance to virtualization because of security concerns that the whole system could be compromised. There were also business concerns due to the Windows business having a foundational belief of one Windows license for every CPU. All the while, virtualization was growing rapidly and on every CIOs radar precisely because of security. Their belief was that virtualization was inherently more secure. It was also the core technology that would enable cloud computing and as such it was critical that we get it right. Competitively, virtualization was critically important for the Windows Server business. VMWare, the inventors of virtualization, was rapidly becoming a technology powerhouse under the leadership of Paul Maritz—yes, the former leader of Windows. Ironic moments such as this were in no short supply.

We also wanted a big bet for the typical Windows consumer, which would give us a chance to incorporate Windows Live services as a key part of the overall value proposition for Windows. Historically, Windows had duplicated services provided by MSN (the predecessor to Windows Live), ostensibly for a whole variety of reasons from legal to performance to security, and at the same time the MSN services did not do any work to shine on new versions of Windows. The ultimate achievement of this was the debacle when Microsoft shipped both Windows Messenger and MSN Messenger on new PCs and both had different sign-on, networks, and features. Another example was when the Windows Mail program did not do a good job connecting to Hotmail. This gave us a chance to say, “We will plan on not duplicating work,” at a minimum, but also push to do great work that could potentially compete with Apple or maybe Google.

In order to account for the heavy lifting that would be required to build on the Vista foundation and yet also fix it to the degree we needed to, we defined a big bet that we called “continuing bets.” This provided a catch-all to plan on the needs for improved PC security, 64-bit computing, and overall cleanup work. The fact that the release ultimately succeeded in cleaning up or completing this work led to the frustrating belief by some that Windows 7 was, in fact, a minor or cleanup release.

The traditional Windows view loved big bets—that felt like the kind of work we did for Longhorn. Many on the development side were perfectly happy to define a release by making progress on big bets, even if the manifestation of big bets would take years and the visible features not particularly visible.

From Julie’s perspective, the plan or vision for Windows would be start with planning themes. Rather than a plan itself, the memo contained ten planning themes. A planning theme was a precursor to a specific main pilar of the release. Themes are an invitation for brainstorming and creativity within that theme. Prior to this there is a step to even pick these themes, but that is a small group and done relatively top-down. The planning themes were broad strokes. The introduction of those themes was really an invitation to begin a process whereby the specific groups of engineers (feature teams) work together to define what it might mean to deliver on that theme—a literal call to innovate and be creative. The themes for planning Windows 7 included:

• Refining the Vista User Experience

• Building Customer Confidence

• Embracing the Best of Web Development

• Helping OEMs and IHVs Win the Hearts of Customers

• Turning IT Pros into Windows Evangelists

• Making it Easy to Add or Replace a PC

• Lighting Up Everywhere with Servers and Services

• Finding Everything Easily

• Connecting Multiple Devices to Multiple PCs

• Embracing Hardware Advances for Better Multimedia Experiences

Over the next three months there were countless offsites, meetings, design sketches, and more to arrive at more detailed views of what features might be built. It was this part of the process that is both the most uncertain and nerve-wracking for me. I not only had no idea if the ideas being generated were good, but I didn’t even know if the teams were converging. There’s no way to even measure this. In the back of my head, I was also wondering if there were developers writing code for new features that we won’t even want to ship while PM was off figuring out what to make. If the goal of the planning process starting with the planning memo was to bake a cake, then I just couldn’t open the oven every 15 minutes to check without ruining the cake.

Windows 7 Planning Memo

369KB ∙ PDF File

Read now

Read now

Over the three months from the planning memo to the creation of a product vision the team is not producing code. The PM team was producing slide decks, PM prototypes, design sketches, and even a little bit of prototype code. The development team participated in this part of the process but was also tasked with watching the market telemetry for Vista and fixing a lot of bugs. The test and development teams together were working to improve the daily build and test process—an enormous undertaking that GrantG referred to as building out “the factory floor.” The 6 years of Vista development and the numerous side releases of Windows had made for a neglected engineering process. There was plenty of work to go around. Having the time to address these pain points and to do so together without a crisis enabled even this type of work to become part of the culture change. JonDe dug into every aspect of the daily development process, which he had become acutely aware of in his role leading Engineering Excellence. Fixing the factory floor would prove to be an enormous win for morale and efficacy.

Then suddenly the cake was ready. There was a vision. Reading this, one might really want to know what precisely went on for those months. How did the team go from brainstorming to a plan? The lack of a concrete description of this is why it has always been somewhat magical. It really isn’t magic, but it is empowerment, accountability, and creativity. There was never an answer other than build a great product, but pieces had to fit together, and everyone had to agree and reach a shared view of what was being committed to and being built. Every offsite, prototype, and sketch were talked about, debated, and considered. Most were thrown out for any of a myriad of reasons.

There was, however, one bit of magic and it was connected to a cultural change. The typical (in Windows and elsewhere) executive management role is one where teams go off and generate ideas and come back with a plan, for approval. Invariably during a meeting for approval the plans would be changed with the incorporation of executive feedback. The problem I always had with this was the underlying assumption that an executive thinking on the fly about whatever specifics or details arose during one meeting for an hour after weeks (or months) of work was truly value added or just value changed. I never had that much confidence. We started from an assumption that the plan was already approved, and the meeting was a confirmation of the plans the team created and was accountable to. The magic was that leading up to those review meetings we were, JulieLar in particular, in a constant and iterative conversation about ideas, tradeoffs, and specifically adherence to the evolving product vision. This led to a much deeper sense of ownership and buy-in and avoided the historic problems of swoop and poop or simply random executive thoughts.

We called the transformation of planning themes to the product vision a pivot (Microsoft loved to use the word pivot in just about every context, especially because it had nothing to do with basketball.) We were pivoting from a long list of themes with ideas of problems to be solved to a much shorter list of vision areas each with specific scenarios we would implement. This is why the vision represented a true product plan.

On July 27, 2007, we gathered the team at the Meydenbauer Convention Center—yes the entire Windows product team was invited—for a meeting where we presented the product vision. The all-team meeting was another step in the culture change. It would be the first time the whole of the Windows team got together to hear the entire product plan—the committed product plan—for a Windows release before coding started. It was so important to me that everyone really experience what we intended to build and to have that moment when as a team we commit.

Just as we did with Office, the product vision consisted of a substantial memo (this time with a bit more up front on how to read the memo), a series of produced design sketches showing each of the main themes of the release as we intend to develop them, a mock press release created by marketing showing how the release would be communicated upon shipping, and my favorite the one page cheat-sheet for the vision.

Even though we had been together for more than year as a team, and Windows Vista had been in market for six months already, we were still transforming and growing as a team. While everyone really wanted to know what everyone else was going to build (by this time most people knew what they were going to start to build) I wanted us to continue to build the culture. I had a slide defining a successful Windows 7 as a set of key traits feeding into success (using Office SmartArt of course): promise and deliver, develop satisfying features + scenarios, create partnerships [not dependencies], participate and communicate, learn and iterate and improve. Still, we had one more slide articulated how to use the vision. At this point, if you’re not convinced management is repetition…

Before JulieLar would take the stage and share the vision themes and features, we had a special speaker. Although now formally transitioned from his role as Chief Software Architect to philanthropist and Chairman of the Board, I thought it would be important for BillG to share a personal view on the role of Windows within Microsoft. He delivered a wonderful and improvised talk without any slides. It was a mix of history and enthusiasm for the most recent innovations lasting about 15 minutes. He spoke of the patience we showed in building Windows after the first releases that were too early and the bet on having Office for Windows which made Windows better and Office better. I did ask Bill to emphasize competition knowing that was near and dear to him, given I had already shared with him my view that there was a bit of a lack of fire in that regard. The iPhone was just weeks on the market and the potential impact on the PC industry was just becoming clear and did not escape Bill’s mention, including some speculation about a tablet-sized device for reading (this will be discussed in Chapter XIV.) He also touched on Linux competition which was acute in the enterprise space and on servers. The highlight for me was when Bill held up the vision one-pager and reinforced that this was the product he was expecting, and he too would behave and not ask people about things not part of the plan—the team applauded and that made for quite a moment for me. That moment didn’t last long as he then told the team it wasn’t critical that we hit the ship date as long as we got all the scenarios working—that is the Office baggage described in previous sections where Office somehow cheats by cutting features to ship on time. There is a recording, but it is poor quality—just a camcorder in the back of the room. 

JulieLar presented the vision itself. It was a work of art. From a dead stop after Vista she pulled the entire PM team across WEX and COSD through a foreign process (an Office process no less.) I could see the excitement and almost amazement from the team as I stood in the back of the room doing all I could to get a sense for the vibe. The vision for the release had five areas:

• Specialized for Laptops

• Designed for Services

• Personalized computing for everyone

• Optimized for Entertainment

• Engineered for Ease of Ownership

Each of these were detailed with scenarios, business motivation, and a definition of success and then illustrated with a narrated design sketch.

Following this ChuckC, Julie’s counterpart from the Windows Core System team in COSD, presented the project tenets. These were the non-negotiable aspects of the project:

1. Design for interoperability

2. Security is a key promise to customers

3. Runs with existing hardware

4. Application and driver compatibility

5. Getting ready for 64-bit only

6. Performance breakthroughs for key scenarios

7. Improved Reliability

8. Design for sustainability, manageability, supportability

9. Design for every market, every language

10. Improved accessibility for all users

Chuck outlined the project schedule which included three milestones—each an opportunity to re-evaluate, adjust, re-allocate resources, and adapt the plan. We would begin coding in 5 weeks, after the US Labor Day holiday. Windows 7 RTM was set for May 13, 2009.

Mike Sievert (MSievert), the CVP of marketing (and as of this writing, the CEO of T-Mobile) provided a detailed overview of the current state of the business and opportunity. KevinJo spoke about the importance of Windows Live, which was in the process of executing a plan to run on a shorter schedule and would have a releases of services for Windows 7 at availability. He also addressed what was top of mind for both of us, which was adhering to the newly announced Windows Principles a series of proactive steps to managing the business that the legal team put forth on their own in hopes of setting a different tone with regulators.2

JonDe spoke to the deep technology shifts in the PC industry where the COSD team had historically focused their energy and where the big bets at the core OS level were critical, especially for Windows Server which shared the OS. He spoke to the work we needed to continue including:

• Multi-core and many-core

• Virtualization

• GPUs

• Wireless

• Storage and non-volatile memory

• Power management

• New and popular devices: GPS, biometrics, web-cameras

• Diverse form factors

To set an example, the meeting went like clockwork and lasted three hours, and there was even a break. After the meeting, I sent out the full memo to the whole team. I recently acquired a new ultra wide-angle lens for my (then fancy) DSLR and took a team photo. Everyone was in their limited-edition color-coded t-shirts which was always done tongue in cheek but certainly plays like something one would see on a bad take of a tech on HBO. I still see these Windows 7 t-shirts around town, which amazes me. I even saw one in a yoga class in Silicon Valley, years after vision day.

I followed up with an Office Hours blog post expanding on my themes of what would make Windows 7 a successful release.

Windows 7 Vision

1.01MB ∙ PDF File

Read now

Read now

The day could not have gone better. I had been through many vision days in Office, but this one was truly a special moment. I genuinely felt like we had reached a milestone of cultural change within the team.

I was of course kidding myself. I only felt that way because for 15 months non-stop I had been saying the same thing over and over again gradually improving. But we were just now starting the real work. Other than my own fatigue, there was no evidence yet to support an assertion that we would get the release done. In reality, I remained terrified. I couldn’t even hide it. KevinJo sent me mail after the meeting saying he felt the meeting was great, but he thought I seemed down.

I was not down—the day was really excellent. I was, however, worried. Would this be enough? Would we get done on time? Was on time even soon enough? We had so much to do. We had so much to fix, starting with the relationships with PC makers who were truly suffering with Windows Vista.

On to 089: Rebooting the Ecosystem