Zero-Surprise Development in the Era of Software-Defined Products

Software-defined vehicles are forcing automotive OEMs to rethink how products are engineered and operated. Regulatory pressure is rising, architectures are shifting, and software now defines a growing share of vehicle value. At the same time, engineering organizations are expected to move faster, improve quality, and prepare for AI at scale.

The decisive question is no longer whether OEMs adopt software, but rather whether they can stay in control of the complexity that comes with it.

When Complexity Outpaces Organizations

For decades, automotive development was optimized for a relatively stable reality. Devices fulfilled well-defined functions. Responsibilities were clearly separated. Systems evolved incrementally, and organizations were structured accordingly.

That reality no longer exists.

Today, a single ECU supports multiple, interconnected functions across domains, vehicle lines, and lifecycle stages. Electrical systems, electronics, and software are tightly coupled. Features depend on one another across variants and generations, resulting in more technical and systemic complexity.

Failures are rarely isolated. Resolving issues requires coordination across disciplines, organizations, and suppliers. Communication paths multiply, ownership blurs, and progress slows simply because the organizational model was designed for a different world.

What initially appears as coordination overhead quietly turns into delayed SOPs, conservative architecture decisions, and lost optionality for digital revenue.

This pattern shows up clearly in SPREAD’s Engineering Intelligence Index 2025, a study based on interviews with senior engineering leaders across manufacturing industries in Europe and the United States:

• 75% spend at least one-third of their time on administrative work

• 67% lose significant time to issue resolution

• 64% struggle with product complexity on a daily basis

• More than half report collaboration friction

These are not isolated inefficiencies, but show symptoms of how engineering organizations currently operate.

Legacy Tool Landscapes in a Software-Defined Reality

Most OEMs have invested heavily in powerful toolchains: PLM, ALM, ERP, CAD, simulation, and domain-specific systems. Individually, these tools do what they were designed to do. The problem is that they were designed for a different engineering reality.

Traditional platforms assume structured handovers, stable architectures, and clear lifecycle stages. Vertical tools excel within domains, requirements, design, and testing, but lack context beyond them.

In software-defined vehicles, the real friction no longer sits within domains, but between them.

Despite decades of PLM investment, 71% of engineers still rely on Excel and 64% on PowerPoint for core workflows. These “shadow tools” have become the connective tissue between systems, teams, and lifecycle stages.  This points to a simple truth: the bottleneck is no longer missing functionality. It is missing coherence and context.

Data exists, but it is fragmented. Ownership is split across engineering, IT, production, and aftermarket. Traceability across domains is fragile. As a result, critical product decisions increasingly happen outside the systems of record.

CAN AI Alone Fix Fragmented Engineering?

AI is often presented as the answer to rising complexity. OEMs are piloting code generation, test automation, and documentation tools,  and the potential is real, but AI is constrained by the same fragmentation that slows engineers down. The limiting factor is not algorithms, but the lack of connected, contextualized product data. Engineering information is scattered across systems, formats, and abstractions, often disconnected from the actual product architecture.

Without product-level context, AI cannot reliably answer the questions that matter most:

• What will this change break?

• Where else is this function or signal used?

• Which vehicles and customers are affected?

• How do we validate this change across all variants?

As long as product data remains fragmented, AI stays confined to narrow, local use cases. The gap between AI ambition and operational reality is one of the most underestimated barriers in automotive R&D.

From Data to Understanding: A Shared Product Context

Regaining control does not require another point solution. It requires a shared understanding of the product that reflects how functions, components, software, and signals interact across the lifecycle.

Across OEM programs, four capabilities consistently prove decisive:

1. Reliable, centralized product data: Engineers need a trusted source of truth instead of constant reconciliation.

2. Flexible information structures: Rigid schemas fail as architectures evolve. Models must adapt to real engineering complexity.

3. Cross-domain and lifecycle traceability: Dependencies must be visible before changes propagate downstream.

4. AI that operates in context: AI becomes valuable only when grounded in product architecture and engineering semantics.

When these capabilities are in place, teams move from searching and coordinating to understanding and deciding. Dependencies become visible. Change impact becomes predictable. Root causes are traced across domains instead of rediscovered downstream.

This is the foundation of zero-surprise development.

Engineering Intelligence as a Control Layer

What many OEMs are missing today is not another system of record, but a horizontal engineering intelligence layer that connects what already exists into a coherent product view.

Such a layer does not replace PLM, ALM, or ERP. It connects them. It anchors vertical domain work in a shared, traceable understanding of the product as a system.

In practice, this enables:

• Impact assessment before changes propagate

• Cross-domain issue resolution instead of local fixes

• Governance of variant-heavy architectures without spreadsheets

• AI that reasons over the product, not isolated documents

At SPREAD, this concept is what we refer to as Engineering Intelligence: making complexity navigable by turning fragmented product data into shared understanding, and using that foundation to scale both engineering productivity and AI.

A Structural Advantage for First Movers

A clear divide is emerging.

Some OEMs treat product data architecture as strategic infrastructure. They align engineering, IT, production, and aftermarket around shared models and governance. These organizations report faster issue resolution, shorter change cycles, and AI programs that deliver real value.

Others continue optimizing local tools while leaving the underlying model untouched. In these environments, complexity compounds, and AI remains experimental.

As vehicles become increasingly software-defined, this gap turns into a structural performance advantage.

In the end, success in the software-defined era is not about eliminating complexity.
It is about building the data and architecture needed to master it, without surprises.