The Mechanical Engineer and the Innovator's Dilemma

The Best Engineers Build the Wrong Products

There is a particular kind of strategic failure that is almost exclusive to engineering-led companies, and it is both the most understandable and the most damaging. The best mechanical engineers in a company — the ones who genuinely understand their product domain — are the most resistant to the innovations that will eventually displace their products. This is not a paradox. It is the logical consequence of deep expertise applied to the wrong problem.

Clayton Christensen described the innovator’s dilemma as the mechanism by which successful companies are displaced by less sophisticated competitors entering at the bottom of the market with simpler, cheaper solutions. This is the standard narrative, and it is real. But in the mechanical engineering context that characterizes most DACH manufacturers, the dilemma has a more specific texture. It is not primarily a story about startups disrupting established players from below. It is a story about how engineering excellence — the genuine competitive asset that built these companies — becomes a systematic filter that prevents organizations from seeing the most important opportunities.

I teach a module on innovation at WU Vienna. When I describe Christensen’s framework to a room of engineers, they nod along — they have heard of it. When I ask them to identify the disruptive threats to their own organization, the answers consistently reveal the same bias: they see the threats that are technically sophisticated, and they miss the ones that are simpler and come from a different direction. The innovator’s dilemma, in an engineering organization, runs through the minds of individual engineers before it ever shows up in a boardroom.

How Engineering Excellence Creates Blind Spots

Mechanical engineering is a discipline built on a particular epistemology: problems have correct solutions, solutions can be evaluated on objective criteria, and better solutions outperform inferior ones. This is enormously valuable for solving engineering problems. It is dangerously misleading when applied to product strategy.

The Performance Trajectory Trap

Engineers evaluate solutions by performance on technical metrics. In any established product category, there are well-understood metrics: load capacity, precision, efficiency, speed, durability. Engineering-led companies excel at improving performance on these metrics. And this creates the first element of the innovator’s dilemma: they improve performance on established metrics past the point where customers need or can use the improvement.

A CNC machining center that achieves 2-micron positional accuracy is a genuine engineering achievement. If 80% of the applications in your target market require 10-micron accuracy, that 2-micron performance advantage is not a competitive asset — it is cost that your customer is paying for without receiving value. Meanwhile, a competitor offering 8-micron accuracy at 30% lower cost is technically inferior on the specification sheet and commercially superior in most applications.

Engineers see the accuracy gap. They struggle to see that the accuracy gap doesn’t matter for most customers.

The Solution Space Constraint

Deep mechanical engineering expertise creates strong intuitions about the solution space. When a problem is defined, experienced engineers can rapidly generate a range of solutions within the domain they know — mechanical systems, materials, manufacturing processes, structural design. This is fast and valuable when the optimal solution lies within that domain.

It becomes a liability when the optimal solution lies outside it. An engineer who has spent 20 years solving thermal management problems with mechanical solutions will have a strong prior that the next thermal management problem requires a mechanical solution. The possibility that software-managed intermittent operation, materials with phase-change properties, or a fundamentally different system architecture might be superior will feel intuitively less promising — not because the engineer is incompetent, but because pattern recognition built on successful experience points toward familiar solution types.

The Customer Conversation Problem

Most mechanical engineers in product-creating organizations talk to customers in a particular way. They discuss technical requirements: loads, tolerances, cycles, environments, materials. These conversations are valuable for specifying products. They are not designed to reveal the full job the customer is trying to do, including the stages of the job where the product is not the bottleneck.

I was working with a manufacturer of industrial pumps, a company full of exceptionally skilled fluid dynamics and mechanical engineers. Their customer conversations were technically precise. They knew exactly what their customers’ pumps needed to do. What they did not know — and had never systematically asked — was what happened before the pump started, while it was running, and after it stopped, in terms of the broader job of managing process fluid in a continuous production environment. When we mapped the full job and measured outcomes, the highest-opportunity items had almost nothing to do with pump performance. They related to predictive maintenance planning, integration with process control systems, and documentation for regulatory inspections. None of these were domains the engineering team had ever considered part of their product’s scope.

The Innovator’s Dilemma in the DACH Engineering Context

Christensen’s examples were primarily American: Sears, US Steel, disk drive manufacturers, minicomputer companies. The DACH engineering context is different in important ways that shape how the dilemma manifests.

DACH industrial manufacturers — particularly in the Mittelstand — are often engineering-founded and engineering-led multiple generations in. The founder’s engineering insight is embedded in corporate identity. Being an engineering-excellence company is not just a strategy; it is the culture, the source of pride, and the basis for almost all internal authority. This creates an organizational immune system that treats non-engineering innovations as foreign bodies.

When a product manager at such a company proposes a digital service offering, a connectivity platform, or a predictive analytics product, they are not just proposing a product extension. They are implicitly challenging the premise that mechanical engineering excellence is the primary source of value creation. The organizational response is often not explicit rejection — it is slower and more insidious. The proposal is studied, refined, piloted in limited scope, and gradually absorbed into the existing product architecture in a way that eliminates its disruptive potential.

This is the innovator’s dilemma as a cultural phenomenon: the organization does not fail to see the threat. It sees it clearly and then domesticates it until it is no longer threatening to the existing order.

What Makes Engineers Good at Innovation — When It Is Properly Directed

Here is the counterintuitive part of this analysis. Mechanical engineers are not bad at innovation. They are exceptionally good at a specific type of innovation, and that type happens to be the wrong type for addressing the most important market opportunities.

Engineers are superb at:

• Optimizing solutions within a defined problem space
• Evaluating solution candidates against objective criteria
• Identifying technical failure modes and designing around them
• Accumulating and applying domain-specific performance knowledge

These capabilities are invaluable for developing products once you know what to build. The problem is that they are poorly suited to the prior question: what should we build, and for which customers’ unmet outcomes?

The ODI framework, which I apply in my work at MYLES, is in part an attempt to give engineering-oriented organizations a rigorous, data-grounded method for answering the prior question — in terms that engineers can engage with on their own epistemological terms. When you can show an engineering team a quantified opportunity score for each of 120 customer outcomes, ranked by importance and satisfaction, engineers engage with it productively. They see a specification. They can evaluate which outcomes their existing capabilities address and which ones require capability development or new solution approaches.

This is the practical bridge between the Jobs-to-be-Done framework and engineering organizations: present customer outcomes as a specification, not as market research, and engineers know exactly what to do with it.

Case Example: The Crane Manufacturer Who Looked the Right Direction

A manufacturer of mobile cranes — a company with 50+ years of engineering history, deep expertise in structural mechanics, hydraulics, and lifting control systems — was facing a characteristic pattern. Their cranes were technically excellent. Market growth was flat. Chinese competitors were winning price-sensitive tenders. The product team’s instinct was to invest in a next-generation control system with higher precision and faster response times — a genuine technical advancement that would have taken 4 years and €8M to develop.

Before committing, they agreed to run an outcome-mapping exercise on the job of the crane operator and site manager. The job, defined properly, was: “coordinate the movement of materials and equipment on a construction site to meet project schedule and safety requirements.” This is broader than “operate a crane.”

The quantitative survey of 240 customers across construction site managers, crane operators, and fleet owners revealed a striking picture. The outcomes with the highest opportunity scores — those rated most important and most underserved — clustered almost entirely in two areas:

1. Planning and coordination: minimizing delays caused by crane unavailability during critical project phases, minimizing the time to reschedule lifts when site conditions change unexpectedly.

2. Compliance documentation: minimizing the time and effort to compile inspection records and operating logs for regulatory audits.

Neither of these areas had anything to do with crane performance specifications. The crane did what it needed to do mechanically. The unmet needs were organizational and informational.

The product innovation that followed was not a next-generation crane. It was a fleet management and compliance documentation platform that integrated with the existing crane telemetry and reduced both coordination overhead and documentation effort significantly. Development cost: €1.2M over 18 months. The new revenue model — subscription-based, per-machine — created recurring revenue that the hardware-only model never had. See our work on innovation management in enterprise for more on this type of platform transition.

The Path Forward: Engineering Organizations That See Clearly

The innovator’s dilemma is not inevitable. Engineering organizations that have learned to apply their analytical rigor to the customer’s job — not just to the product’s performance — have demonstrated that they can combine engineering excellence with genuine market insight.

The organizational changes required are not dramatic. They are specific:

Separate the “what to build” question from the “how to build it” question. The engineering organization is appropriately authoritative on the second question. It should not drive the first. Create explicit organizational space where customer outcomes are defined and prioritized by a cross-functional team before the engineering design process begins.

Invest in outcome research as seriously as you invest in engineering research. A company that spends €5M per year on materials and testing laboratories and zero on systematic customer outcome research is making an implicit statement about where it believes value comes from. That statement becomes a self-fulfilling prophecy.

Train engineers in the ODI outcome syntax. Engineers who understand how to write and evaluate outcome statements — not feature requests, not technical specifications, but solution-agnostic desired outcomes — can participate productively in customer insight activities. They bring technical grounding to what is otherwise an abstract customer research exercise.

Make innovation portfolio allocation visible. Most engineering organizations invest overwhelmingly in sustaining innovation — improving existing products on established performance dimensions. Making this allocation explicit, and setting targets for exploratory innovation investment, is the first governance step toward addressing the innovator’s dilemma at an organizational level. Our work on innovation in the DACH region covers how leading manufacturers are structuring this governance.

The most dangerous sentence in an engineering-led product organization is “we already know what our customers need.” It is dangerous not because the engineering team is wrong about the performance specifications — they are usually right. It is dangerous because it forecloses the investigation of the 40% of the customer’s job that the product does not currently address, and that is precisely where the next competitive advantage is hiding.

Frequently Asked Questions

The innovator’s dilemma is not an external force that happens to engineering companies. It is a systematic bias built into how engineering organizations think, decide, and invest. Recognizing it is the first step. The second step — building the customer insight capability and organizational processes to counteract it — is where the real work begins.

Engineering excellence is worth preserving. But it needs to be directed by customer evidence, not protected from it.