The massive growth and valuations of tech companies seem to indicate that funding new market entrants is—at least in terms of capital allocation—more successful than transforming established market leaders. But why is adapting an existing business less effective than building a new one from the ground up? Why do native software companies outpace their transforming competitors so consistently?

We believe this is due to two factors:

The first is a deep, structural misunderstanding of how software development creates (shareholder) value. Below, we will show how software engineering works entirely differently than goods manufacturing or providing personal services, because software is not a commodity.

The second is buried deeply in the organizational nature of the transforming companies and commonly referred to as the “innovator’s dilemma.” Coined by Harvard professor and businessman Clayton Christensen, the expression describes how successful companies can do everything “right” but still lose market leadership—and even fail—as new and unexpected competition dominates the market.

To understand how to face these two issues head on, we must dive deeper.

Software development is no commodity

A look at the dynamics of transforming companies shows it’s not a lack of resources that causes them to be left behind. Most companies have recognized and acknowledge that they have to invest in their digital transformation.

One of the most straightforward indicators of this investment is initiatives to ramp up their software departments, including the hiring of thousands of software developers. Take the German automotive industry, for example.

Volkswagen announced in early 2021 that it wants to boost its digital team to 10,000 developers by 2025. To achieve this end, Volkswagen has founded its own coding school and is retraining former assembly-line workers as software developers. Likewise, Mercedes-Benz has the target of 10,000 developers in its sights after creating 3,000 new jobs in the field of software development in 2022. The goal is to launch the Mercedes-Benz Operating System (MB.OS), a “data-driven and flexibly updatable operating system, starting [in] 2024.”

Transforming companies in the automotive sector have improved their approaches to software engineering and are recruiting developers as part of a long-term vision to produce better results. And judging by the above figures, there’s no denying the fact that they’re willing to spend the money necessary to effect their transformation. And yet, as we discussed in the previous article in this series, despite this fact — and despite recent losses in its share value — relative newcomer Tesla is still valued by the capital markets as being worth more than all the German automotive OEMs together.

More isn’t necessarily more

So the problem is neither personnel nor investment in software, but the perception of software (at least as indicated by the capital markets). And that’s not limited to the automotive industry: In many companies that shift their traditionally analogous business models towards tech, software is often considered to be (and therefore treated as) a mere commodity. Consequently, software production processes are structured like the manufacturing of material goods.

This way of thinking suggests there is a direct correlation between quantity of input (e.g., lines of code, number of features implemented, or hours spent working on the product) and the size and quality of the end product. The general assumption is that more hours result in more product or service and will thus lower costs per unit—in this case, lower costs per work hour or line of code—and increase profits.

This assumption is true for the production of material goods. But it’s fundamentally wrong when applied to the development of software products, solutions, or services, as these are all different from producing a T-shirt, or a jet engine.

The manufacturing of material goods usually starts with a prototype. The goal of the manufacturing process then becomes to replicate this original as closely and efficiently as possible. Whether this replication process is simple or highly complex: its primary goal is to minimize deviation from the prototype. Each copy can be compared to the original or another copy. Any faults and deviations that exist are “tangible”—they can be empirically verified and corrected. The output (i.e., number and quality of units produced) can be clearly and objectively measured and is also reflected in the company’s year-end balance sheet because these are (tradeable) commodity goods.

The uniqueness of software

Every software build is a unique arrangement of code, created in particular ways and for specific purposes. Its effectiveness cannot be measured or quantified with a universal value. Instead, good software fulfills the purpose for which it was developed; it is “beneficial”.

And this benefit is valued, not the lines of code.

This fact has a few implications that must be considered when building software:

• First: In a software development process, prototypes are (solely) built and required to monitor the process and serve as landmarks while the product is created. There is no “final” prototype that serves as a template at the beginning of the process. Instead, various protypes, drafts and layouts, experiments and builds must be produced, and each prototype indicates the viability of the current direction—and whether course correction is necessary.

• Second: Software development is about exploring possibilities and new ways of dealing with a problem. That requires the freedom to be creative and to consciously re-evaluate and deviate from earlier approaches to similar problems. While an assembly line requires strict instructions and foremen, software development projects need guidance and leadership.

• Third (and maybe most important): Software development processes need to be managed and monitored differently than traditional production processes: Traditional monitoring allocates resources (such as staff or funds) to cost and profit centers. Only profit centers are expected to contribute to the company’s income. That means they optimize for higher production, increased sales revenues, or more profits through cost-reduction. They follow a pre-determined and necessarily a pre-validated chain of value creation. Accordingly, transforming companies too often aim for more lines of code, more features, or for more development time per dollar spent. They assume this represents value.

Startups (and native software companies) on the other hand work purely based on the maximum principle: With a given budget, they do anything reasonably possible to achieve the best result (for their investors or shareholders). They focus on numbers, too—but they target action metrics: successfully lowered user acquisition costs rather than a slight increase in sales, higher customer lifetime value through lower churn rates rather than upselling, and foreseeable profitable growth rather than short-term profits. They value the future value (and thus the ability to maximize value creation) far more than the actual profits. Because native software businesses know: The value of each unit has not (yet) been determined.

Transforming companies’ dilemma

The other factor that blocks the success of software development processes in transforming companies is their (limited) openness to novelties and innovation.

Transforming companies often have intimate knowledge of established trends. They have an existing successful, often dominating, position in their market. This is based on a product that they continually try to optimize based on the feedback of customers and predictive market analysis. To adapt the terms coined by Clayton Christensen, author of The Innovator’s Dilemma: Transforming companies engage in sustaining innovation with the goal of maintaining existing business success and to extend it along familiar and predictable pathways.

In contrast, native software companies begin and maintain their growth by engaging in disruptive innovation. They identify niche markets that current market analytics deem not profitable or too risky and expand from there. Their processes are thus optimized for fast responses to and quick shifts in interest in various market niches.

As a consequence, native software companies have a vastly different approach to development. When producing material goods, deviation is a problem; but for software products, it may be the key to conquering a new market. In 2017, Mark Zuckerberg said in an interview, “At any given point in time, there isn’t just one version of Facebook running, there are probably 10,000.” And as Meta explores AR, VR and the metaverse, it’s clear this spirit of experimentation is still alive.

For manufacturers, deviation must be eliminated—or at least reduced though strict enforcement of standards and continuity. For native software companies the never-ending search for product-market fit, for the next big thing, is at the very core of their existence—and this is not measured in units or percentage of completion. A single “killer feature” may help you reach product-market fit and enable you to outperform all your competitors; it is far more valuable than any set of mediocre features.

With this in mind, Amazon President and CEO Andy Jassy wrote in his 2021 letter to shareholders:

For native software companies, it is this willingness to listen to feedback while continuing to innovate that can turn a short-term leap of faith into long-term value—and ultimately success.

In part three, we will discuss the way out of the innovators dilemma and how established companies can get a disruptive perspective on their own transformations.