Why Service Businesses Are Not Product Businesses

What manager in a product-oriented business has not thought about growing revenues by adding related services? What company in a service business has not weighed the advisability of offering products? Expansion often seems to make sense, but most companies creating a new offering limit themselves to approaches that are familiar and have worked before. Unfortunately, all too often those approaches are not suited to the new sector. The software industry provides examples that could help managers in other industries — particularly other high-technology industries — avoid getting injured in the chasm between service businesses and product businesses.

With the explosive growth of the global software industry, which witnessed annual revenues topping $500 billion in 1998, a striking phenomenon has emerged: software companies attempting to straddle the two industry sectors, products and services.1 Traditionally, individual software companies catered to either the service market or the product market, but competition and the need to maintain a high growth rate induced many service companies to venture into the product arena.2 To a lesser extent, product companies have started widening their offerings to include services.

It is too early to judge how successful product companies are in offering services, but the lackluster results in the opposite direction are evident.3 A recent survey shows that from 1995 through 1998, approximately 87% of the product ventures initiated by software-service companies were unsuccessful.4 Traditional explanations for their failures (such as lack of venture capital and marketing skills) are hard to accept, given the availability of capital and talent and the fact that Internet technologies have removed several location-based disadvantages in software development.5 Instead, the failures point to more-fundamental issues.

It appears that many software-service companies that attempt to move into the product sector fail to recognize the differences between the two sectors’ underlying business models. The implications for design and development practices are significant, and inappropriate transfer of organizational practices and development culture from the service sector to the product sector is a recipe for failure. A 1999 study of 21 software-service companies addressed the following questions: What current practices and strategies of a service company could inhibit its success in the product sector? What accommodations should be made to the software-development culture to support both product and service businesses? What organizational mechanisms should be deployed to capture potential synergies between the two businesses?6 Although the study focused on the move from the service sector to the product sector, it also provided food for thought for companies making the move in the opposite direction.

The issues are not limited to the software industry. An increasing number of other high-technology industries (including computers, electronics and semiconductors) are witnessing a gradual blurring of the boundaries between their product and service sectors. Dell, Sony and others have embarked on ambitious projects to incorporate service offerings into their portfolios.7 As the software-industry examples reveal, straddling the product and service sectors successfully requires the ability to understand the differences in the underlying economic and market forces affecting the two sectors —and the adoption of appropriate organizational practices.

Five Key Issues Differ for Products and Services

Software-product businesses and service businesses both involve software development and are global, knowledge-intensive and highly dynamic. However, they differ in several respects, including the economics of each business and how the businesses create value.

Intellectual Property Rights

To the software-product vendor deciding the technology strategy and focus, legal protection of the product’s special features is critical.8 If strong protection is difficult to obtain, the only way to maintain competitiveness is to pursue rapid innovation and to bring out a continuous stream of upgrades that maintain the product’s uniqueness (as Netscape did in its early years). For software-service companies, intellectual property rights are less important. Companies rarely own the rights to the services they develop or to the knowledge generated during development. Thus they lack the experience and processes to handle intellectual property rights appropriately for a product-development plan.

Product Complementarity

Software-product companies expend a lot of effort developing products that complement, support or enhance the functionality of existing and established products. By leveraging the potential for products to complement one another, vendors can gain larger market size and make it more costly for customers to switch. For example, the initial success of i2 Technologies (a supply-chain solution provider) was due not only to its product’s unique functionality, but also to how well the product complemented the leading enterprise resource planning (ERP) products. (ERP products provide companies with one comprehensive computer system that will integrate all the functions or tasks of the computer systems used by different departments or business units.) Software-service companies, on the other hand, rarely concern themselves with the long-term competitive implications of which application area or software platform they choose to specialize in, because of the ad-hoc nature of the projects they undertake. More often than not, their focus is defined only by the range of software projects that they have managed to win over the years.

Returns From Scale

Because fixed costs predominate in the development of products, companies can expect higher marginal returns from increases in market share (that is, from scale). The services sector, however, is dominated by variable costs, and therefore increasing returns from scale are rarely possible.9 Achieving returns from scale would require extensive reuse of client specifications in other contexts — inherently difficult and often not contractually permissible. Such disparities in the two sectors lead to different behaviors: The promise of scale benefits may encourage product companies to make higher initial investments in the design of the product architecture. Service companies, for their part, handle variable costs by emphasizing process rigor and efficiency.

Abstracting Knowledge and Integrating Technology

A product company’s success lies in its ability to abstract the knowledge obtained while developing a product. Context-specific elements must be removed, so that the final product can be deployed in varied situations.10 Service companies are in a different situation. Because their primary objective is to develop a system that is uniquely suited to the idiosyncrasies of the client’s business, abstracting knowledge is not emphasized. Further, in the product sector, the varied technologies used in development must be integrated in the product architecture to enable seamless operation of the end product. Thus when integrating into its ERP product a technology developed by another company, SAP embeds it deeply in the architecture. Service firms, on the other hand, emphasize the ability to compartmentalize external technologies so that integration can be effected without reducing the efficiency of the overall development process. A Singapore-based service company integrated an external data-analysis tool into a claims-administration system that it was developing for an insurance company merely by creating a data bridge between the core system and the tool — without considering architectural compatibility. The approach may not result in optimal performance, but it definitely reduces development cost and time.

Connections With Users

The knowledge derived from users shapes software development in both the product and service sectors. However, because the users themselves and the nature of their contributions differ, their relationships with companies differ — as do the ways companies manage those relationships. Users are a critical source of innovation for product vendors, who commit considerable resources to long-term relationships.11 In the service sector, relationships with users are more project-driven and dominated by short-term goals. Further, because service companies often are involved in the development of mundane business applications, such as accounting systems and inventory control, their interactions are generally with unsophisticated users.

So although product and service companies may both be involved in software development, organizational practices differ. (See “Comparing Product and Service Companies on Five Key Issues.”) Companies that have operated in either sector for long tend to emphasize the practices and culture they know best. When they cross the product/service divide and start operating in both sectors, the desire to find synergies often results in inappropriate transfer of development practices and methods — and leads to failures. For example, when a service company transfers its focus on process efficiency and rigor to products, those products may end up with limited design flexibility and create nightmares for long-term product support. The following cases demonstrate how five software-service companies addressed the managerial challenges of moving into products.

Failure and Success in Moving from Services to Products

The following short case studies come from the author’s 1999 study of 21 software-service companies. The companies, located in India, Singapore and the United States, pursued product initiatives to varied extents. The first three met with failure; the last two were successful.

Case One: When a Service Strength Becomes a Product Weakness

Several years back, an India-based software-service company with expertise in developing accounting and financial systems for manufacturers decided to develop a generic accounting package targeted primarily at small and midsize manufacturers. Although the product achieved some initial success, by the end of the second year it had not captured sufficient market to justify further investments, and the company was forced to scale back. What went wrong?

First, the company based the product largely on the solutions it had created for its major clients over the years. Leveraging its internal expertise provided time and cost advantages, but the company failed to incorporate market elements to enhance those advantages. Its generic accounting product had too few unique features to differentiate it in the market. The company was counting on its domain expertise and its reputation in the service business to create sufficient market advantage and underestimated the significance of other elements that would have given the product a wider customer base. For example, it failed to integrate the product with leading products in complementary application areas (such as inventory control or taxation). Similarly, it failed to offer the product on multiple software platforms. The product manager admitted that the company’s service solutions had been for clients who used the Unix platform, and that its expertise ended up limiting its product: “We prided ourselves so much on our [Unix-based] development expertise that we focused solely on that [platform] for product development.” The lesson? Too much focus on leveraging its existing internal strengths made the company neglect other critical market elements that would have forced it to redefine the product’s focus or even to sacrifice advantages such as Unix expertise in order to gain a more defensible market position.

The second factor in the product’s failure also relates to development practices imported from the service business. Over the years, the company had put a premium on process rigor and efficiency. The downside was process inflexibility. On three separate occasions during the development of the first version of the product, project managers rejected demands for incorporating changes in the product specs, citing the need to remain efficient. As one later noted, “We didn’t realize … until very late in the game that the one quality that was most desirable in our service [business] … had become to some extent a handicap in [developing] products.” Given the dynamic nature of most product markets and the uncertainty regarding rapidly emerging competitive products, it is critical for product vendors to adopt a flexible and evolutionary product-definition process.12 Thus, when service companies venture into the product sector, they must reexamine the trade-off between process flexibility and process rigor, and make the necessary changes.

Case Two: When Ease of Development Hampers Design Flexibility

In the mid-1990s, a midsize software company based in Singapore, experienced in developing custom solutions for companies in the financial sector, decided to build a product to support the treasury- and securities-related operations of financial institutions. The new product found some early success. Unfortunately, at the end of the first year, the financial industry went through radical change, partly as a result of new government regulations, and the company had to revise its product to meet the requirements. In bringing out the new version, the company ran into technical difficulties, and the ensuing delays drove several potential customers away and hampered the product’s growth. By the end of the second year, having revised only one part of the product, the company realized that the initial promise would never be realized.

The company could not respond rapidly to the new business requirements because, like many software-service businesses, it had sacrificed design flexibility to ease of development. Product architectures must be able to leverage market forces, even if that makes development more difficult. Modular product architectures enhance long-term product flexibility and maintainability, and cross-platform product design ensures broader market appeal. However, both modularity and cross-platform compatibility require more-complex designs and higher levels of knowledge abstraction, which may reduce short-term development efficiency. In the service sector, ease of development dictates much of the design strategy.13 Given that profits are directly related to programmer productivity, simple system architectures that enable efficient development and coding are preferred to technically elegant and flexible architectures that require more development time.

The Singapore company’s product architecture was difficult to modify when new requirements arose. The CEO later reflected that it would have been wise to specify criteria that could have alerted managers to the inappropriateness of some of the trade-offs the developers were making. Instead, the yardsticks that senior managers used to control the project (development time and cost, for instance) drove the developers to adopt practices and policies based on their original service orientation. In the end, the company faced a significant redesign and a rewrite of the code, a task that eroded all its initial advantages.

Case Three: The Perils of Overgeneralizing

Some years back, a U.S.-based software company that specializes in custom-building decision-support systems (DSS) for companies in the financial industry decided to develop a generic DSS tool for financial-risk evaluation. It created a product targeted at managers in different industries who evaluate and control financial risk. Unfortunately, the product was a major market failure.

The company made a critical mistake while defining its product focus. In its service business, it had created unique, innovative features that were invaluable for its financial-industry clients. However, in choosing to target a wider market, the developers were forced to create a more generic product, forgoing innovative features that made little sense outside the financial industry. In failing to leverage its unique knowledge assets fully, the company created a product that was too generic to have any marketplace advantage. As one of the company’s senior managers noted, “We had some unique things to offer and a good reputation with our financial clients … in hindsight, we should have developed only for that [niche market].” The niche strategy might have limited the product’s appeal to a smaller customer base, but it would have allowed the product to retain its uniqueness.

Case Four: Successful Alliances With Other Product Vendors and Users

A few years ago, a U.S.-based software company that develops custom logistics solutions for the chemical and pharmaceutical industries decided to create a product that would leverage its knowledge assets, including the powerful software-based analytical tools it had created to solve complex routing and scheduling problems for clients. However, an external market evaluation showed that a generic product might have difficulty finding a market as a stand-alone solution. So the company decided to piggyback on the logistics module of an established enterprise-resource-planning vendor serving the same industries and clients. As the company’s CEO noted, “The crucial element of our success has been the selection of a complementary product that would add value to our end product and at the same time enable us to package and serve the knowledge built over years to an established customer base.” Such an approach compensates for the company’s use of relatively particularized knowledge (peculiar to the chemical and pharmaceutical industries) by aligning the product with an established product that would provide ready-made market-protection mechanisms in the form of an established customer base, brand equity and a stable technological platform.

The product’s success was also partly due to the measures the company took to develop strong links with users. As the chief technology officer noted, “Our user network, which we have painstakingly built up over the last two years or so, is our lifeblood … it has enabled us to understand the real value of the knowledge our service business brought in and prevented us from making a number of wrong design choices.” That emphasis on the user relationship is unusual for a service organization. Most service companies see their relationships with users as transaction-oriented (based on specific projects); in a transaction-oriented relationship, the established relational mechanisms facilitate only limited information sharing. The product sector, however, calls for development-oriented user relationships that can support both knowledge sharing and knowledge generation. Thus, an important challenge for a service company entering the product sector is to shift from a transaction orientation to a development orientation. The shift is difficult because it relates to the organizational culture; it may need to be addressed at the level of individual developers, who will have to start viewing users not as one-time customers but as long-term partners.14

The company in question took specific measures early on, creating new roles (such as relationship manager) to cultivate selected service clients who could contribute to product development. The company also gradually expanded its user network by including its ERP partner’s lead customers. To keep the users interested in participating in product development, the company offered incentives, including special implementation and integration services for the new product. The company strongly believes that the relationships were invaluable in the initial years of its product initiative and determined its eventual success.

Case Five: Successfully Using a Long-Term Design Perspective

In the late 1980s, one of India’s large software-service companies developed a branch-automation solution for a large Indian bank. Over the years, it added modules and also developed and implemented similar custom solutions for other clients in banking. Then, in the 1990s, the company developed a generic banking product based on its custom solutions. The product found success in both the Asian and European markets, thanks largely to practices the company adopted in product design and knowledge management.

The company realized early on that the key challenge would be to design a product capable of evolving. Creating a malleable architecture from custom-built software requires understanding which elements will be constant and which may change —and then designing the product around the major stable elements. To determine the extent of potential variability, the company classified each software component as vertical (engineered for a specific business domain) or horizontal (broader applicability), logical (providing business functionality) or physical (a basic technological component), and mandatory (core functionality) or optional (customers’ choice).15 By analyzing those three attributes, developers could assess the expected variability in each component and arrive at an architecture that would allow them to leverage the development work that had already been done in the service business while providing the flexibility to revise the product with ease. The design focus enabled the company to create gradually a product family from the initial custom solution, a feat that can provide considerable market benefits if done well.

The company’s management of the connections among its employees was another important factor. Although product vendors frequently rotate their developers across different product groups to ensure knowledge sharing and generation of new ideas, service companies rarely have much need for information sharing across project groups. Many service companies intentionally keep their developers dedicated to specific application groups to gain economies of learning. As a result, service companies may lack mechanisms for establishing and promoting the internal relationships that facilitate knowledge sharing across project or product groups. This company, however, took several initiatives to establish effective mechanisms for speedy and efficient consolidation of expertise as well as for knowledge sharing across its product and service businesses. For example, it instituted regular project reviews and audits to identify experiential learning and created an organizationwide knowledge repository to store such knowledge assets. It also created a knowledge directory (a people/knowledge map) that pointed to expertise within the organization, using a multilevel taxonomy of topics that crossed the product-service divide. The company complemented those measures with development methodologies that called for more-intense interactions across groups, an approach that forced individual developers to establish stronger internal ties. Together, the measures enabled the company to bring about a gradual change in the nature and purpose of its internal links, and to leverage on an ongoing basis the development work carried out in its product and service businesses in related areas.

The cases illustrate the issues that can contribute to the success or failure of a service company’s venture into the product arena. The issues can be classified into three interrelated categories: competitive strategy, knowledge sourcing and development strategy, but the key to success in all cases is to question ingrained development practices. Too often, companies not only fail to recognize that point, they mistakenly attribute their lack of success to external factors and end up making ever increasing resource commitments without effectively addressing the more fundamental problem of their development culture’s biases and practices. (See “Managerial Challenges and Lessons Learned.”)

Service Initiatives of Product Vendors

Software-product companies suffer from a similar blindness regarding biases in development practice and corporate culture when they attempt to incorporate software services into their portfolio. Product vendors have traditionally adopted an arms-length approach to services, typically offering services in partnership with established consulting companies. However, more recently, several product businesses, including SAP, Intuit, Oracle and i2 Technologies, have started establishing internal units exclusively to offer software services such as product customization and application hosting. For product enterprises, three issues are especially significant.

First there is the trade-off between process efficiency and flexibility. As they venture into the service sector, most product companies need to adopt process frameworks that impart more rigor into their development process, given the service sector’s greater emphasis on process efficiency and productivity. The fact that product companies have lagged behind service companies in adopting process-improvement models such as the capability-maturity model (CMM) indicates that product companies are still behind on the learning curve when it comes to process efficiency and discipline. As one software manager noted, “It is very easy to bleed money on a custom [software-development] project. … If you are not careful, you could easily end up paying for the inefficiencies of your client.” Process models enable companies to identify and isolate such sources of inefficiency.

Second, although offering application-hosting services enables product companies to introduce new technologies and solutions to their clients rapidly, it also requires reexamining most practices with regard to design flexibility and product integration.16 Further, such hosting services make clients more dependent on software companies, which may necessitate reevaluation of how the customer relationship is managed.

Third, product companies must institute whatever mechanisms are necessary to take full advantage of the potential synergies between the two sectors. For example, companies could use their product-customization and applications-hosting services (regardless of whether such services are offered directly or through an external partner) as an avenue to cultivate and evaluate their products’ new functionalities and features. To do so, the product company would have to consider software service as an integral part of its product-development process rather than as just an extension of its customer support, as many product vendors currently view it. The new mind-set has important implications for the type of resources allocated to the service business as well as the practices and methods promoted in that business.

Implications for Other Industries

The issues and the managerial challenges discussed here are likely to be relevant to companies in other high-technology industries that have both a product face and a service face.17 Examples include the semiconductor industry, in which service companies that design and produce customized specialty chips for companies are now branching out into the design and production of general-purpose chips, and the communications industry, in which service providers who traditionally have focused on designing and implementing customized networking products have started offering packaged networking solutions that cater to the general needs of a particular industry (for example, banking).18

As high-technology companies attempt to straddle both the product and the service sectors, some failures are inevitable —not from lack of expertise or lack of capital, but because of organizational practices and assumptions that are transferred from the dominant business. There are synergies between the product and service sectors in most technology industries, but the differences in the nature of their value creation and their delivery call for different types of design and development trade-offs and decision frameworks. Although the specific issues are likely to vary based on the industry context, the broad lessons learned in the software industry could become invaluable in avoiding potential disasters in other high-technology industries. The words of one interviewee, a CEO, go to the heart of the matter: “In our company there has been a constant tension between finding synergy between our product and service businesses and … recognizing the fundamental differences in the market conditions that drive the two businesses. … A significant part of our success in the last couple of years can be attributed to how we have managed the delicate balance between these two forces. … It has not been an easy task, and indeed, at many times, it has forced us to relearn and redefine our practices and policies.”