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.


Comments (25)
  1. PatriotB says:

    It’s interesting to see the products & release dates in a table like that. Am I the only one who thinks Office 2003, released in *November* 03, should have been Office 2004? Or VS 2005 should have been VS 2006? (It’s kinda strange when 2006 products come out before 2005…)

  2. steven_sinofsky says:

    Well I don’t name the products πŸ™‚

    Cars do this all the time — sometimes they want a jump on the next year and sometimes they want to keep the car in teh current year.

    Regardless we support the product for 10 years based on the release date not the name.


  3. Chris Bettin says:

    I think Professor Iansiti could be right about innovation. Especially when the impact is negatively perceived. If you don’t have the right deployment, timing, marketing, or audience then your invention is not going to be a smash hit.

    I always enjoy reading your blog and hope you keep it up!

  4. steven_sinofsky says:

    Thanks for the kind words! I will pass along your comments to Prof. Iansiti as well.

  5. AnOfficeDev says:

    Are you saying we need to have these big monolithic releases since we need to throw lots of features at the user and hope that some of them resonate? Could we change the way we develop, market, and sell the product?

    It would be nice if we built more modularized software and could allow for a new "gear shift" to be popped in.

  6. Fadi says:

    Steven – Very informative post … I work in MS but know nothing about this…It was worth waiting all this time for this post. Hardik, i hope you’re satisfied too.

    AnOfficeDev – Couldn’t understand what you meant by "would be nice if we built more modularized software and could allow for a new "gear shift" to be popped in" Can you clarify in few more words?

  7. Fadi says:

    Steven – Why don’t you call it Office VISTA and benefit from a 2in1 VISTA campaign. From a marketing standpoint, when you are promoting for "VISTA", you’ll be targeting office and windows at the same time thus saving money. Establishing a brand name in the minds of the consumer is very expensive.

    Not to forget that having Office VISTA and Windows VISTA drives the customer to get both of the products at the same time since, when having the same release name, they look complimentary.

  8. steven_sinofsky says:

    Hi there AnOfficeDev — you know if you are on the team, just step outside your office and head about 100′ North and stick your head in my office and ask this question in person. Or maybe today when I drop by the office dev all-hands you can ask this question. I will know it is you and we can make it our secret πŸ™‚

    I think there are two things:

    * Is our software modular?

    * If it was modular, why not release features more "one at a time" rather than in big releases

    I tried to hit the second, but I did assume the first. I think our software is incredibly modular. If fact the modularity is one thing that contributes to the wide variety of uses and the flexibility that customers enjoy. There are a myriad of ways that you can "plug in" to Office at all sorts of different levels. One of my favorites is that you can switch the user-interface language on the fly, or for that matter the help system can be another language, and you can edit any number of languages (there are lots of features that are required for all the different scripts of the world) — all without a recompile, relink, or even touching any executable code.

    The trick with modularity is that often what seems cool and modular turns out not to be the way you want to extend something in 10 years, which is why during our M0 we are always investing in rearchitecting. One example from the "physical" world is what it is like to set up wiring in a house (or in our case a condo). I spent a huge amount of time on wiring — I have a great patch panel and home run. I switched DSL providers and it took 10 seconds to patch in a different demarc line and switch over my network. I wanted to change a fax machine to a third line and it took 5 seconds. But I dread the day we might need a 5th phone line (no chance since we only use 2 today but never say never) since my modular system can’t handle that. Or even worse what if there is a move to fiber–we have some conduit but not to every room. Software is no different — you can make it modular to handle a set of circumstances, and for those it works amazingly well. When I was working on VC++/MFC we had a rule which was not to add extensibility unless we used it ourselves, since that way you could prove you were modular for at least some usage. But still customers found things they couldn’t accomplish. It is amazing the things that can be easily added to Office and done without a lot of work because we have a great architecture. But like any modular system, it is not "infinite" and time introduces new needs and new scenarios to rearchitect for.

    But should we use the modularity we have to do smaller releases? That is not a technical question as much as a sales and marketing question, or more appropriately "would it sell" question, or perhaps a product planning question in terms of up front choices. This one I liken to a movie studio trying to only make hit movies, or an financial manager only picking winning stocks. After all, why waste your time making features that won’t "sell". It just isn’t so simple–I wish I could think of another way to say that. Some might agree and say that is precisely why you should just release smaller brand new things more frequently and get feedback — but then that starts to look a lot like "churn" and a lot less like "customer satisfaction". Even our service packs, which make the product way better need to be spaced out because people don’t like that much change.

    It gets back to "innovation = invention + impact". To have impact something needs to be big and broad. Small improvements are great. A few small improvements might get you a pop. But to really move the needle you need to complete a "scenario" and solve a bigger problem for customers and that takes a lot of invention, some of which won’t pan out. Now in some "new" areas or in some hyper markets there is so much focus on invention that it becomes the currency of the day, even without the impact. I think in a "bubble" environment those in the know focus on invention, even though that many people might not be impacted by it. You see that today with many "2.0" things out there–lots of excitement, but exceedingly small numbers of people are impacted by the work. Maybe some of them will be huge, maybe not. It is tough to know. So that is why VCs have dozens of small companies all trying new things. For that same reason, our releases try to address a broad set of customer problems.

    Now unlike the "go out of business" option for VCs, it turns out that (as Jensen is going through on his blog) even features that one person does not like in Office are still used by a lot of people. A feature used by 0.5% of our customers in a release, still means that perhaps 500,000 people will be using that feature (based on installed base and historic upgrade rates, not including new users). That is a lot of IMPACT!

    So AnOfficeDev, feel free to stop by any time and we can talk more!


  9. Hardik says:

    steven:-sir this is a nice post seems to cover all the long silence in one post πŸ˜‰

    fadi:-yes i really enjoyed reading this blog and jobsblog πŸ™‚ i daily check this two blogs!!!

  10. Fadi says:

    Steven – Can we visit your office too?… or are you practicing discrimination on your blog? πŸ˜‰

  11. EJ says:

    While this is all a very cogent,detailed, and self-contained account of what I am sure is a huge orchestration issue, it begs the meta-question of "what is the true technical innovation in any of the recent or forthcoming Office versions that justifies 4,000 developers working on it?" At $150K/yr per developer, that is an annual cost of $600M; over 3 years that is nearly $2B of cost. Will we see $2B of technical innovation in Office 12? Or would we be better off spending $2B somewhere else?

  12. Fadi says:

    EJ – I like your accurate calculations. You just missed adding the coffee and toilet paper consumption cost.

    150K/year for each developer! Jack Welch makes a 100K!.

    You can’t see $2B in innovation! I can’t either, cause no one can. Innovation can only be seen through the positive impact produced on people and businesses using office around the world. If you can’t see that, go read some case studies on

    You may also need to realize how delicate and serious it is to innovate in a product used by 400,000,000 users around the world.

  13. steven_sinofsky says:

    A perfectly reasonable question from an intellectual point of view, but one that could be asked about any endeavor.

    There are only 700 developers on Office though.

    I think that the only quantitative measures are patents and revenue. I think by both of these we do a very good job justifying our product development investment. The ROI of our investment in building Office is world-leading I believe.

    The positive impact produced by Microsoft Office is pretty incredible. I do wish I could measure it–economists struggle with measuring the economic impact of productivity improvements much more than I ever could. I just stick by what a Wall St. customer once told me — "we make more money from Excel than Microsoft does". That’s innovation and a return on investment.

  14. jumbo says:

    Please don’t make the mistake of VS2005 and ship too early with lots of showstopper bugs. Whoever was in charge of that one really lost the plot.

    It’s a real pain to use, it crashes all the time and it corrupts data mercilessly.

  15. steven_sinofsky says:

    Jumbo, I’m sorry you are having that experience. If you have any specifics you would like to report please mail them to me using the contact form.

  16. Fadi says:

    Steven, do you often interact with Billg during your work?

  17. Doug Mahugh says:

    When considering Office’s development costs, let’s not forget all of the developer-oriented code in Office that end users never see. For example, the new XML formats — huge work to implement, but the average user can’t see a thing. And the new APIs in Office 12 for adding 3rd-party functionality to the ribbon, task pane, and so on — that stuff requires a lot more development work than adding a few bells & whistles to the UI.

    As for whether this investment is the best way Microsoft can spend $2 billion (or whatever the number really is), that’s a hard question to answer with any precision, like any investment decision. It’s clear that people are going to continue using some type of product like Word, Excel, etc, to do their work, whether it’s Office or some competitor on the desktop or the net. And it’s also clear that we (Microsoft) need to figure out how to remain the number one player in that space.

    I’m excited about the developer focus of some of the new features, and how those features will drive ISVs to integrate Office server functionality with their apps to an unprecendented degree. If the investment in Office development can lead to Office being perceived (by developers) as a viable platform for building applications, in addition to its perception as (by end users) as a high-quality productivity suite, then I think we’ll look back on it as a wise move.

  18. Ilana Davidi says:

    Ah, the old "software is easier to change than hardware" argument. We can never tire of that one. =) Your analogy of comparing changing a software product like Office to changing the layout of a magazine rather than the content is a very good one. People who do not work on software can often not understand the concept of infrastructure for something they cannot touch.

    Thanks for another informative and detailed article!

  19. While at Stanford this week I was asked by a number of PM (program manager) candidates to talk about…

  20. Dating says:

    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

  21. Republished from Steven Sinofsky’s PM at Microsoft , TechTalk, Dec 2005 While at Stanford this week I

Comments are closed.

Skip to main content