How Should IT and Product Engineering Work Together in the AI Era?

What is the right relationship between IT and product engineering?

In an AI-ready organization, IT provides the secure, reusable foundations for digital work, while product engineering teams own the specialized solutions and workflows of their domain.

IT should not have to translate and deliver every calculation, data flow or AI application requested by engineering. Engineering should not have to bypass IT with unsupported spreadsheets, scripts and tools in order to move quickly.

The effective model combines central enablement with distributed ownership:

• IT owns shared platforms, cybersecurity, enterprise architecture, core-system interfaces and common engineering standards.
• Engineering domains own the problems, workflow design, product context, adoption and long-term operation of domain-specific solutions.
• Cross-functional teams combine engineering knowledge with software and data capability close to the work.

This relationship is increasingly important because generative AI makes software development part of everyday engineering improvement. The old boundary—engineering specifies, IT implements—cannot handle the required speed or specialization.

Why does the traditional IT delivery model struggle in product engineering?

Most corporate IT organizations were designed to deliver reliable enterprise services through centralized governance and formal project processes. That model works well for capabilities that are common across the company, require strong standardization or carry significant enterprise risk.

Product engineering contains a different class of digital problem. Calculations, validation methods, design rules and development workflows are specific to the product and physical domain. Requirements evolve as engineers learn. A useful solution often emerges through rapid iteration with the people doing the work.

When every improvement becomes an IT request, three problems appear.

First, demand exceeds central capacity. Engineering teams wait weeks or months for small integrations and workflow changes.

Second, context is lost in translation. The people implementing the solution are separated from the assumptions, exceptions and physical constraints that determine whether it works.

Third, delivery becomes project-based. A solution is handed over after launch even though the engineering process continues to evolve.

The result is predictable: engineers create local workarounds because the official delivery path cannot respond at the speed of the problem.

Why can’t engineering simply build everything itself?

Unmanaged decentralization replaces one bottleneck with a larger structural problem.

Engineering teams naturally reach for spreadsheets, local scripts, specialist software and now AI-generated applications. These tools may solve an immediate need, but without shared practices they create security gaps, duplicated data, incompatible solutions and dependence on individuals.

AI makes this risk more urgent. It lowers the barrier to creating software, but it does not automatically provide architecture, testing, access control, lifecycle management or operational ownership. A solution can be produced quickly and still be unsafe or impossible to maintain.

Autonomy therefore cannot mean “everyone builds whatever they want.” It means teams can act quickly within a system that makes the safe and reusable approach the easiest approach.

What should IT own?

IT should own the foundations that benefit from enterprise consistency and specialist technical expertise.

Shared digital platforms

Provide approved environments where teams can build, deploy and operate applications, data flows and AI solutions without assembling infrastructure from scratch.

Security and access guardrails

Define how identities, permissions, sensitive product information, suppliers and external AI services are handled. Build controls into the platform so compliance does not depend on repeated manual approval.

Core-system connectivity

Make important data and functions from PLM, PDM, ERP and other enterprise systems available through secure, documented and discoverable interfaces.

Common engineering standards

Define practical expectations for source control, testing, documentation, monitoring, support and retirement according to the risk of the solution.

Enterprise architecture and reuse

Identify duplicated capabilities, maintain shared patterns and help teams build on existing services rather than creating another isolated solution.

Enablement and specialist support

Provide coaching, reusable templates and expertise for engineering teams. Success is measured partly by how effectively domains can deliver for themselves.

In this model, governance shifts from controlling every delivery decision to creating an environment in which good decisions are repeatable.

What should product engineering own?

Engineering domains should own the digital capabilities that are inseparable from their product and process knowledge.

The operational problem and outcome

The domain defines what must improve and how success will be measured—for example, reducing simulation preparation time, improving requirements quality or accelerating engineering change assessment.

Workflow design

Engineers determine how work should flow, which decisions require human judgment and where automation or AI can assist. Technology should not fossilize a poorly understood process.

Product and engineering meaning

The domain remains accountable for assumptions, units, physical constraints, acceptance criteria and the correct interpretation of engineering information.

Product ownership of the solution

A named owner prioritizes improvements, coordinates users and remains accountable after the first release. The solution is managed as a continuing product, not a finished IT project.

Adoption and operational performance

Engineering leadership ensures the new workflow is used and that it improves lead time, quality, cost or capacity. A technically deployed solution is not automatically an operational success.

Responsible use within guardrails

Teams follow shared standards, protect sensitive information, document critical logic and contribute reusable improvements back to the wider organization.

Ownership moves closer to the domain, but accountability becomes stronger rather than weaker.

How should responsibilities be divided in practice?

The boundary should follow the nature of the capability, not the organizational history.

Capability	IT leads	Engineering leads
Identity, security and access	Enterprise controls and implementation	Correct domain access and usage
PLM, PDM and ERP foundations	Platform reliability and interfaces	Product meaning and workflow requirements
Shared development platform	Tooling, templates and operation	Adoption and domain use
Domain application or AI workflow	Technical enablement and assurance	Product ownership and operational outcome
Engineering data	Integration and governance mechanisms	Meaning, quality and appropriate use
Software practices	Standards, coaching and reusable patterns	Compliance and day-to-day execution
Scaling a successful solution	Enterprise reuse and platform support	Domain expertise and continued ownership

The exact split will vary by company and risk level. What matters is that every capability has an explicit owner and a clear route from idea to operation.

What does an effective engineering team look like?

The required capability does not need to take the form of a large new department.

A domain such as simulation, validation or systems engineering may have a small product-oriented team combining:

• an engineering product owner who understands the workflow and desired outcome;
• domain engineers who supply physical and process expertise;
• software or data specialists embedded in or dedicated to the domain;
• access to IT platform, architecture and security support;
• representative users who provide rapid feedback.

The team owns a defined workflow or digital product over time. It can release incremental improvements rather than waiting for a multi-year project. It uses shared foundations rather than constructing its own infrastructure.

This arrangement preserves the closeness of local problem solving while making solutions reliable and reusable.

How can IT provide governance without becoming a bottleneck?

Traditional governance often relies on reviews and approvals performed separately for each project. As the number of small digital solutions grows, this model cannot scale.

AI-ready governance moves repeatable decisions into the platform and delivery process.

Examples include:

• pre-approved development environments and AI services;
• reusable patterns for accessing product data;
• automated security and quality checks;
• risk tiers that apply stronger controls to safety-critical solutions;
• standard ownership and support requirements before production use;
• visible catalogs of approved interfaces, data and reusable components;
• lightweight architecture support available early rather than a late approval gate.

This is governance by enablement. Teams move faster because many requirements have already been solved once and built into the path they use.

What changes for IT leadership?

IT remains essential, but its measure of success expands.

In addition to reliability, cost and risk, IT must consider the time it takes an engineering team to deliver a safe digital improvement. A platform that is technically capable but difficult to access does not enable the business. An interface that exists but cannot be discovered or understood is not truly reusable.

IT also moves from owning every application to stewarding an ecosystem. It establishes common foundations, observes where teams struggle, turns repeated needs into platform capabilities and helps successful domain solutions scale.

This requires product thinking inside IT. Engineering teams are customers of the internal platform, and their ability to deliver is an important platform outcome.

What changes for engineering leadership?

Engineering leaders can no longer treat software, data and AI as services that someone else delivers.

If a workflow is central to product development, the engineering function must own its digital evolution. That includes funding product ownership, developing internal capability, following software practices and accepting long-term responsibility for solutions.

Leadership must also distinguish useful experimentation from operational software. A local prototype can be informal. A solution influencing product decisions, quality or compliance requires appropriate engineering discipline, regardless of how quickly AI helped create it.

The new autonomy comes with an obligation to build for the organization rather than only the immediate team.

What does this model look like in a real workflow?

Consider a team that wants to reduce the manual effort required to prepare inputs for structural simulation.

Under a traditional model, engineering documents requirements and asks IT or a supplier to build an integration. Months may pass before the first version. Changes require another request, while engineers continue using spreadsheets and scripts.

Under unmanaged decentralization, an engineer creates a local AI-assisted tool. It works for one product line but uses exported data, personal credentials and undocumented assumptions. Other teams cannot safely adopt it.

In an enabled domain model:

1. Engineering owns the simulation-preparation workflow and outcome.
2. IT provides approved development tooling and governed interfaces to product and material data.
3. Embedded software and data capability works directly with simulation engineers.
4. Shared standards cover testing, access, deployment and support.
5. The team releases a small improvement, measures the result and iterates.
6. Useful interfaces and patterns become available to other engineering domains.

The solution is faster because ownership is close to the problem and safer because it uses enterprise foundations.

How should organizations make the transition?

Do not begin with a large reorganization or a general mandate for citizen development. Prove the model through a small number of important workflows.

1. Align leadership on the target relationship

Engineering and IT leaders agree which capabilities should be centralized, which should sit in domains and how success will be measured.

2. Select workflows exposing the current bottleneck

Choose problems where domain knowledge, system integration and frequent iteration are all required. Make the existing wait time and manual work visible.

3. Form cross-functional domain teams

Assign a long-term engineering owner, bring implementation skill close to the work and connect the team to IT platforms and specialists.

4. Establish a paved path

Provide approved tooling, interfaces, templates and risk-based controls. Remove repeated approval work wherever possible.

5. Capture and reuse what is learned

Turn recurring needs into platform capabilities. Share interfaces and patterns. Measure whether the next team can deliver faster.

The objective is not simply to complete the selected projects. It is to create a repeatable organizational mechanism for improvement.

What should an executive team decide first?

Bring the heads of product engineering, IT and transformation together and resolve five questions:

1. Which digital capabilities must engineering domains own to improve their work continuously?
2. Which foundations must remain common across the enterprise?
3. What can teams access through self-service today, and where do they still enter a queue?
4. Who owns domain solutions after the pilot or project ends?
5. Which engineering workflow will be used to prove the new model?

These decisions are more consequential than choosing the next AI platform. They determine whether the organization can turn any platform into sustained engineering value.

What are the implications for executive leadership?

• The relationship between IT and engineering is part of the engineering operating model.
• Central standards should increase team speed, not only control variation.
• Domain autonomy requires product ownership and software discipline.
• Platform investment should reduce the time from engineering need to operational improvement.
• External suppliers should strengthen internal capability rather than remain permanent intermediaries.
• AI governance must be built into reusable foundations so responsible adoption can scale.

AI does not eliminate the need for IT. It makes effective IT enablement more important. It also does not diminish engineering accountability. It expands that accountability to include the digital systems through which engineering work is increasingly performed.

Frequently asked questions

Is this the same as citizen development?

Not exactly. Citizen-development programs often focus on giving individuals low-code tools. The model described here gives engineering domains end-to-end ownership, appropriate specialist skills, shared platforms and long-term operational responsibility.

Does every engineering function need its own software team?

No. Capability can be embedded, shared across related domains or provided through a federated model. The essential requirement is fast access to implementation skill and clear ownership close to the engineering problem.

How do we prevent duplicate solutions?

Make existing interfaces and capabilities discoverable, require teams to build on shared foundations and use lightweight architecture support early. Some local variation is healthy; invisible duplication is not.

What if engineering does not want to own software?

Leadership must connect ownership to engineering performance. If a digital workflow is essential to developing the product, treating it as someone else’s responsibility leaves the function unable to improve its own operation.

Will decentralization increase cybersecurity risk?

It will if teams are left to choose their own infrastructure and controls. A governed self-service platform can reduce risk by replacing hidden local solutions with visible, supported and consistently controlled delivery.

Where should AI specialists sit?

Some specialist capability may remain central for research, standards and advanced support. Delivery teams should still include or have direct access to AI and data capability close to the domain, with engineering owning the operational result.

How should success be measured?

Track the time from idea to reliable deployment, adoption in the workflow, improvement in engineering outcomes, number of reusable capabilities created and reduction in unsupported local solutions—not only platform usage or project completion.

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.