If Software Is A Commodity...Then What?

  • Written By:
  • Published:


Many, if not most categories of software have become commodities. Vendors hate to hear it, but most of the products in a category produce the same results, pretty much in the same way. If this is true, how do user select the right vendor? How does a vendor get selected?

Yes, A Commodity!

How do we define a commodity in the software world? Both vendors and end users tend to focus on features, but both should focus on the needs of the business. A commodity situation exists when multiple products can satisfy the needs of the business with no meaningful difference in the results. This is more typical in a mature market (for example, categories like ERP, SCM, MES, etc.) and less so in a newer market. We find that most products yield the same results and the differences are in the "How" they do it instead of "What" they do. The relatively small percent of features that are different (usually less than 20%) are often in the "nice to have" category, or are not features that most end-users need. The product battle becomes one of ease-of use, add-on modules with questionable needs or "my general ledger (GL) field is bigger than yours". How the buyer defines their needs can make a difference. If a company states, "We need ERP", hundreds of vendors will claim to fit the bill and most will be correct. If the buyer states, "We need an ERP for a tier two auto supplier who makes plastic parts", the list of vendors becomes much shorter and the odds being a commodity becomes less, but not zero. If an enterprise has existing software vendors, that may lessen the commodity nature of what is being sought. A need becomes integration into the existing solutions. That means the existing vendors have an advantage and others must compete on their ability to integrate.

If The Products Are Commodities, What's Important?

If the software category is a commodity, do we need to talk about function? Yes, after all, that is what develops the value. Critical functions still require evaluation to make certain both "what" and "how" are appropriate for the business. But function becomes less important in a commodity category.

Like any commodity purchase, the non-product issues become the decision criteria. Both buyers and sellers must focus in the non-product issues to understand the difference.

The various types of decision criteria can be assigned importance as in the chart of decision criteria shown, with the product usually the most important issue, services next, tangible issues and finally intangible issues.

According to how commoditized the software category has become, differences may not exist in the product area and perhaps limited differences in the services area. For example, in a new software category, the products and the results may be very different. In a mature product category (financial systems) both products and services may show minimal differences. We need to spend the effort of validating that things are the same but even more time discussing the differences.

Examples of each category of decision criteria include:

  • What the product does relative to the needs of the business
  • How the product does it (ease of use, reporting options, etc.) ?
  • Security
  • Integration
  • Core technologies
  • Consulting services
  • Education
  • Support
  • Implementation plan
Tangible Issues
  • Speed of implementation
  • Internal effort required for implementation
  • Total Cost of Ownership
  • Flexibility
  • Scalability
  • Ease and speed of modifications and extensions
  • Availability of other modules which may be needed in the future
Intangible Issues
  • People
  • Trust
  • Vendor stability
  • Vendor credibility
  • Vendor focus
  • Vendor knowledge
  • Risk
  • End-user company politics


End Users Buyers should decide on their needs first. Given those needs, how many vendors can satisfy those needs and do differences in what they do exist? Define your needs above the level of individual features. Define needs relative to your type of business and the problems you are trying to solve.

Do look at product but only to verify that it will reach the results you seek. When looking at product, you may like how a product does things, but does it have any meaningful difference to the outcome of the project? If an end-user organization focuses too much on product when the software category is a commodity category, they end up basing the decision on the quality of the sales effort, not on what's best for the business.

Spend quality time on the other decision criteria until you understand the differences among vendors. When differences exist, ask the question, "Are the differences meaningful to the success of the project, to the results?" Differences that impact success should be heavily weighted while those that do not are interesting but maybe not meaningful.

Vendors - Take a very hard look at your software category. Yes, you want to be different. Yes, most vendors think they are different. But is your product really different or is it just myopic thinking on your part? Think of your product category from the prospect's point of view, not your own. Look at your category to understand how many players exist. Does your product really provide different value? Does your product do things in a different and meaningful way? For most categories and therefore most vendors, reality says that product does not make a huge difference; you are in a commodity situation.

If you are in a commodity software category, face the reality. Start thinking of the total list of decision criteria. Develop differentiation in non-product areas. Understand that selling the non-product issues is more difficult than selling product. You need professionalism and credibility to win. (See Technology Vendor Can You Afford Credibility) Change your sales process. Your product objective is not to get eliminated. You need to figure out to win with non-product differentiators. Most importantly, learn how to sell in a commodity market and execute your new plan.

About the Author

Olin Thompson is a principal of Process ERP Partners. He has over 25 years experience as an executive in the software industry. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry.

He can be reached at Olin@ProcessERP.com.

comments powered by Disqus