Microsoft’s Virtual Machine Software - Take 2

About a month ago, in the post What Does it Really Mean if Microsoft’s Virtual Machine Software is Delayed?, I analyzed what would happen if Microsoft delayed the release of its Virtual Machine Software for its new server operating environment. Now, its become clear that Microsoft has chosen to reduce the software's set of features to hit its previously announced release date. My first thought is that the folks over at Microsoft are in a "damned if you do and damned if you don't" position. No matter what they do in such circumstances, someone in the industry is going to complain.

Before launching into an analysis of this event and trying to define the impact on both Microsoft and the industry, I'd like to once again point out that virtual machine software development is every bit as complex as developing general purpose operating systems. In some ways, it is even more difficult. That is to say, its up there with other forms of what the industry terms "rocket science." Microsoft, like most software suppliers, wants to let its customer base know what the Microsoft product roadmap looks like so they can plan their adoption strategy. It's very difficult to balance what should be disclosed with the fact that software development is full of unknowns. Software engineers really don't know how difficult the implementation of some feature is really going to be until they launch in to the project.

Having been a member of product development, management and marketing teams in the past, I understand how difficult it is to get all of the dreams and visions for a product implemented on time and on budget. A key consideration for the team is what to do if the release date is drawing near and if promised features are not really ready (read don't work as expected, have unfortunate side effects, or don't perform well). Here are snippets of the discussion I expect happened around some table in Redmond.

• "Let's go ahead and release the software even though it really isn't ready. We'll need to be prepared for the customer backlash. The product features can be fixed once the product is released."
• "Whoa there, fella, we'd be beaten about the head and shoulders in the media. Let's hold off releasing the software until everything works as promised. We can tell customers that we're helping them by releasing product only when it's really ready."
• "There's another approach that will minimize the beating we'll take in the industry. Let's move features that aren't ready to future releases of the software. We can release what's working today and declare that the product schedule has been met. We'd have to deal with a smaller number of upset customers. We can offer those folks who are really upset access to a "beta test" version of those features and we can keep working on the problems back in the lab."

Do you see what I mean? No matter what choice is made, some customers are going to complain. Furthermore, journalists, analysts and consultants are going to be able to score points by publishing negative articles.

Situational analysis from Microsoft's point of view 

Microsoft knows that it is no longer a startup. It has dominant share of the operating systems market, that is having greater than 50% market share or having twice the share of the next player in a fragmented market. They're also the dominant player in several other markets. If you'd like to know how many markets, ask my former colleagues at IDC. They're really good at tracking market share.

Microsoft also knows that, for all its strength in other markets, it's still not dominant in the area of virtual machine software. Releasing features before they're really ready not only might incur the wrath of customers, it may also result in litigation around the world. In the end, making a move like that isn't going to increase their market share.

The results of releasing things before they're ready will produce results that would be considered "bad" regardless of who is doing the analysis.

This means of the three possible choices mentioned in the scenario presented above, only two of them are really viable. The real choices are to delay the whole product or to delay specific features that aren't ready. Let's examine each of the three choices a bit more closely.

• Release the product as it is, ready or not, and fix problems as they arise. Can you say "let the beatings begin?"
  
  
• Delaying the whole product would allow competitors to build marketing and sales campaigns founded on this delay. These competitors would love to have a chance to present why organizations should select their product now rather than wait for Microsoft. This approach would also have the impact of angering and embarrassing decision-makers who told their organization to wait for Microsoft because they were assured that the new software would both solve problems they were facing and would be available when it was needed. Since IT decision-makers have very long memories and find a way to get even later, this isn't a very good choice.

• Delaying specific features until they're really ready for customer deployment minimizes the "surface area" competitors can attack. It would upset only those decision-makers who have a strong need for the missing features. After all, if these few customers are important enough, Microsoft could offer them a chance to use these features as "beta test software. This just might be the best of three bad choices.

 

Situational analysis from Competitors' point of view 

Any delay of the Microsoft product is a joyful event for Microsoft's competitors. I can hear them cheering now.  I'm sure that they're thankful that Microsoft has given them a longer period of time to increase the shipments and share of their products. This, of course, includes the good folks at Novell, Virtual Iron, VMware, XenSource and others.

 

Situational analysis from Microsoft's customers point of view

As I said in an earlier post, I would think that Microsoft's customers would rather give the company time to "get it right" rather than to rush out a product that won't won't work well. If they have an absolute requirement for some specific feature that didn't make it into this version of Microsoft's product, they can either purchase a product from some other supplier or attempt to negotiate to be part of a "beta test program" in order to get those unreleased features.

Situational analysis from the industry's point of view

The adoption of virtual machine software is not really being hampered by this delay. There are, after all, notable alternatives available. The fact that there's a great deal of noise first about the delay and then about features being pull will only help to educate IT decision-makers about the complexity of this software and help them understand that they really must choose carefully.

Summary

So, is this really cause for a great industry wide outcry? In short, no. Those needing to move forward today can use today's products. Those having an absolute requirement for Microsoft's products can wait, knowing that the final result will be better engineered because it wasn't rushed to market to beat some arbitrary deadline.

I'm thankful to my friends at Microsoft for giving me something interesting for my post.