Engineering Windows 7 : Planning

Our Next Engineering Milestone

e7blog — Mon, 11 May 2009 20:01:00 GMT

Back in January we released the Beta and updated you on our overall engineering process that will get us from Beta to the Release Candidate. Today, downloading of the Release Candidate started and we’re already seeing a lot of installations and a lot of excitement. On behalf of the team, I want to extend a thank you for all of the millions of people who have been running and testing the Beta who have helped to make the Release Candidate possible. The feedback we have received, through all the mechanisms we have blogged about, has been an incredibly valuable part of Engineering Windows 7. We continue to be humbled by the response to Windows 7. Thank you!

This post is about the path from RC to what we call RTM, release to manufacturing. RTM is not one point in time but a “process” as from RTM we enable the PC manufacturers to begin their processes of building Windows 7 images for new PCs, readying downloads for existing machines, and preparing the full supply chain to deliver Windows 7 to customers. Thus RTM is the final stage in our engineering of Windows 7, but the engineering continues from RTM until you can purchase Windows 7 and Windows 7 PCs in stores at General Availability, or GA.

The path to RTM starts with downloads of the RC. The RC is “done” and what we are doing is validating this against the breadth of the ecosystem and with partners. It means, from our perspective, we have run many tests many times and are working to understand the quality of the release in a breadth sense. We’re all familiar with this as we have done this same thing as we went from pre-Beta to Beta and from Beta to RC. The primary difference with the RC is that we will not be changing the functionality or features of the product at this point—that’s the sort of thing we’ll save for a future release. We’ve gotten tons of feedback on design and features and shown how we have digested and acted on this feedback throughout many posts on this blog. We know we did not do everything that was asked, and we have also seen that we’ve been asked to do things that are tricky to reconcile. We hoped through the dialog on this blog that we’ve shown our commitment to listening and balancing a wide variety of inputs, and how we have thought about the evolution of Windows.

What sort of feedback are we looking for in the RC? We are primarily focused on monitoring the behavior of the product through the telemetry, and of course making sure we did not introduce any regressions in any dimension from Beta quality. One of the things we have done since Beta has continued to beef up telemetry—we’ve put in additional monitoring points in many systems. We’re particularly interested in seeing what devices are installed, drivers that are required, and overall system performance. We have telemetry points that monitor the UI responsiveness of the Start Menu, Internet Explorer (recently posted), Boot, Shutdown, Resume, and across all subsystems. Of course in the final product, this telemetry is optional and opt-in, and it is always private.

There are a series of specific types of reports that we are keeping an eye out for that would constitute changes we would make to the code between now and RTM. Some of these might include:

Installation – We have significant telemetry in the setup process and also significant logging. Of course if you can’t set up at all that is something we are interested in and the same holds for upgrades from Windows Vista. For the “enrolled” beta programs we have a mechanism to enlist a connection to Microsoft for these issues and for the broad community the public support groups are monitored.
Security issues – Obviously any vulnerability is a potential for something we would fix. We will use the same criteria to address these issues as we would for any in-market product.
Crashes and Hangs – We are monitoring the “crash” reports for issues that arise that impact broad sets of people. These could be Windows code, drivers, or third party software. This information streams “real time” to Microsoft and we watch it very carefully.
Device installation and compatibility – When you download a driver from Windows Update or install a driver via a manufacturer’s setup program this is a data point we collect. We’ve had millions of unique PnP IDs through the Beta. We also receive the IDs for devices that failed to locate drivers. We are constantly updating this web service with pointers to information about the device (driver availability, instructions, etc.)
Software installation – Similar to devices, we are also monitoring the installation process of software and noting programs that do not complete successfully. Again we have the mechanism to help move that foreword and/or introduce compatibility work in the RTM milestone.
Servicing – We will continue to test the servicing of Windows 7 so everyone should expect updates to be made available via Windows Update. This includes new drivers and will also include patches to Windows 7. Test Updates will be labeled as such. We might also fix any significant issue with new code as well. All of this in an effort to validate the servicing pipeline and to maintain the quality of the RC.
New Hardware – Perhaps the most important category is making sure that we work with all the new hardware being made as we all use 7100. Our PC Manufacturing partners and Hardware partners are engineering new PCs and these are combinations new to the market and new to the OS. We’re working together to make sure Windows 7 has great support for these PCs and hardware.

All of the feedback will be evaluated and whether the issue is with Windows itself or with hardware, software, or OEM partner code we will work closely across the entire ecosystem to do what is necessary to deliver excellent fully integrated PCs. This goal is more important than anything else at this point. The depth of this work is new for the team in terms of spending engineer to engineer time across a broad range of partners to make sure everyone is ready together to deliver a great PC experience.

Overall, while many have said that the quality of the Beta was on par with past RCs (remember how some even suggested we release it as final!), we are working to do an even better job with Windows 7. We think we have the tools in place to do that.

While the RC itself was compiled about 2 weeks ago, it takes a bit of time to go through the mechanics of validating all the ISOs and images that are released. In the meantime we continue doing daily builds of the product. The daily builds are incorporating code changes to address the above types of issues that impact enough customers that on balance the code change is more valuable than the potential of a regression. Throughout this process, every change to the code is looked at by many people across development and test, and across many different teams. We have a lot of engineers changing a very little bit of code. We often say that shipping a major product means “slowing everything down”. Right now we’re being very deliberate with every change we make.

The RTM milestone is not a date, but a process. As that process concludes, we are done changing the code and are officially “servicing” Windows 7. That means any subsequent changes are delivered as fixes (KB articles) or banked for the first service pack. Obviously our ability to deliver fixes via Windows Update has substantially changed the way we RTM and so it is not unreasonable to expect updates soon after the product is complete as we have done for both Windows XP and Windows Vista.

Between now and the RTM milestone we will make changes to the code in response the above inputs. We are decelerating and will do so “gracefully” and not abruptly. We do not have a “deadline” we are aiming to meet and the quality (in all dimensions) of the product and a smooth finish are the most important criteria for Windows 7. In addition, we have a lot of work going on behind the scenes to build Windows 7 in nearly 100 languages around the world and to make sure all the supporting materials such as our Windows web site, SDK, resource kits, and so on are ready and available in a timely manner.

Once we have entered the RTM phase, our partners will begin to make their final images and manufacture PCs, and hardware and software vendors will ready their Windows 7 support and new products. We will also begin to manufacture retail boxes for shipment around the world. We will continue to work with our enterprise customers as well and based on the RTM process the volume license products will be available as well.

Delivering the highest quality Windows 7 is the most important criteria for us at this point—quality in every dimension. The RTM process is designed to be deliberate and maintain the overall engineering integrity of the system. Many are pushing us to release the product sooner rather than later, but our focus remains on a high quality release.

Ultimately our partners will determine when their PCs are available in market. If the feedback and telemetry on Windows 7 match our expectations then we will enter the final phases of the RTM process in about 3 months. If we are successful in that, then we tracking to our shared goal of having PCs with Windows 7 available this Holiday season.

--Steven and Jon

Our Next Engineering Milestone

e7blog — Fri, 30 Jan 2009 11:00:00 GMT

Many posts start with a thank you and I want to start this post with an extra special thank you on behalf of the entire Windows team for all the installs and usage we are seeing of the Windows 7 Beta. We’ve had millions of installations of Windows 7 from which we are receiving telemetry, which is simply incredible. And from those who click on the “Send Feedback” button we are receiving detailed bug reports and of course many suggestions. There is simply no way we could move from Beta through Final Release of Windows 7 without this type of breadth coverage and engagement from you in the development cycle. There’s been such an incredible response, with many folks even blogging about how they have moved to using Windows 7 Beta on all their machines and have been super happy. The question we get most often is “if the Beta expires in August what will I do—I don’t want to return to my old [sic] operating system.” For a Beta release, that is quite a complement and we’re very appreciative of such a kind response.

This post is about the path from where we are today, Beta, to our RTM (Release To Manufacturing), building on the discussion of this topic that started at the PDC. This post is in no way an announcement of a ship date, change in plans, or change in our previously described process, but rather it provides additional detail and a forward looking view of the path to RTM and General Availability. The motivation for this, in addition to the high level of interest in Windows 7, is that we’re now seeing how releasing Windows is not something that Microsoft does “solo”, but rather is something that we do as one part of the overall PC ecosystem. Obviously we have a big responsibility to do our part, one we take very seriously of course. The last stages of a Windows release are a partnership across the entire ecosystem working to make sure that the incredible variety of choices you have for PCs, software, and peripherals work together to bring you a complete and satisfying Windows 7 experience.

The next milestone for the development of Windows 7 is the Release Candidate or “RC”. Historically the Release Candidate has signaled “we’re pretty close and we want people to start testing the release, especially because all the features are done.” As we have said before, with Windows 7 we chose a slightly different approach which we were clear up front about and are all now experiencing together and out in the open. The Pre-Beta from the PDC was a release where we said it was substantially API complete and even for the areas that were not in the release we detailed the APIs and experience in the sessions at the PDC. At that time we announced that the Beta test in early 2009 would be both API and feature complete, widely available, and would be the only Beta test. We continued this dialog with our hardware partners at WinHEC. We also said that many ecosystem partners including PC makers, software vendors, hardware makers will, as has been the case, continue to receive interim builds on a regular basis. This is where we stand today. We’ve released the feature complete Beta and have made it available broadly around the world (though we know folks have requested even more languages). As a development team we’re doing just what many of you do, which is choosing to run the Beta full time on many PCs at home and work (personally I have at least 9 different machines running it full time) and we’re running it on many thousands of individual’s machines inside Microsoft, and thousands of machines in our labs as well.

All the folks running the Beta are actively contributing to fixing it. We’re getting performance telemetry, application compatibility data, usage information, and details on device requirements among other areas. This data is very structured and very actionable. We have very high-bandwidth relationships with partners and good tools to help each other to deliver a great experience. One thing you might be seeing is that hardware and software vendors might be trying out updated drivers / software enhanced for Windows 7. For example, many of the anti-virus vendors already have released compatibility packs or updates that are automatically applied to your running installation. You might notice, for example, that many GPU chipsets are being recognized and Windows 7 downloads the updated WDDM 1.1 drivers. While the Windows Vista drivers work as expected, the new 1.1 drivers provide enhanced performance and a reduced memory footprint, which can make a big difference on 1GB shared memory machines. You might insert a device and receive a recently updated version of a driver as I did for a Logitech QuickCam. Another example some of you might have seen is that the Beta requires a an updated version of Skype software currently in testing. When you go to install the old version you get an error message and then the problem and solutions user interface kicks in and you are redirected to the Beta site. This type of error handling is deployed in real time as we learn more and as the ecosystem builds out support. It is only because of our partnerships across the ecosystem that such efforts are possible, even during the Beta.

Of course, it is worth reiterating that our design point is that devices and software that work on Windows Vista and are still supported by the manufacturer will work on Windows 7 with the same software. There are classes of software and devices that are Windows-version specific for a variety of reasons, as we have talked about, and we continue to work together to deliver great solutions for Windows 7. The ability to provide people the vast array of choices and the openness of the Windows platform make all of this a massive undertaking. We continue to work to improve this while also making sure we provide the opportunities for choice and differentiation that are critical to the health and variety of the overall ecosystem. This data and the work we’re doing together with partners is the critical work going on now to reach the Release Candidate phase.

We’re also looking carefully at all the quality metrics we gather during the Beta. We investigate crashes, hangs, app compat issues, and also real-world performance of key scenarios. A very significant portion of our effort from Beta to RC is focused on exclusively on quality and performance. We want to fix bugs experienced by customers in real usage as well as our broad base of test suites and automation. A key part of this work is to fix the bugs that people really encounter and we do so by focusing our efforts on the data we receive to drive the ordering and priority of which bugs to fix. As Internet Explorer has moved to Release Candidate, we’ve seen this at work and also read about it on IE Blog.

Of course the other work we’re doing is refining the final product based on all the real-world usage and feedback. We’ve received a lot of verbatim feedback regarding the user experience—whether that is default settings, keyboard shortcuts, or desired options to name a few things. Needless to say just working through, structuring, and “tallying” this feedback is a massive undertaking and we have folks dedicated to doing just that. At the peak we were receiving one “Send Feedback” note every 15 seconds! As we’ve talked about in this blog, we receive a lot of feedback where we must weigh the opinions we receive because we hear from all sides of an issue—that’s to be expected and really the core design challenge. We also receive feedback where we thought something was straight forward or would work fine, but in practice needed some tuning and refinement. Over the next weeks we’ll be blogging about some of these specific changes to the product. These changes are part of the process and part of the time we have scheduled between Beta and RC.

So right now, every day we are researching issues, resolving them, and making sure those resolutions did not cause regressions (in performance, behavior, compatibility, or reliability). The path to Release Candidate is all about getting the product to a known and shippable state both from an internal and external (Beta usage and partner ecosystem readiness) standpoint.

We will then provide the Release Candidate as a refresh for the Beta. We expect, based on our experience with the Beta, a broad set of folks to be pretty interested in trying it out.

With the RC, this process of feedback based on telemetry then repeats itself. However at this milestone we will be very selective about what changes we make between the Release Candidate and the final product, and very clear in communicating them. We will act on the most critical issues. The point of the Release Candidate is to make sure everyone is ready for the release and that there is time between the Release Candidate and our release to PC makers and manufacturing to validate all the work that has gone on since the pre-Beta. Again, we expect very few changes to the code. We often “joke” that this is the point of lowest productivity for the development team because we all come to work focused on the product but we write almost no code. That’s the way it has to be—the ship is on the launch pad and all the tools are put away in the toolbox to be used only in case of the most critical issues.

As stated up front, this is a partnership and the main thing going on during this phase of the project is really about ecosystem readiness. PC makers, software vendors, hardware makers all have their own lead times. The time to prepare new products, new configurations, software updates, and all the collateral that goes with that means that Windows 7 cannot hit the streets (so to speak) until everyone has time to be ready together. Think of all those web sites, download pages, how-to articles, training materials, and peripheral packages that need to be created—this takes time and knowing that the Release Candidate is the final code that we’re all testing out in the open is reassuring for the ecosystem. Our goal is that by being deliberate, predictable, and reliable, the full PC experience is available to customers.

We also continue to build out our compatibility lists, starting with logo products, so that our http://www.microsoft.com/windows/compatibility site is a good resource for people starting with availability. All of these come together with the PC makers creating complete “images” of Windows 7 PCs, including the full software, hardware, and driver loads. This is sort of a rehearsal for the next steps.

At that point the product is ready for release and that’s just what we will do. We might even follow that up with a bit of a celebration!

There’s one extra step which is what we call General Availability or GA. This step is really the time it takes literally to “fill the channel” with Windows PCs that are pre-loaded with Windows 7 and stock the stores (online or in-person) with software. We know many folks would like us to make the RTM software available right away for download, but this release will follow our more established pattern. GA also allows us time to complete the localization and ready Windows for a truly worldwide delivery in a relatively small window of time, a smaller window for Windows 7 than any previous release. It is worth noting that the Release Candidate will continue to function long enough so no one should worry and everyone should feel free to keep running the Release Candidate.

So to summarize briefly:

Pre-Beta – This release at the PDC introduced the developer community to Windows 7 and represents the platform complete release and disclosure of the features.
Beta – This release provided a couple of million folks the opportunity to use feature complete Windows 7 while also providing the telemetry and feedback necessary for us to validate the quality, reliability, compatibility, and experience of Windows 7. As we said, we are working with our partners across the ecosystem to make sure that testing and validation and development of Windows 7-based products begins to enter final phases as we move through the Beta.
Release Candidate (RC) – This release will be Windows 7 as we intend to ship it. We will continue to listen to feedback and telemetry with the focus on addressing only the most critical issues that arise. We will be very clear in communicating any changes that have a visible impact on the product. This release allows the whole ecosystem to reach a known state together and make sure that we are all ready together for the Release to Manufacturing. Once we get to RC, the whole ecosystem is in “dress rehearsal” mode for the next steps.
Release to Manufacturing (RTM) – This release is the final Windows 7 as we intend to make available to PC makers and for retail and volume license products.
General Availability (GA) – This is a business milestone and represents when you can buy Windows 7 pre-installed on PCs or as full packaged product.

The obvious question is that we know the Pre-Beta was October 28, 2008, and the Beta was January 7th, so when is the Release Candidate and RTM? The answer is forthcoming. We are currently evaluating the feedback and telemetry and working to develop a robust schedule that gets us the right level of quality in a predictable manner. Believe me, we know many people want to know more specifics. We’re on a good path and we’re making progress. We are taking a quality-based approach to completing the product and won’t be driven by imposed deadlines. We have internal metrics and milestones and our partners continue to get builds routinely so even when we reach RC, we are doing so together as partners. And it relies, rather significantly, on all of you testing the Beta and our partners who are helping us get to the finish line together.

Shipping Windows, as we hoped this shows, is really an industry-wide partnership. As we talked about in our first post, we’re promising to deliver the best release of Windows we possibly can and that’s our goal. Together, and with a little bit more patience, we’ll achieve that goal.

We continue to be humbled by the response to Windows 7 and are heads down on delivering a product that continues to meet your needs and the needs of our whole industry.

--Steven on behalf of the Windows 7 team

The "Ecosystem"

e7blog — Thu, 18 Sep 2008 10:00:00 GMT

In the emails and comments, there are many topics that are raised and more often than not we see the several facets or positions of the issue. One theme that comes through is a desire expressed by folks to choose what is best for them. I wanted to pick up on the theme of choice since that is such an incredibly important part of how we approach building Windows—choice in all of its forms. This choice is really because Windows is part of an ecosystem, where many people are involved in making many choices about what types of computers, configuration of operating system, and applications/services they create, offer, or use. Windows is about being a great component of the ecosystem and what we are endeavoring to do with Windows 7 is to make sure we do a great job on the ecosystem aspects of building Windows 7.

Ecosystem and choice go hand in hand. When we build Windows we think of a number of key representatives within the ecosystem beyond Windows:

PC makers
Hardware components
Developers
Enthusiasts

Each of these parties has a key role to play in delivering on the PC experience and also in providing an environment where many people can take a PC and provide a tailored and differentiated experience, and where companies can profit by providing unique and differentiated products and services (and choice to consumers). For Windows 7 our goals have been to be clearer in our plans and stronger in our execution such that each can make the most of these opportunities building on Windows.

PC Makers (OEMs) are a key integration point for many aspects of the ecosystem. They buy and integrate hardware components and pre-install software applications. They work with retailers on delivering PCs and so on. The choices they provide in form factors for PCs and industrial design are something we all value tremendously as individuals. We have recently seen an explosion in the arrival of lower cost laptops and laptops that are ultra thin. Each has unique combinations of features and benefits. The choice to consumers, while sometimes almost overwhelming, allows for an unrivaled richness. For Windows 7 we have been working with OEMs very closely since the earliest days of the project to develop a much more shared view of how to deliver a great experience to customers. Together we have been sharing views on ways to provide differentiated PC experiences, customer feedback on pre-loaded software, and partnering on the end-to-end measurement of the performance of new PCs on key metrics such as boot and shutdown.

Hardware components include everything from the CPU through the “core” peripherals of i/o to add-on components. The array of hardware devices supported by Windows through the great work of independent hardware vendors (IHVs) is unmatched. Since Windows 95 and the introduction of plug-and-play we have continued to work to improve the experience of obtaining a new device and having it work by just plugging it in—something that also makes it possible to experience OS enhancements independent of releases of Windows. This is an area where some express that we should just support fewer devices that are guaranteed to work. Yet the very presence of choice and ever-improving hardware depends on the ability of IHVs to provide what they consider differentiated experiences on Windows, often independent of a specific release of Windows. The device driver model is the core technology that Microsoft delivers in Windows to enable this work. For Windows 7 we have committed to further stabilization of the driver model and to pull forward the work done for Windows Vista so it seamlessly applies to Windows 7. Drivers are a place where IHVs express their differentiated experience so the breadth of choice and opportunity is super important. I think it is fair to say that most of us desire the experience where a “clean install” of Windows 7 will “just work” and seamlessly obtain drivers from Windows Update when needed. Today with most modern PCs this is something that does “just work” and it is a far cry from even a few years ago. As with OEMs we have also been working with our IHV partners for quite some time. At WinHEC we have a chance to show the advances in Windows 7 around devices and the hardware ecosystem.

Developers write the software for Windows. Just as with the hardware ecosystem, the software ecosystem supports a vast array of folks building for the Windows platform. Developers have always occupied a special place in the collective heart of Microsoft given our company roots in providing programming languages. Each release of Windows offers new APIs and system services for developers to use to build the software they want to build. There are two key challenges we face in building Windows 7. First, we want to make sure that programs that run on Windows Vista continue to run on Windows 7. That’s a commitment we have made from the start of the project. As we all know this is perhaps the most critical aspect of delivering a new operating system in terms of compatibility. Sometimes we don’t do everything we can do and each release we look at how we can test and verify a broader set of software before we release. Beta tests help for sure but lack the systematic rigor we require. The telemetry we have improved in each release of Windows is a key aspect. But sometimes we aren’t compatible and then this telemetry allows us to diagnose and address post-release the issue. If you’ve seen an application failure and were connected to the internet there’s a good chance you got a message suggesting that an update is available. We know we need to close the loop more here. We also have to get better at the tools and practices Windows developers have available to them to avoid getting into these situations—at the other end of all this is one customer and bouncing between the ISV and Microsoft is not the best solution.

Our second challenge is in providing new APIs for developers that help them to deliver new functionality for their applications while at the same time provide enough value that there is a desire to spend schedule time using these APIs. Internally we often talk about “big” advances in the GUI overall (such as the clipboard or ability to easily print without developing an application specific driver model). Today functionality such as networking and graphics play vital roles in application development. We’ve talked about a new capability which is the delivery of touch capabilities in Windows 7. We’ve been very clear about our view that 64-bit is a place for developers to spend their energy as that is a transition well underway and a place where we are clearly focused.

Enthusiasts represent a key enabler of the ecosystem, and almost always the one that works for the joy of contributing. As a reader of this blog there’s a good chance you represent this part of the ecosystem—even if we work in the industry we also are “fans” of the industry. There are many aspects to a Windows release that need to appeal the enthusiasts. For example, many of us are the first line of configuration and integration for our family, friends, and neighbors. I know I spent part of Saturday setting up a new wireless network for a school teacher/friend of mine and I’m sure many of you do the same. Enthusiasts are also the most hardcore about wanting choice and control of their PCs. It is enthusiasts sites/magazines that have started to review new PCs based on the pre-installed software load and how “clean” that load is. It is enthusiasts that push the limits on new hardware such as gaming graphics. It is enthusiasts who are embracing 64-bit Windows and pushing Microsoft to make sure the ecosystem is 64-bit ready for Windows 7 (we’re pushing of course). I think of enthusiasts as the common thread running through the entire ecosystem, participating at each phase and with each segment. This blog is a chance to share with enthusiasts the ins and outs of all the choices we have to make to build Windows 7.

There are several other participants in the ecosystem that are equally important as integration points. The system builders and VARs provide PCs, software, and service for small and medium businesses around the world. Many of the readers of this blog, based on the email I have received, represent this part of the ecosystem. In many countries the retailers serve as this integration point for the individual consumer. For large enterprise customers the IT professionals require the most customization and management of a large number of PCs. Their needs are very demanding and unique across organizations.

Some have said that the an ecosystem is not the best approach that we could do a much better job for customers if we reduce the “surface area” of Windows and support fewer devices, fewer PCs, fewer applications, and less of Windows’ past or legacy. Judging by the variety of views we've seen I think folks desire a lot of choice (just in terms of DPI and monitor size). Some might say that from an engineering view less surface area is an easier engineering problem (it is by definition), but in reality such a view would result in a radical and ever-shrinking reduction in the choices available for consumers. The reality is engineering is about putting constraints in place and those constraints can also be viewed as assets, which is how we view the breadth of devices, applications, and “history” of Windows. The ecosystem for PCs depends on opportunities for many people to try out many ideas and to explore ideas that might seem a bit crazy early on and then become mainstream down the road. With Windows 7 we are renewing our efforts at readying the ecosystem while also building upon the work done by everyone for Windows Vista.

The ecosystem is a pretty significant in both the depth and breadth of the parties involved. I thought for the purposes of our dialog on this blog it is worth highlighting this up front. There are always engineering impacts to balancing the needs each of the aspects of the ecosystem. Optimizing entirely along one dimension sometimes seems right in the short term, but over any period of time is a risky practice as the benefits of a stable platform that allows for differentiation is something that seems to benefit many.

With Windows 7 we committed up front to doing a better job as part of the PC ecosystem.

Does this post reflect your view of the ecosystem? How could we better describe all those involved in helping to make the PC experience amazing for everyone?

--Steven

Product Planning for Windows...where does your feedback really go?

e7blog — Wed, 03 Sep 2008 03:08:00 GMT

Ed. Note: Allow me to introduce Mike Angiulo who leads the Windows PC Ecosystem and Planning team. Mike’s team works closely with all of our hardware and software partners and leads the engineering team's product planning and research efforts for each new version of Windows. --Steven

In Windows we have a wide variety of mechanisms to learn about our customers and marketplace which all play roles in helping us decide what we build. From the individual questions that our engineers will answer at WinHEC and PDC to the millions of records in our telemetry systems we have tools for answering almost every kind of question around what you want us to build in Windows and how well it’s all working. Listening to all of these voices together and building a coherent plan for an entire operating system release is quite a challenge – it can feel like taking a pizza order for a billion of your closest friends!

It should come as no surprise that in order to have a learning organization we need to have an organization that is dedicated to learning. This is led by our Product Planning team, a group of a couple dozen engineers that is both organized and sits with the program managers, developers and testers in the feature teams. They work throughout the product cycle to ensure that our vision is compelling and based on a deep understanding of our customer environment and is balanced with the business realities and competitive pressures that are in constant flux. Over the last two years we’ve had a team of dozens of professional researchers fielding surveys, listening to focus groups, and analyzing telemetry and product usage data leading up to the vision and during the development of Windows 7 – and we’re not done yet. From our independently run marketing research to reading your feedback on this blog we will continue to refine our product and the way we talk about it to customers and partners alike. That doesn’t mean that every wish goes answered! One of the hardest jobs of planning is in turning all of this data into actionable plans for development. There are three tough tradeoffs that we have been making recently.

First there is what I think of as the ‘taste test challenge.’ Over thirty years ago this meme was introduced in a famous war between two colas. Remember New Coke? It was the result of overemphasizing the very initial response to a product versus longer term customer satisfaction. We face this kind of challenge all the time with Windows – how do we balance the need for the product to be approachable with the need for the product to perform throughout its lifecycle? Do you want something that just boots as fast as it can or something that helps you get started? Of course we can take this to either extreme and you can say we have – we went from c:\ to Microsoft Bob in only a matter of a decade. Finding the balance between a product that is fresh and clean out of the box and continues to perform over time is a continual balance. We have ethnographers who gather research that in some cases starts even before the point of purchase and continues for months with periodic visits to learn how initial impressions morph into usage patterns over the entire lifecycle of our products.

Second we’re always looking out for missing the ‘trees for the forest.’ By this I mean finding the appropriate balance between aggregate and individual user data. A classic argument around PCs has always been that a limited subset of actions comprises a large percentage of the use case. The resulting argument is that a limited function device would be a simpler and more satisfying experience for a large percentage of customers! Of course this can be shown to be flawed in both the short term and the long term. Over the long term this ‘common use case’ has changed from typing & printing to consuming and burning CDs and gaming to browsing and will continue to evolve. Even in the short term we have studied the usage of thousands of machines (from users who opt-in of course) and know that while many of the common usage patterns are in fact common, that nearly every single machine we’ve ever studied had one or more unique applications in use that other machines didn’t share! This long tail phenomena is very important because if we designed for the “general case” we’d end up satisfying nobody. This tradeoff between choice and complexity is one that benefits directly from a rigorous approach to studying usage of both the collective and individual and not losing sight of either.

Third is all about timing. Timing is everything. We have an ongoing process for learning in a very dynamic market – one that is directly influenced by what we build. The ultimate goal is to deliver the ultimate in software & hardware experiences to customers – the right products at the right time. We’ve seen what happens if we wait too long to release software support for a new category (we should have done a better job with an earlier Bluetooth pairing standard experience) and what also happens when we ship software that the rest of the ecosystem isn’t ready for yet. This problem has the dimension of working to evangelize technologies that we know are coming, track competing standards, watch user scenarios evolve and try to coordinate our software support at the same time. To call it a moving target isn’t saying enough! It does though explain why we’re constantly taking feedback, even after any given version of Windows is done.

These three explicit tradeoffs always make for lively conversation – just look at the comments on this blog to date! Of course being responsive to these articulated needs is a must in a market as dynamic and challenging as ours. At the same time we have to make the biggest tradeoff of them all – balancing what you’re asking for today with what we think you’ll be asking for tomorrow. That’s the challenge of defining unarticulated needs. All technology industries face this tradeoff whether you call it the need to innovate vs. fix or subscribe to the S curve notion of discontinuities. Why would two successful auto companies, both listening to the same market input, release the first commercial Hummer and first hybrid Prius in the same year? It wasn’t that 1998 was that confusing, it was that the short term market demands and the long term market needs weren’t obviously aligned. Both forces were visible but readily dismissed – the need for increased off road capacity to negotiate the crowded suburban mall parking lots and the impending environmental implosion being predicted on college campuses throughout the world. We face balancing acts like this all the time. How do we deliver backwards compatibility and future capability one release at a time? Will the trend towards 64 bit be driven by application scenarios or by 4GB machines selling at retail?

We have input on key tradeoffs. We have a position on future trends. That’s usually enough to get started on the next version of the product and we stay connected with customers and partners during throughout development to keep our planning consistent with our initial direction but isn’t enough to know we’re ready to ship. Really being done has always required some post engineering feedback phase whether it’s a Community Technical Preview, Technology Adoption Program or a traditional public Beta. The origin of Beta testing and even the current definition of the term aren’t clear. Some products now seem to be in Beta forever! We work to find the best possible timing for sharing the product and gathering final feedback. If we release it too early it’s usually not in any shape to evaluate, especially with respect to performance, security, compatibility and other critical fundamentals. If we release too late we can’t actually take any of the feedback you give us, and I can’t think of a worse recipe for customer satisfaction than to ask for feedback which gets systematically ignored. I was just looking at another software “feedback” site where a bunch of the comments just asked the company to “please read this site!” For Windows 7 we’re going to deliver a Beta that is good enough to experience and leaves us enough time to address areas where we need more refinement. This blog will be an important part of the process because it will provide enough explanation and content and guidance to help you understand the remaining degrees of freedom, some of the core assumptions that went into each area and will structure our dialogue so that we can listen and respond to as much feedback as you’re willing to give. Some of this will result in bugs that get fixed, some will result in bugs in drivers or applications that we help our partners fix. And of course sometimes we’ll just end up with healthy debate – but even in this case we will be talking, we will respond to constructive comments, bugs and ideas and we will both be starting that conversation with more context than ever. So please do keep your comments coming. Please participate in the Customer Experience Improvement program. Give us feedback at WinHEC and PDC and in the newgroups and forums – we’re listening!

Thanks,

- Mike

Measuring the scale of a release

e7blog — Wed, 20 Aug 2008 10:00:00 GMT

Thanks for all the feedback that we have been getting. That much of it is positive is certainly appreciated. I’ve been answering mails as best I can and along with members of the team we’ve been having the discussion in the comments. Everyone has done a great job sharing their views on specifics, wishes, and requests. I love getting these mails and reading the comments. It is fantastic. I just want to make sure folks know I can’t answer each one! What we are going to do is look to the emails and comments as a way of suggesting posts we should write. The team overall appreciate the warm reception from all those that have joined us--we know we have lots of energetic discussions ahead of us and we're genuinely happy to start.

With this post, I am hoping to continue the dialog on the way we think “inside the Win7 team” so to speak—in a sense this is about expanding the team a bit and bringing you into some more of the discussions we have about planning a release. This conversation about major or minor releases is very much like the one I have with my boss as we start planning :-)

When we started planning the release, the first thing some might think we have to decide is if Windows 7 (client) would be a “major release” or not. I put that in quotes because it turns out this isn’t really something you decide nor is it something with a single answer. The magnitude of a release is as much about your perspective on the features as it is about the features themselves. One could even ask if being declared a major release is a compliment or not. As engineers planning a product we decide up front the percentage of our development team will that work on the release and the extent of our schedule—with the result in hand customers each decide for themselves if the release is “major”, though of course we like to have an opinion. On the server blog we talked about the schedule and we shared our opinion of the scale of the releases of Windows 7 client and server.

Our goal is about building an awesome release of Windows 7.

Across all customers, there is always a view that a major release is one that has features that are really the ones for me. A minor release is one that doesn’t have anything for me. It should then be pretty easy to plan a major release—just make sure it exactly the right features for everyone (and given the focus on performance, it can’t have any extra features, even if other people want them)! As engineers we all know such a design process is really impossible, especially because more often than not any two customers can be found to want exactly opposite features. In fact as I type this I received sequential emails one saying “[N]obody cares about touch screen nonsense” and the other saying “[Win7 needs] more advanced/robust ‘touch’ features”. When you just get unstructured and unsolicited input you see these opposites quite a bit. I’m sure folks are noticing this on the blog comments as well.

Let’s explore the spectrum of release magnitude across a couple of (but not all) different types of customers: end-users, developers, partners, IT professionals, and influentials.

End-users are generally the most straight-forward in terms of deciding how big a release is going to be. For an end-user a release is a big deal if they want to go out and buy an upgrade or buy a new PC. We could call that a major release. Seems simple enough and a major release is good for everyone. On the other hand, one could also imagine that a release is really cool and people want to buy it, but they also want to use their existing PC and the release requires more memory, updated drivers that might not be available, or maybe some specific hardware to be fully realized. Then it seems that a major release goes from a positive to a bit of an under-taking and thus loses some of its luster. Of course we all know that what folks really want is all the things they want that runs on the hardware they want—then that is a great product to get (whether it is major or not).

Developers look at a release through a different lens. Obviously for developers a release is a major one if there are new APIs and capabilities to take advantage of in their software—again straight-forward enough. It could also be the case that a previous release had a lot of new APIs and folks are just getting familiar with using them and so what they really want is to round out the APIs and maybe improve performance. So one might suspect that the first release is a major release and the second type is a minor release. But if you look at the history of software products, it is often these “minor” releases that themselves become the major releases – Windows 3.1, Office 4.2, or even Windows XP SP2. In each of these cases, the target for developers became the “minor” release but in the eyes of the market that was the “major” release. The reason developers want to use new APIs is to differentiate their products or focus their energies on domain expertise they bring to the table, not just call new APIs for the sake of calling them. In that sense, a release might be a major one if it just happens to free up enough time for an ISV that they bet on the new APIs because they can focus on some things that are a major deal to them.

Partners represent the broad set of folks who create PCs, hardware, and the infrastructure we think of as the ecosystem that Windows is part of. Partners tend to think about a major release in terms of the opportunity it creates and thus a major release might be one with a lot of change and thus it affords the opportunity to provide new hardware and infrastructure to customers. On the other hand, incompatibilities with the past might be viewed in a less than positive light if it means a partner needs to stop moving forward and revisit past work to bring it up to the required compatibility with a new release of Windows. If they choose, for any number of reasons, not to do that work then the release might be viewed as a minor one because of the lack of ecosystem support. So again we see that a big change can be viewed through the lens of a major or a minor release.

IT professionals are often characterized as conservative by nature and thus take a conservative view of change. Due to the business focused nature of the role, the evaluation of any software product is going to take place in the context of a return on investment. So for an IT professional a major release would be one that delivers significant business value. This business value could be defined as a major investment in deployment and management of the software for example. Yet for end-users or developers, these very same features might not even be interesting let alone worthy of being a major or minor release.

Influentials are all the folks who are in the business of providing advice, analysis, and viewpoints on the software we make. These folks often look at releases through the metric of “change”. Big changes equal major release. A big change can be a “re-architecture” as we saw in the transition from Windows 9x to Windows 2000—even though these products looked the same there was tons of change to talk about under the hood. So for reviewers and analysts it was definitely a major release. Big changes can also be big changes in the user-interface because that drives lots of discussion and it is easy to show all the change. Yet for each of these, this definition of major can also be viewed as a less than positive attribute. Re-architecture means potential incompatibilities. New user-interface can mean learning and moving from the familiar.

We’ve seen a lot of comments and I have gotten a lot of email talking about re-architecting Windows as a symbol of a major release. We’ve also gotten a lot of feedback about how a major release is one that breaks with supporting the past. If I could generalize, folks are usually implying that if we do things like that then a number of other major benefits will follow—re-architecting leads to better performance, breaking with the past leads to using less memory. It is always tricky to debate those points because we are comparing a known state to a state where we fix all the things we know to fix, but we don’t yet know what we might introduce, break, or otherwise not fix. So rather than define a major release relative to the implementation, I think it makes sense define the success of the release relative to the benefits of whatever implementation is chosen. We will definitely continue to pick up on this part of the discussion--there's a lot of dialog to have.

The key is always a balance. We can have big changes for all customers if we prepare all the necessary folks to work through the change. We can have small changes have a big impact if they are the right changes at the right time, and those will get recorded over time as a major release.

We’ve talked about the timing and the way we structure the team, so you have a sense for the “inputs” into the project. If we listened well and focused our efforts correctly, then each type of customers will find things that make the product worthwhile. And if we do our job at effectively communicating the product, then even the things that could be “problems” are seen in the broader context of an ecosystem where everyone collectively benefits when a few people benefit significantly.

From our perspective, we dedicated our full engineering team and a significant schedule to building the Windows 7 client OS. That makes it a major undertaking by any definition. We intend for Windows 7 to be an awesome release.

I hope this helped to see that perspective is everything when it comes to deciding how big a release is for each type of customer.

--Steven