Outdated distinction: business model vs product

Over the decades that I’ve worked with companies, I’ve seen many, many examples of sales versus engineering. These two functions are frequently at odds with each other for a variety of reasons. In companies that are mostly technology-driven, senior management often comes out of R&D and is frustrated with the sales organization being unable to sell the beautiful products the company develops. These might include bleeding-edge technology and might solve the integration of mechanics, electronics and software beautifully, but often, there’s a lack of alignment with the ‘jobs’ customers are ‘hiring’ the product for.

In companies that are predominantly sales-led and where technology understanding is limited, R&D tends to be viewed with frustration. Customer requests for product functionality that seem perfectly reasonable take forever to be realized by R&D. Embarrassing quality issues slip through to the field because R&D is forced to release quickly. More and more of R&D resources get consumed by what seems to be simple busy work. And so on. Sales is well aware of what they could sell to customers if the darn R&D organization would just get its act together.

In both cases, though, the business model is often transactional, meaning you sell the product, the customer uses it for some time and then you re-engage to sell them the next product. That no longer works in a digitalized world as the design of the product and the way we aim to monetize the product need to go hand in hand from the start. This requires engineering to deeply understand the business and monetization strategy and build the enablers for different approaches to deliver value to customers. Sales needs to understand technology and work closely with engineering to ensure that all viable avenues for revenue generation are exploited.

With a digital offering, there typically are four factors that are different from a traditional transactional model. First, companies adopt DevOps, meaning that the product receives frequent updates to its functionality. Second, digital products often provide data back to the company with information about product usage, diagnostics and sometimes even data used for additional services to our customers or even to an entirely new customer base. Third, the business model either becomes hybrid, meaning that it’s a combination of an upfront transactional cost and a recurring fee, or purely continuous based on access, usage or performance. Finally, because of these developments, the relationship between a company and its customers transitions from a transactional one to a continuous one.

The consequence is that whereas in traditional organizations, sales and R&D often were at odds with each other, in digital companies, the two need to be joined at the hip. Especially when the business model is based on performance, this becomes critical. For instance, in the case of a customer using our product in production, our business model may be based on the number of items produced. This means that any updates that increase the throughput of the production line will automatically result in more revenue for us. In digital companies, this business model is actually preferred in many contexts as it perfectly aligns the incentives of the customer with those of the company.

One factor that often becomes a challenge in this context is customer adaptation and extension. Traditionally, especially in situations where the products are expensive and the number of customers is relatively small, companies have supported significant customization of their products to support the specific context of the customer. This customization can be done by the company, the customer or a third party hired by the customer. When adopting DevOps, however, that model falls apart as customization of the product would need to be conducted every couple of weeks for every customer, which is prohibitively expensive.

One approach is to adopt what one of the companies in the center I lead refers to as the “avocado model.” Their product defines an API that customers use to have their specific extensions access the system’s core functionality and data. This API is defined in such a way that the product can be updated frequently (DevOps) while the extensions can stay constant.

The avocado model only works when the customer-specific extensions can be modeled such that they can live on the other side of an API. Unfortunately, that’s not always the case. In those situations, the company can follow the superset platform approach, where all functionality and all variants provided to customers are integrated into a superset product or platform and the specific functionality used by each customer simply becomes a configuration of the superset product. The company can then adopt DevOps as long as it sets up a test infrastructure that ensures that all product configurations used in the field are tested.

An advantage of the superset approach is that it becomes much easier to cross-sell and upsell. New functionality can be offered to customers who don’t have access to it yet and providing it simply becomes flipping the switch on a configuration parameter, assuming the functionality is already available in the superset product or platform. Achieving this, however, requires a close collaboration between sales and R&D.

In many companies, sales and R&D traditionally have an antagonistic relationship. When digitalizing the offering to the customer base, this needs to change as the business model and the product need to be deeply integrated with each other to ensure revenue and growth opportunities. This requires DevOps, a superset product or platform, a continuous relationship with customers and typically a business model aligned with the incentives of the customer. To end with a quote by the late and great Steve Jobs: “My model for business is The Beatles. They were four guys who kept each other’s kind of negative tendencies in check. They balanced each other and the total was greater than the sum of the parts. That’s how I see business: great things in business are never done by one person, they’re done by a team of people.”