Release timing and Office products -- how fast is fast enough?

I've been asked quite a bit by people interviewing at Microsoft about "software release". This post will talk about our strategy around product releases for Office products, since we have been pretty consistent over the years and this represents a balance between some competing interests.

The topic comes up because there has been a lot of web discussion and press about products at Microsoft that have taken a long time between major releases. This post is about the way we structure releases of Office. In the big picture, one of the things that is a hardcore Microsoft "value" is that we learn from our past experiences and work hard not to repeat things in the future. An article on this can be found in the WSJ which talks about some of the introspection we have done and more importantly some of the mid-course changes we have made within some of the teams at Microsoft. 

If you work on Office, you are using software that people use everyday to do work that is really important to them--lots of money, important decisions, and grades rely on Office working well. There is clearly a lot going on in the industry and a lot of "2.0" discussions, and Office plays a big role in bringing those to the broad base of customers in their productivity tools. It is also the case that we have to make sure that Office works extremely well--once a customer makes a bet on Office we owe them a very strong level of commitment and service. That is decidedly different than many of the new products and services that are out there. If you lose work in Office or can't get something done quickly in Office, the cost is much higher and your alternatives at the moment fewer than many of the other types of products out there today. We take this responsibility seriously and it also makes for a unique experience working on our products. If you've been tracking the Office12 blogs (linked to on this site) you can see the comments from folks that do rely on Office and the emotion around the software.

The first thing to realize is that with products like Office there is a whole product lifecycle to consider. Often people think of the big bang release and talk about that, but in reality for Office there are five different releases going on all the time:

Office product wave. Of course the thing that captures the most attention (when done right, the other developments just work and don't cause any stir) is the new release of Office. Since Office 2000 we have focused on delivering most all of the Office products at the same time--so of course Word, Excel, PowerPoint, Outlook, Access, but also Project, FrontPage, and now Visio, OneNote, InfoPath, as well as all of our server products. We have found that releasing the products all at once allows us to develop rich scenarios that cross products (such as Project integration with Excel for analysis and SharePoint for the server). Customers, particularly at the enterprise level, definitely strive for a 1+1=3 solution and see the benefits of a broad set of products designed to work together. Of course we also work to insure that we deliver the best components as well. 

Immediate updates to software. These are done on short notice and represent issues with the software that must be addressed "yesterday". These can be quality issues, potential security issues, or exploited security issues. These are very small in number (we have had 3 of these in Office 2003 since it released in November 2003). 

Customer driven updates. For corporate customers, developers, or other software vendors we have in-depth support relationships that offer these parties support professionals to help troubleshoot and diagnose issues they might be having with our products. These can result in an "escalation" to the product team if the customer or support professional believe that the product is not meeting the needs, not operating as specifying, or is just broken. We actually see hundreds of escalations in a month. Most of the time these are properly handled by using an alternate way to accomplish the task or by changing some deployment characteristics. Other times a product change is warranted. These changes can be small code changes, significant UI changes, or new features. Any change we make to the product this way will be made available to 100% of customers around the world so we do make sure that these are in the best interests of the broadest set of customers. In a given month we might do 100 fixes along these lines--that's over 100 changes to Office every month. 

Broadly available Service Packs. About every 8-12 months we release a "service pack" for a product. Along with all the customer driven updates, we also address the crashes and hangs that we see being reported by our "Watson" tools. We get millions (and millions) of reports of these issues from customers and we constantly look at this data to make sure we understand how Office is functioning in "real world usage". If we see a spike we jump on that right away and perhaps this might call for a critical update (we did this with Office 2003 early in the product cycle). This "instrumentation" (which is anonymous, private, and opt-in) has radically redefined the way we can improve the quality of Office. In the past these issues would linger and we would never know which ones to fix or how to reproduce them. Since Office XP we have been whittling down these errors in the product and have radically improved the overall robustness of Office based on metrics like "mean time to fail" (tracked with this same mechanism). So these service packs offer a big improvement to the overall product quality and allow customers to get all the updates we have done during the previous months. For a given release over the lifetime we will generally do 3 service packs. Generally speaking it is worth noting that we support a release of Office for 10 years from RTM. This is a big commitment we make to customers and it means that at any given time we are fully supporting 3 different versions of Office, because customers expect that from us and it is an important part of why they rely on our products.

Continuously improving OfficeOnline. One element of the Office products is our OfficeOnline web site. This is not just another product information web site, but an integral part of the product's experience. OfficeOnline does contain pre-sales information, but it also contains a vast amount of content designed to help make using the product better, learning the product easier, and maintaining the product as an admin much more efficient. You can access OfficeOnline through a browser, but you can also access it by just using File New and using templates, or Insert ClipArt and using web-based clipart, or just by typing a question into the help "box" at the top right of an Office window. As with other web sites, these queries and usage patterns drive site "programming". One of the biggest things we do is respond in near real time to the questions and problems customers are having use Office. This not only causes us to write new articles, tutorials, online courses, etc. but we also look to see how people rated the articles and then go back and fix those. We are constantly scoring these articles and looking to improve them based on real world feedback and also add new articles based on current problems. Of course just like your favorite shopping sites, we offer timely templates, clipart, and other content -- at Valentines in the US we have lots of hearts, at Tax time we offer tax spreadsheets, etc. And by the way, all of this is done globally and in a locale specific way.   

So that is a rough look at the "velocity" of change of the Office products. For the product that is in market you can think of this graphically as the following shows. In this picture I've made the length of this the rough average for time between product waves (more on that below):

Is this fast enough? Or is this too fast? Good question! The answer really depends on the circumstances and how you measure success. 

Let's take this question to really be one about the major releases. I've heard a lot of people say that major releases are a thing of the past and that what is "new" today is that software should be released "continuously". Continuously is a lot of software for people to absorb. For some things this works well--I love that shopping web sites have all the newest products all the time for example, and of course I love that we are constantly adding new clipart and templates to OfficeOnline. But for other things even ones that are traditionally continuous, new things all the time can be a chore--for example I love reading The Economist, and it comes with a lot of new stuff all the time and I can't absorb it at the pace they can deliver it. For engineering and manufacturing products, like cars, what seems to have worked for a long time is a big new product followed by subsequent iterative improvements (Toyota famously squeezed that cycle time down to 3+ years rather than the traditional 5-7 years US companies used, but the concept remained). Some would say software is different and some might even say that software on a server is even more different. There is no doubt that technically software is easier to change, but what do customers want, expect, need? It isn't obvious and like so many things we have talked about the answer is "it depends".

Before we look at the choices, here is the history of Office products since Office 97 (taken from

For Office, some customers are very conservative, or even extremely conservative. They say that Office has no big improvements left or that the cost of deploying and updating is high enough that the product should be updated infrequently, perhaps every 6 or 7 years. I happen to think this is extreme but we do hear this quite a bit (though I would also say these same customers are quick to request their favorite features and say they would like those right away). Other customers, perhaps the trade press or magazines that write about Office, might like this to be more frequent because they can generate more of their business with a big new product to talk about and they might like something very frequently about every 6 months or so. I think that the best place is somewhere in the middle of course. And keep in mind that throughout the talk of the release, we are updating the product as described above--we're not "dark" but always improving things for our customers. What we have found works for Office is about 24-30 months between releases, or so. We've done that pretty much for the history of Windows releases. Sometimes we are a bit shorter, and sometimes a bit longer (the average since Office 97 is 28 months--you can see this on

Another constituency in this discussion is the marketplace in terms of how and when they can take the time to understand what is in the product, and how they will adapt to using the product. In this case, I would think again about the Economist. But instead of thinking about the new content, think about what it is like when they change the layout of the magazine. This is a major deal (like once every 10 years). But it actually has an impact on you and you need to adjust. Imagine if this happened every 6 months! That would be more than you could absorb and they would spend a lot of pages explaining the change and you'd probably get frustrated. I'm sure you have experienced web sites like this--you feel like your hand knows where to click and then after a few months things move around. So even if you have a web-service based product you need to consider that people need to adjust and learn and once you have a lot of customers/users you can't change things with a very high velocity or you might alienate people. The changes probably are better being bunched up and delivering as a "theme" around a set of changes. This is how the magazine views a new layout and how a car company views a new model. It turns out this is great for the people that market a product as well--having a small, but frequent, set of changes is a rather significant marketing challenge. But having a broad set of changes with a theme allows the marketing people to more effectively communicate the product. Trying to raise awareness of a single new feature can also come across as artificial--if you're trying to read your mail do you really want banner ads for new features to manage your email? While the context is right, it seems a bit distracting. We tried that in Word 6.0 with the "tip of the day" :-)

Office has an extra challenge in that the set of features have to apply to a lot of different types of customers--end users, IT pros, developers, business people, and of course all the industry folks like the press, analysts, etc. (many of whom are also end-users). This means that you have to consider in each release how to offer those customers features they might want. It means for example that each release of Office has features for a broad set of constituencies. There aren't a lot of other types of products that have to meet this test--it comes from the breadth of the customer base of the product I think. It means that it might not be a good plan to offer just a few targeted features for developers, because you won't get any end-user demand. Or even though a few end-user features might make for a good article in a PC magazine, you won't get a lot of support from the IT Pros that have to deploy and support the product. 

One of the biggest challenges in product design is what to do when you have a "hit" feature that everyone wants, or a feature you think will be so hot that everyone will want it. Most of the time you figure this out only after you are done developing it and get feedback. I have a first generation Toyota Prius and as soon as I sat in it the first time I knew that the gear shifter was a design mess. When the next model came out they changed that and boy did I wish I could just take that gear shifter and move it to my car--but no such luck I had to get a new car (I didn't. Software is a lot like that -- you see a new release and you just want one thing and wish you could get that on your machine without paying for a new product or "upgrading" (like when PhotoShop finally added RAW support and I didn't need all the other stuff in CS). The challenge we face with Office is that nearly every feature is used by the whole universe of people, and so by definition there exists a set of people who would want that one single new feature and nothing else (see Jensen's blog on the new UI for frequency of command comments). More than anything, I hear this from individuals talking about specific features they would like. Even more interesting is trying to think if we could somehow communicate and market a release based on some of these "nuggets" because more often than not this would be really hard. Sometimes you get amazing nuggets like red squiggles for spelling in Word, or AutoCorrect teh->the. But those are the big home runs of features in their area and don't happen all that much, and of course when we were doing them it was not always universally agreed that they would be such a hit (AutoCorrect in particular). It is important to separate the ability to release things and the market desire for those things. Of course we release hundreds of changes as described above, but trying to communicate these is a huge challenge because they are not part of a larger whole and are about "customer service".

Professor Iansiti at Harvard once told me that he thinks of "innovation" as really an equation: innovation = invention + impact. In other words, it isn't enough to just invent something cool, but you have to have an impact as well. A big part of having an impact is getting the word out on what you do and making sure people ultimately use and benefit from the work. The timing of a release has a lot to do with the impact. Too fast, and you pass people by or frustrate them in their ability to absorb the change. Too slow and you miss the opportunity or circumstances change and your invention is no longer relevant or inventive. It is a fine balance. Often only hindsight is 20/20.

Finally I would also say that as a new member of our team, the ability to participate in all of these offers you a chance to really experience the breadth of software engineering. You definitely hit the ground running and you'll want to contribute soon. But you also have the time to learn and the time to gain experience in our industry--you won't have to release your first code as a critical update (that takes a lot of experience) but at the same time you probably will end up waiting less than a year before your first projects see release, and less if you count pre-releases.

This is where we are today. Things change a lot over time and nothing about what I said above is written in stone. We build our products for customers and we listen carefully. If there is a sea change in how customers want their software delivered or what time frame we should deliver software then we will of course change--without customers liking what we're doing we're definitely way off course.