A grass roots campaign has been started by Peter Provost to get Microsoft to include unit testing support included with all versions of Visual Studio 2005 (VS). Currently, Microsoft is only including it with Visual Studio Team System (VSTS) versions of Visual Studio. This looks to be a great example of a killer feature in a product providing so much surprise and delight that people are demanding that it be universally available. This is also a great example of market segmentation by Microsoft. The irony is that there is an open source alternative that makes the opportunity cost very low, and yet people are still clamoring. Let’s see why.
Background
Visual Studio 2005 is a development environment for developing .NET applications. Microsoft offers several versions of the software – 8 in the 2005 packaging. Even for people familiar with the product, the market segmentation strategy can be pretty confusing. To oversimplify, each version offers more capability than the less-expensive version below it. Rob Caron provides the best explanation of the product definition strategy in his Hitchhiker’s guide to VSTS. He starts by explaining the Visual Studio 2003 packages, and then shows the evolution to the VS2005 appraoch, including the Team System versions.
Unit testing support is offered only in the four most expensive, most capable versions – the Team System versions. The petitioners argue that unit testing is critical to all developers, and should be included in every version of the product. Unit testing is a form of whitebox testing where developers create automated tests of their code.
Microsoft is implementing a classic market segmentation strategy with this approach.
Market Segments
Markets are not homogenous – we don’t sell products to clones. Everyone has a different set of criteria for purchasing software. They make different tradeoffs in terms of price versus performance, or cost versus capability. Imagine a market roughly divided into two populations – price sensitive people, and feature-driven people.
The price-sensitive people like getting extra features, but will only pay marginally more for them. The feature-driven population is willing to pay a higher premium for added capabilities.
If we treat our potential customers as a homogenous market, we will make one of three mistakes:
- Price the product so that everyone buys it. If we set the price based on the price-sensitive population, we are leaving money on the table. The feature-driven people would gladly pay more for the features.
- Price the product so that only feature-driven people will buy it. We lose out on sales to the price-sensitive population, who won’t pay for the extra capabilities.
- Try and compromise. Nobody wins. We won’t get enough of the price-sensitive customers, and we’ll leave money on the table with the feature-driven customers.
The Good, The Better, and The Best
One way to serve all of the customers is with multiple products. As an example, imagine three versions of a washing machine. They all basically do the same thing, wash clothes. The manufacturers can put a stronger motor, fancier control panel, or better sound insulation on some versions of the same product, and sell them to different people for different prices.
Most of the engineering costs apply to all three versions of the same product. The same is even more applicable to software. An easy way to do it would be to write the “best” software, and then disable some features to create the “better” and “good” versions. Many small software companies do this today, offering free and paid versions of their software. The free versions usually are missing features of the paid versions.
Microsoft has presumably identified several user profiles, and tailored a specific version of the software for each profile. Each version has different capabilities, and a different price.
Product Differentiation
Unit testing support, within the Visual Studio development environment, is absolutely a valuable capability. The growing response to the petition proves it. This is a great example of a surprise and delight feature (in Kano terms). In fact, some users find it to be so compelling that they want all users to get it “for free” as part of purchasing any version of Visual Studio.
This is one way that Microsoft is providing differentiation of the Team System versions of Visual Studio. There are other tools that may provide even more compelling reasons to get the Team System version.
Opportunity Cost
The odd thing is that NUnit is an open-source unit testing tool that can be plugged-in to all versions of Visual Studio. This means that there is a free tool for doing exactly what the petition is asking Microsoft to do. The cost of using NUnit is the time spent setting it up – I would imagine a few hours to figure it out and create an install document for the rest of the team. This is a surprisingly low-cost alternative. And it may even be the better alternative, as NUnit has a very active community, and there are many areas to find free support and help. The opportunity-cost logic applies to this situation (but in reverse). There is a low-cost alternative, so why spend the money on the extra features?
The other capabilities available in Team System provide much better differentiation, as they don’t have low-cost alternatives like NUnit.
Conclusion
This is a great example of using market segmentation to sell more software for more profit. Feature-driven people who want unit testing will pay more for it. People who are more price sensitive will still buy the versions without unit testing baked in, and will hopefully know about NUnit and bolt it on.
Good job Microsoft marketing.
