Tiered software is the answer to feature bloat

If you are an early adopter for Windows Vista, then you are probably bemoaning the fact that I would even consider such a solution to feature bloat. The last time I checked, Vista has five flavors: Ultimate, Home Premium, Home Basic, Business, and Enterprise. Running Windows XP Home Edition suites me well enough, and an upgrade to the professional version is still sitting in my desk drawer. Because of this I will not venture a critique of the Vista OS. Although, I will say that the tiered approach is a sacrificial lamb for techies who simply do not like what Vista has to offer in any version.

There is no shortage of jokes surrounding the average computer user’s confusion with Vista versions, and there is a grain of truth to the criticism regarding the model Microsoft chose. With the proper research and marketing, however, tiered software can actually improve the customer’s purchase experience. This not only includes the initial purchase, but with upgrades as well. As a software engineer, that is a difficult thing to say, because I know that a tiered approach is complicated and full of potential pitfalls.

What OOP was designed to do

One of the mistakes some developers make when considering tiered software, is to simply “turn off” the features that are not available in a lower tier. This can have a significant impact on the customer, depending on the platform, whether or not this is software as services, but especially if the software is downloadable and upgradeable. When I hear this approach discussed in development circles, it typically applies to legacy software that would be difficult to retrofit appropriately. This is perceivable, but in regards to software that has yet to be built, it is unintelligible.

The fundamental concepts behind a design paradigm such as objected oriented programming are intended to help solve problems like tiered software. Inheritance is the primary ingredient of OOP that allows entire object libraries to be left out of the build process. A utility class that provides functionality across an entire application might be essential to support features in several tiers, but with the right preparation, this should be the exception to the rule. The tiers will be able to coexist, will not be written in vacuums, and each will be upgradeable (or even downgradeable) with ease.

Market the feature, not the lifestyle

OOP might make sense to a software developer, but even with the proper execution, it still does not solve the problem for a confused consumer. I believe the primary issue with the tiered approach, when executed incorrectly, is that the tiers are advertised as lifestyle choices. Are you a home user, small business professional, or a network technician? What if you do a little of all three? The network technician would know how to choose, but the former two would have difficulties. Pinpointing what a user needs to accomplish as a member of a specific lifestyle helps the situation, but there is still potential for overlap.

Instead, each tier, although named differently, should be a feature set. You should be able to select, add, and remove features when purchasing or upgrading software. Although not completely in line with this approach, I have always enjoyed the way in which Winamp presents each tier release. Every feature is listed neatly, and it explains to the user exactly what you get by selecting the Pro, Bundle, Full, or Lite version. The best part is that the core functionality is available in every tier, including all the necessary file types for streaming music. Instead of removing key features to get users to upgrade to Pro, Winamp includes “special” features that enhance the customer experience.

Make it productive, not feature full

Another argument against tiered software, is that it would not be necessary, if the software was simply productive. Software is no longer selling better if it just includes a robust feature set. There would be no need to dowse an application with features if the features included did exactly as they were advertised. Consumers want features that are useful and intuitive, and that enhance productivity. On some level, I tend to agree. Why pay for features that I simply do not need, or be restricted from accessing useful features that should be have been included in all tiers?

Nevertheless, this does not solve all of the issues with all of the software. For instance, think about tax software. You must not only file state taxes, but federal taxes as well. You have the option to file over the Internet, or print out your completed tax paperwork. Some premium versions include a Web based counterpart. Small businesses or entrepreneurs might want additional assistance with stocks and bonds, or real estate. Each version is uniquely suited to the tax-payer, through very distinct tiers. Almost all of the features are incredibly useful.

Offering tiered software to customers only because the measure of functionality is bloating the current product line will always be the wrong choice. Even so, finding the right mix with each tier can be difficult. It is clear from the number of useless features that appear in some products, that marketers are still under the impression that the volume of features still sells. It will be up to developers and product managers to instill a sense of balance, and to design the software with special attention to this particular detail.

• Posted by Brian
• December 12th, 2007