Why AI Transformations in Product Engineering Fail to Scale

Why do promising AI pilots produce so little operational impact?

AI transformations in product engineering fail to scale when companies introduce AI without changing the environment in which engineering work happens.

AI depends on connected data, understood workflows, interoperable systems and teams that can turn an idea into a reliable digital solution. Yet many product engineering organizations still operate through disconnected PLM, PDM, ERP, simulation and test environments. Spreadsheets, email and manual coordination fill the gaps between them.

Adding AI to this environment may help an individual complete a task faster. It may also produce an impressive demonstration. But it does not create an organizational capability. In many cases, it simply adds another isolated tool to an already fragmented engineering landscape.

The core problem is therefore not the AI technology. It is the operating model around it: how engineering and IT divide responsibility, how teams improve workflows, how information moves between systems and who owns the resulting digital solutions.

What does it mean when an AI transformation fails to scale?

Failure does not mean that nothing works. Most organizations can point to useful experiments, enthusiastic users and credible use cases.

The transformation has failed to scale when that activity does not materially change how products are developed across the organization. Typical signs include:

• AI copilots are available, but development lead time remains unchanged.
• Demonstrations work with manually prepared data but cannot use live engineering information.
• Design, simulation, testing, manufacturing and quality run separate initiatives.
• Engineers continue copying information between systems and reconciling versions by hand.
• AI outputs cannot be trusted because their source data and context are unclear.
• Solutions remain dependent on consultants, an innovation team or individual enthusiasts.
• No operational owner exists once the pilot budget ends.

The clearest warning sign is not an absence of pilots. It is a growing number of pilots alongside an unchanged engineering operating model.

Why is product engineering particularly difficult to transform?

Product engineering does not resemble finance, HR or sales. Those functions share many common processes across companies and have inherited generations of integrated enterprise platforms.

The work of an industrial engineering organization is much more specific. Its calculations, validation methods, design rules, physical constraints and regulatory obligations reflect the product it develops. PLM and PDM systems govern important records, but they rarely cover the complete engineering workflow. No software vendor can provide every specialized calculation, test process or design decision out of the box.

Engineers have always closed these gaps themselves. They built spreadsheets, macros, scripts, databases and file-based workflows because those were the practical tools available. These solutions often contain essential engineering knowledge, but they were rarely treated as organizational software. They may have no shared standards, automated tests, documented interfaces or long-term owner.

Over time, critical business logic becomes scattered across spreadsheet cells and individual laptops. Different functions create their own versions of product information. People learn whom to call and which file to use, but the organization itself cannot reliably find or reuse that knowledge.

This is not a failure of engineers. It is the predictable result of asking domain experts to solve digital problems without giving them the software practices, shared platforms and organizational support required to make their solutions scale.

Why doesn’t adding better AI fix the underlying problem?

AI cannot reliably automate a process that exists mainly in people’s heads. It cannot determine the authoritative version of a calculation when several copies circulate through email. It cannot coordinate work across systems that cannot exchange information. And it cannot safely reuse engineering data when products, materials, drawings, requirements and test results cannot be traced through common identifiers.

The dependency is straightforward:

1. AI value depends on reliable engineering workflows.
2. Reliable workflows depend on connected systems.
3. Connected systems depend on reusable, governed engineering data.
4. All three depend on clear ownership and digitally enabled teams.

AI amplifies organizational capability. It does not replace it.

Where workflows and data are strong, AI makes the organization faster. Where they are fragmented, AI makes those gaps more visible and can amplify unreliable information through incorrect or untraceable outputs.

Where do AI transformations usually break down?

Are we rolling out tools without deciding how engineering should work differently?

Many transformations begin with licenses, training and a list of use cases. Leadership encourages experimentation but does not define the engineering organization it wants to create.

That leaves fundamental questions unanswered. Should engineering teams own their digital workflows? What role should central IT play? Where should software and data skills sit? Who is accountable for connecting information across functions? Which engineering outcome is the investment expected to improve?

Without a target operating model, each function optimizes locally. AI becomes a collection of activities rather than a transformation.

The leadership question is not merely, “Where can we use AI?” It is:

If AI succeeds, what will our product engineering organization be able to do differently three years from now?

How much engineering work still depends on people moving information manually?

In many R&D organizations, engineers re-enter data between PLM, ERP, simulation, testing and manufacturing systems. They compare files, reconcile revisions, chase approvals and assemble reports from multiple sources.

In effect, people become the integration layer between systems and departments. This creates waiting time, duplicated effort and inconsistent information. It also places a hard limit on AI: individual tasks may become faster, but the end-to-end engineering process remains constrained by the same manual handovers.

Modernizing these workflows is not an optional cleanup exercise before the “real” AI work begins. It is what makes operational AI possible.

Can engineering teams improve their own digital workflows?

Central IT is usually designed to protect reliability, security and enterprise standards. Those responsibilities remain essential. But a delivery model based on requests, approvals and centralized projects struggles when digital improvement becomes part of everyday engineering work.

Highly specialized solutions require continuous input from the people who understand the product and process. When implementation is separated from that knowledge, delivery slows and requirements get lost. When teams bypass IT entirely, the organization accumulates more unsupported local tools.

The answer is neither complete centralization nor unmanaged decentralization. IT should provide secure platforms, reusable interfaces, standards and guardrails. Engineering teams should use those foundations to build and own domain-specific solutions close to the work.

Why do successful AI pilots still fail in production?

A pilot can avoid the conditions that make daily engineering difficult. Its data may be selected and cleaned manually. The use case may be narrow. Consultants or an innovation team may provide direct support. The demonstration may not need to integrate with production systems, satisfy long-term governance requirements or work across product variants and sites.

Scaling reintroduces everything the pilot temporarily removed.

A successful pilot proves	It does not prove
An AI model can perform a task	The engineering workflow can operate reliably
A use case has potential	The required data is reusable at scale
A small team can build a demonstration	Engineering teams can own the solution long term
AI can produce an output	Engineers can trust and act on that output
Value exists in one controlled context	The organization can reproduce the value elsewhere

This is why counting pilots gives leadership a misleading picture of progress. The important question is whether every initiative leaves behind a stronger workflow, better access to data and a capability another team can reuse.

What must change before AI can scale across engineering?

The AI-Ready Product Engineering Framework provides a four-phase modernization path. AI tooling is deliberately not the first phase; the earlier work is what allows it to produce durable value.

1. Agree on the destination

Leading question: What kind of product engineering organization are we trying to build?

Leadership must align on the role of AI, the future relationship between engineering and IT, where digital capabilities should reside and who owns engineering workflows. It must also connect the transformation to outcomes such as time-to-market, engineering cost, quality or iteration speed.

Without this shared destination, later initiatives remain isolated experiments.

2. Find where engineering work loses time and information

Leading question: Where do our teams wait, copy, reconcile, chase and re-enter information today?

Map the operational friction across important workflows. Look for manual handovers, inaccessible data, duplicate solutions, unclear ownership and delays caused by organizational boundaries. Then identify the three to five improvements in each engineering function that would make the greatest progress toward the target state.

This is more useful than collecting a long list of disconnected AI ideas.

3. Build capability by solving real engineering problems

Leading question: Which operational improvements create value now and a capability we can reuse later?

Use prioritized business problems to develop software and data skills inside engineering teams. Improve interoperability, clarify ownership and make important information reusable while solving an immediate operational constraint.

For example, a team could connect requirements, design decisions and validation evidence; automate the preparation of simulation inputs; or make test results reusable across product variants. The goal is both a better workflow today and a stronger organizational capability tomorrow.

4. Connect and reuse what works

Leading question: Can the next engineering team build on what the first team created?

Once teams can deliver reliable digital improvements, connect those capabilities through shared platforms, discoverable interfaces, common identifiers and reusable data flows. Each new solution should make the next one faster and less expensive to deliver.

This is where AI begins to compound. It can now work across connected information and workflows instead of remaining trapped inside individual tools.

What does an AI-ready product engineering organization look like?

An engineering organization is AI-ready when it can repeatedly turn AI opportunities into reliable improvements in day-to-day engineering work.

The evidence is operational:

• Leadership shares one direction for engineering modernization.
• Engineering teams can implement digital improvements without waiting months.
• IT enables those teams through governed, self-service foundations.
• Core systems make authoritative engineering data securely reusable.
• Product, drawing, material, requirement, simulation and test information can be connected.
• Workflows cross departmental boundaries without manual re-entry.
• Digital solutions have accountable, long-term owners.
• Capabilities created by one team can be reused by others.
• AI investments improve cycle time, quality, cost or engineering capacity.

AI readiness is not a maturity badge or a one-time technology program. It is an organizational ability to learn and improve faster.

What should an engineering executive do first?

Do not begin with another general call for AI use cases. Bring engineering, IT and transformation leadership together around one material engineering workflow and answer five questions:

1. Which business outcome are our AI investments expected to improve?
2. Which end-to-end engineering workflow constrains that outcome today?
3. Where do people manually connect systems or reconcile information?
4. Which team owns the workflow, and can it improve the workflow directly?
5. What reusable capability should the initiative leave behind?

Choose a workflow with visible business relevance and improve it end to end. A requirements-to-validation flow, engineering-change process, simulation workflow or transfer of product data into manufacturing planning will reveal more about organizational readiness than a generic demonstration.

The first move is not adopting more AI. It is deciding what kind of product engineering organization you intend to become.

What does this mean for engineering leadership?

• AI transformation belongs on the engineering operating-model agenda, not only the technology roadmap.
• Tool adoption and pilot counts are weak measures of business impact.
• Access to engineering data is a leadership concern, not merely an architecture concern.
• The responsibilities of IT and engineering must be redesigned explicitly.
• Personal productivity gains and organizational transformation should be measured separately.
• Every initiative should improve an engineering outcome and leave behind reusable capability.

Organizations with digitally enabled teams, connected workflows and reusable data become faster with every improvement. Organizations that continue layering tools onto fragmented operations run pilot after pilot and remain roughly where they started. Over time, the distance between them widens on its own.

Frequently asked questions

Do we need to modernize every engineering system before using AI?

No. Start with valuable workflows rather than attempting a complete systems replacement. But design each improvement to reduce fragmentation, clarify ownership and create foundations that other teams can reuse.

Is our PLM system supposed to provide the AI foundation?

PLM is an important authoritative source, but it rarely covers the complete engineering workflow. The broader requirement is governed access to information across PLM, PDM, ERP, simulation, testing, manufacturing and locally developed systems.

Should AI capability sit in engineering or central IT?

Responsibilities should be shared but distinct. IT provides platforms, security, interfaces and guardrails. Engineering teams own domain-specific workflows and the solutions built on those foundations.

Can external consultants accelerate the transformation?

Yes, provided they help internal teams build reusable capabilities. A solution that remains dependent on its supplier has delivered a project, not organizational AI readiness.

How should we measure progress?

Measure engineering outcomes: lead time, iteration speed, manual effort, quality, reuse and the time from an improvement idea to a reliable deployed solution. Licenses, training completion and pilot counts measure activity, not transformation.

Are spreadsheets always a problem?

No. They remain useful for exploration and individual analysis. They become a structural risk when they serve as undocumented production systems, authoritative data stores or permanent integration mechanisms.

What is the first sign that we are becoming AI-ready?

Teams can deliver a useful digital improvement faster because they can access governed data, reuse existing capabilities and implement within clear organizational guardrails.

References

1. Kevin Pilch, The AI-Ready Product Engineering Organization: How Industrial Companies Need to Rethink Product Engineering for the AI Era, Version 1.3, June 2026.
2. McKinsey & Company, Software-defined hardware in the age of AI.
3. McKinsey Global Institute, The economic potential of generative AI: The next productivity frontier.
4. DORA Research, 2025 State of AI-assisted Software Development.
5. Niels Pfläging, Complexitools: How to (re)vitalize work and make organizations fit for a complex world.