Software product or service - how can you tell the difference?

When a company is looking for software solutions, this is often the starting point for time-consuming selection processes of a usually long and expensive solution search. Taking many criteria into account, the decision which investment to make should be as objective as possible.

What are the economic and technical expectations of the solution?

The decision depends on criteria that are based on an economic or technical basis. Provided that the basic conditions for such an investment decision are suitably chosen, companies often have long operating cycles for the purchased software solution and thus often have high expectations of the return on investment.

In many of these decisions, the question about the purchase of a product or a service is not asked and therefore not consciously answered. This decision is an important feature when considering the Total Cost of Ownership (TCO).

Distinguishing real products and services

The process of making a decision is hard. The effects of a wrong decision afect the development of a company for years.

What happens if the wrong decision is made despite an intensive selection process? For example, because the decision-maker does not recognize the service? The offered product is not a product, but a service - a disguised service contract. Let's focus on 5 theses, where you can distinguish products and services from the outside.

5 Theses to avoid a wrong decision

What are the characteristics of real software products?

• With real products, short-term licensing is possible without an individual contract, while services in long-term (1/2 year contracts) are often service components hidden in the supposed license price. Beyond that, there are of course discounts if the product is a real one, e.g. in case of long-term commitment or prepayment (10-20% are common).
• The offer of a Proof of Concept (PoC) by the provider is often a sign that there is no finished software solution: A real product has already proven itself in use by many other customers in various cases. In contrast, a PoC protects above all the service provider, who must first check his risk.
• The customer does not have to change/contribute/understand anything about his processes or requirements when there is no real product (like data, other supplies): for integration, the service provider has to build everything individually "by hand", so there are fewer standards that have to be met by the customer. For the customer's cooperation, however, the product provider would like to gain more insight and understanding from the customer, as this reduces the total TCO, because the software customer can contribute with internal resources and does not have to pay (expensive) change requests or service retainers at the provider.
• Feature requests of the customer are implemented 1:1 as described when there is no real product. Since only individual customers are affected by this, the implementation and conception is very fast and the service provider can use it to simulate product progress. However, these developments only benefit individual customers and the customer does not benefit from further development of the overall product.
• Software vendors who sell a product usually offer different external service partners who can work on the system with him and the customer on an equal basis without having special tools or special rights levels (outside of usual rights/role systems). This makes the customer-user equal and so he can work on an equal footing and negotiate even for larger project orders. Different service partners in the portfolio help to create a natural market, comparability and higher service quality.