Build it Right, then Sell it to Many (and Keep Repeating)

Building a software product is more difficult than doing projects or providing services. With projects, software is developed to meet the exact specifications of the client. Work begins only when the contract is signed.

The project scope can be defined accurately in consultation with the customer, and deployment happens in a controlled environment at client site, with known hardware and software. Support requirements are minimal.

Changes to specifications, or defects during development or after deployment, usually have limited financial impact. In T&M contracts, the vendor is paid regularly, based on efforts put in. Hence, changes and delays may in fact, bring in more revenue. Fixed price bids usually account for contingencies like delays. If specifications are changed, the vendor can ask to re-negotiate the price. Quality issues may cause loss of credibility, or at worse, project termination and denial of future contracts. 

A product, in contrast, will be shipped to thousands, or even millions of users. Specifications are based on the seller’s understanding of customer needs. Therefore, a deep knowledge of market and domain is required. Clients are not guaranteed, and marketing and sales functions are critical. Selling cycles are longer and more cumbersome.

Quality has to be outstanding, since the product will be used by a variety of users, and on a plethora of platforms and configurations, and not all of it can be anticipated in advance. As the diagram below shows, the cost of fixing a defect increases exponentially depending on when it is detected.

A post-release defect creates negative publicity and costs lot of money. A patch to fix the problem has to be developed and distributed quickly to the users. Even Microsoft has faced this problem repeatedly when hackers have exploited vulnerabilities in its operating systems. In another instance, a US-based personal finance company inadvertently exposed the private account details of several hundred individuals to other users. Such snafus can expose a product company
to expensive lawsuits.

A product business requires highly structured engineering and organizational discipline. Formal reviews are necessary at every stage (architecture, design, coding) to catch deviations from the requirements. Rigorous testing and quality assurance (test/QA) processes should be followed to detect defects before product  release. Test labs must replicate the myriad deployment environments that users  may have. This can become complicated for multi-platform products that support a variety of operating systems (Windows, Unix, Linux) and databases.

The installation procedure must be highly automated and work fl awlessly in all possible system configurations. New versions, patches, and future upgrades must install without any disruption to existing software and data at user sites. A strong support organization (on phone, email or onsite) has to be built.


Unlike projects, there is no end date for product engineering. They must  continue innovating and releasing new versions with more functionality and advanced features, to stay ahead of competition. Product organizations often have a signifi cant revenue component derived from services such as consulting, customization, integration and solutions. Unlike a pure services business, these are used to underpin and drive their product sales.

The ecosystem for products is more complex, consisting of engineering teams, product management, marketing, sales, consulting, professional services, distributors, system integrators, resellers and investors.

Reprinted from From Entrepreneurs to Leaders by permission of Tata McGraw-Hill Education Private Limited.

Product Business is Very Different from Services

What is the difference between software services and products? Why is it important for India to be developing products?

First Invest, and Then Reap

The business cycle in a services company starts with sales, and ends with project or product delivery. On the other hand, a product company must first invest in building the solution. Then begins a long and complex business cycle to sell, support and continuously evolve the product. This reversal of sales and engineering sequence has a profound impact on how product organizations get built.

Services industry provides manpower to build software apps and products, which belong to the customer. Typically, IT departments of retail, manufacturing, financial, insurance and other businesses require new applications, or enhancements to existing ones, for in-house use. They turn to Indian companies for design and implementation. Needing long-term support, global product companies establish extension engineering teams at Indian subsidiaries or services companies.

In services, clients own the Intellectual Property (IP). All gains (cost savings, productivity improvements, revenue) and risks are entirely the clients’. The service provider gets paid in proportion to the cost of development, irrespective of whether the pricing model is fixed cost or time and material (T&M).

This means that the services revenue growth is directly linked to number of engineers. The industry’s competitiveness is determined by cost of engineers. But the number of trained software engineers in India, cannot scale indefinitely. Even today, good talent is becoming scarce. Salaries are rising to a point where low-cost economies such as China, Vietnam and Philippines have started to compete. Nevertheless, superior talent, project management expertise, processes, and English language skills continue to provide an edge to India. However, others are catching up, thereby causing a slowdown in the industry’s growth rate.

In comparison, products have the potential to fetch non-linear revenue. A product business creates intellectual property. Once developed, the same solution is sold repeatedly to a large number of buyers.

The graph above shows the famed hockey stick revenue model for a successful product company. A services organization can have positive revenue from day one, and grow very quickly too, but the headcount-centric model will eventually become a drag.

Reprinted from From Entrepreneurs to Leaders by permission of Tata McGraw-Hill Education Private Limited.