A common debate I hear among software entrepreneurs and managers is whether it is better in the software business to be mainly a products company or a services companythe underlying assumption being that a company cannot be equally good at both. During the boon years for technology companies before 2001, I believedand I think most venture capitalists, managers, and entrepreneurs believedit is much better to be mainly a products company. I no longer think this is true.
A products company gets most of its revenues through new sales of shrink-wrapped software packages. There are potentially large support and maintenance costs associated with a large user base. But, in general, if it costs you roughly the same to make one or one million copies of a product, you would be a fool not to want to sell a million as isthat is, without adding one-of-a-kind features for individual customers. The more a software company gets into customizing its products for each customer, as well as selling large amounts of maintenance (special product enhancements as well as regular product upgrades) and support services, the more employees it needs, the more unique projects or labor-intensive work it undertakes, and the more it leans toward becoming a services company.
Of course, what I now realize all too painfully is that in bad times customers (individuals or enterprises) may decide not to buy new software versions. This potential failure to buy puts the revenues of software products companies at much more risk than service-oriented companies with lots of long-term contracts. The discretionary nature of software product sales was not so obvious to me or pronounced before the crash of the post-2000 Internet economy.
Because software product sales are subject to buyers "just saying no," it is now apparent that most healthy software companies need to balance product and service revenues to grow rapidly in good times and to survive the lean years. In bad times, often the only revenues a software company can really bank on are from maintenance and services (customization of code, system implementation, training, and technical consulting) delivered under long-term contracts. I like to refer to the services-oriented business model as being somewhat like that of a bank. The software company's long-term contracts for maintenance and services are akin to assets on deposit. In contrast, the business model of software products companies, which strive to replicate copy after copy of a standardized good, is more like that of a printing press.
Software companies, especially young ones, often struggle with the products versus services debate. The reason is obvious. A hit software package, like a best-selling book, can generate enormous profits. In practice though, it is just as hard to write a hit software package as a New York Times best-seller. It is even harder to follow that hit with a continuous stream of new products (the sequel or upgrade business) that sell in good and bad economies. Every successful software company I know of has dealt with the challenge of saturated markets. Hence the tension that inevitably arises among enterprise software companies with a strong products business: they realize they must move eventually toward selling more labor-intensive services.
Regardless of the balance of products and services they choose, managers of software companies must understand what their primary business is, and recognize how the two differfor selling products requires very different organizational capabilities than selling services.
And the struggle is more complicated than this. Software products companies that want more revenues from services generally get those revenues from service contracts to support their new product sales. A general rule of thumb is that, over the lifetime of using a software product, enterprise customers pay between one and two dollars in service and maintenance fees per dollar of software license fees (the up-front product cost). As a result, the pipeline of potential service revenues will rise or fall just as steeply as the rise or fall in new product sales, albeit with a lag of a couple of years. Therefore, software companies with a strong services business must think more about selling products, despite their more sporadic and non-recurring levels.
It is also possible for software products companies to gravitate too much toward services and ruin the potential of their products business, especially when first starting out, or in bad economic times. Say a software company selling a standardized product saturates this market, and starts offering customers anything they want. This leads to selling customized versions of the products, one at a time. The service portion of a company's revenues, and the cost of these revenues, start to rise dramatically.
In a more profitable scenario, software companies sell packaged software to corporations, but as part of the contracts, the enterprise customers agree to pay a certain amount periodically for product upgrades, new training, technical support, expanded product use, and some special bug fixes, usually included under maintenance and service fees. So, as packaged sales or software license fees increase, so do maintenance and service revenues.
Regardless of the balance of products and services they choose, managers of software companies must understand what their primary business is, and recognize how the two differfor selling products requires very different organizational capabilities than selling services.
The software products business is mainly about volume-selling or licensing the most copies you can of a standardized product. The basic growth strategies here are scaling or duplicating what you have done in similar markets. Microsoft has set the model for such firms, which ensure volume sales by setting de facto technical standards that "lock in" customers, whose software applications and databases only work on a particular operating system or hardware platform. The development organization needs to focus on creating a stream of new products and upgrades at regular intervals (à la Windows 95, 98, and 2000) with standardized features good enough for the largest possible set of users. Mass marketing and distribution skills are critical. Part of the strategy for a products company might also include trying to become a platform leader, although most software companies create complementsproducts that work with and add value to a platform, such as a Windows PC or Unix workstation, or a handheld device powered by the Palm operating system.
The software services business is mainly about people. You need to build specific rather than general customer relationshipsand get enough profitable accounts to keep your consultants and developers busy close to 100% of the time. Companies such as IBM, PriceWaterhouseCoopers, Accenture (formerly Andersen Consulting), and Cap Gemini Ernst & Young have set the standards here. A number of Indian companies, including Tata, Wipro, Infosys, and Satym have also come on strong as global competitors bidding for custom IT jobs. Hitachi, Fujitsu, and IBM Japan are leaders in the Japanese market. These types of services are not scale businesses, not software licensing à la Microsoft. But services companies can be strategic as well as efficient. It is usually important to mix senior with junior people to maximize profits for any given client project, with the challenge being to do this without damaging the relationship by having inadequately skilled people on the job.
While software products companies are lured by potentially enormous scale economies, the Holy Grail for service companies are the more elusive scope economies. These can arise from structuring how-to knowledge on requirements, project management, customization, user acceptance testing, or design reuse across different projects. Scope economies can also arise from clever account managementforming relationships with particular customers who keep coming back for more of your software and services over time.
So in a nutshell, my take on the products and services debate is that neither designation is superior. Companies should know where they stand as far as their primary focus, but shouldn't be so rigid that they neglect to reap benefits from both income streams.
©2003 ACM 0002-0782/03/0300 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.
No entries found