AI in PLM: Why Product Lifecycle Intelligence Is the Next Evolution of PLM 

Artificial intelligence has become impossible to avoid. Every major PLM vendor is adding AI capabilities to its portfolio, analysts are predicting a new wave of productivity, and manufacturers are looking for practical ways to apply AI across engineering, manufacturing and service. 

It is tempting to see this as the next chapter of Product Lifecycle Management, but I think the picture is slightly different. Much of today’s discussion around AI in PLM focuses on new capabilities. The more important shift is happening elsewhere: manufacturers are changing what they expect Product Lifecycle Management to deliver. 

PLM was built to manage products. Now it is expected to support decisions. 

When Product Lifecycle Management became mainstream, it solved a problem every engineering organisation recognised. Product information was fragmented. Design files lived in different systems, engineering changes were difficult to trace, and teams often worked with outdated documentation. As products became more sophisticated, those issues became impossible to manage without a structured environment. 

PLM changed that. It introduced governance, version control and a single source of truth for product information. For many manufacturers, it became one of the most valuable technology investments they made over the last two decades. 

That hasn’t changed – what has changed is the environment around it. 

Modern products combine mechanics, electronics, embedded software, connectivity and, increasingly, AI. Development teams are spread across multiple sites and suppliers. Regulatory requirements continue to grow. A single engineering change can ripple across manufacturing, quality, procurement, service and compliance before a product ever reaches the customer. 

Managing information is still essential, but it is no longer enough. Engineering leaders are asking different questions today than they were ten years ago. 

Not: 

• „Where can I find the latest product definition?” 

More often: 

• „If we make this change, what else will it affect?” 

Those are fundamentally different questions. The first is about access to information. The second is about understanding relationships. That difference is easy to overlook because both questions begin with the same data. Yet they require very different capabilities. 

Consider a supplier replacing one material with another. Finding the latest specification is straightforward. Understanding the consequences is not. Does the change require additional testing? Does it affect manufacturing parameters? Are there products already installed in the field that need attention? Will documentation submitted to regulators need updating? 

No single system contains all of those answers. They emerge only when information from different parts of the lifecycle can be understood together. That shift in expectation explains why conversations about Product Lifecycle Intelligence (PLI) have become more common over the last few years. Despite the name, PLI is not about replacing PLM with another platform. It reflects a broader change in thinking. 

AI didn’t create the problem. It exposed it. 

Many conversations about AI in PLM begin with copilots, intelligent search or automated documentation. Those capabilities matter, but they don’t explain why some organizations succeed while others struggle to move beyond isolated pilots. Questions we need to start asking include: 

• Can it summarise technical documents? 

• Can it search engineering records in natural language? 

• Can it generate requirements or suggest design improvements? 

Those capabilities are useful. Some already deliver measurable productivity gains. What they don’t explain is why two manufacturers using similar AI tools often achieve very different outcomes. The answer is usually less about the AI itself than about the environment in which it operates. 

Anyone who has worked with a mature PLM landscape knows that valuable product knowledge rarely sits in one place. Requirements may live in ALM, product structures in PLM, manufacturing information in MES, supplier records in ERP, quality data in QMS and service history somewhere else entirely. 

Individually, each system does its job well. Collectively, they tell the story of the product. The difficulty is that those connections are often obvious to people but invisible to software. 

An experienced engineer knows that a field issue reported by a service technician may be related to an engineering change approved months earlier. They know where to look, who to ask and which decisions provide the missing context, but AI? AI has no such intuition – it can only work with the relationships that already exist in the underlying product knowledge. 

That is why some AI initiatives scale quickly while others remain limited to isolated pilots. The difference is rarely the language model. More often, it is the quality of the product context surrounding it. And that changes the conversation. 

The question is no longer whether manufacturers have enough product data, since most already do – the actual, more important question is whether that data tells a connected story. 

Product Lifecycle Intelligence starts with connections, not algorithms 

If AI has exposed the limitations of disconnected product knowledge, the obvious question becomes: what needs to change? 

The instinctive answer: better AI 

A more useful answer: better context 

Think about how engineering decisions are made today. Rarely does one person make a decision based on a single document. Instead, they combine information from multiple sources. They review requirements, compare design revisions, check manufacturing constraints, consider previous quality issues and, if necessary, speak to colleagues who understand the history behind the product. 

In other words, they don’t just collect information – they connect it. That is the principle behind Product Lifecycle Intelligence. 

Rather than treating product data as a collection of individual records, PLI focuses on the relationships between them. A requirement is linked to the software that implements it. The software is linked to the hardware it runs on. That hardware is connected to manufacturing processes, supplier information, test results and products already operating in the field. The value lies less in the individual records than in the chain they create. 

Imagine a customer reports an unexpected failure in the field. Finding the service report is easy. The real challenge is understanding what happened before that product ever reached the customer. Which requirement introduced the functionality? Which engineering change modified it? Which software version was installed? Was the affected component supplied by a different vendor? Were similar issues identified during validation but considered acceptable at the time? 

Answering those questions manually may require several teams and multiple systems, but answering them quickly can determine whether a company resolves the issue in hours or in weeks. 

That is why Product Lifecycle Intelligence should not be seen as another software category sitting alongside PLM. It is better understood as the next stage in its evolution. The role of PLM is expanding from managing product information to helping organisations reason about it. 

Consider a manufacturer receiving reports of an unexpected product failure in the field. The immediate question is rarely what failed. It is why, how many products could be affected and what should happen next. 

Without connected product context, engineering, quality, service and manufacturing teams often spend days piecing together information from PLM, ALM, ERP, QMS and service systems. They need to understand which requirement introduced the affected functionality, which engineering change modified it, which software version was released, whether the same supplier was involved and whether similar issues have already occurred. 

Product Lifecycle Intelligence does not replace that investigation. It accelerates it by making those relationships visible. The real value is not simply finding the data faster, but reducing the time needed to assess the impact, understand the scope of the problem and make confident decisions. 

Why the Digital Thread matters more than ever 

This is also why the conversation inevitably leads to the Digital Thread.  

For years, the Digital Thread has often been described as a way to connect engineering systems. While that is true, it only explains part of its value. 

• Connecting systems is a technical achievement. 

• Connecting knowledge is a business capability. 

A Digital Thread preserves the relationships between information as a product moves through its lifecycle. It links decisions made during concept development with engineering changes, manufacturing execution, software releases, quality events and service activities. Instead of treating each stage as a separate process, it creates continuity across them. That continuity becomes increasingly valuable as products become more software-defined. 

Consider an over-the-air software update for an industrial machine. On the surface, it appears to be a software release. In reality, it may influence operating procedures, maintenance schedules, regulatory documentation, spare parts planning and customer support. Viewed through the lens of individual systems, those activities belong to different departments. Viewed through the Digital Thread, they are all consequences of the same product decision. That distinction matters because AI does not create context on its own. 

An AI assistant can summarise thousands of documents in seconds, but it cannot infer relationships that do not exist. If engineering data, software configurations, manufacturing records and service history remain disconnected, the model has no reliable way of understanding how they influence one another. The more complete the Digital Thread, the richer the context available to both people and AI. 

That is why organisations investing in Product Lifecycle Intelligence are not simply preparing for more sophisticated AI. They are building an environment in which both humans and technology can make decisions based on the same connected understanding of the product. 

The organisations that benefit most from AI usually did something else first 

It is easy to assume that the next competitive advantage in manufacturing will come from adopting more advanced AI models. In practice, many organisations discover that AI delivers the greatest value only after they have strengthened the foundations beneath it. 

The organisations making the greatest progress with AI are rarely those that started with AI. More often, they spent years building the foundations that make AI useful: improving data quality, establishing governance, connecting engineering disciplines and creating a trusted Digital Thread across the product lifecycle. 

Those investments were not originally made with generative AI in mind. They were made to improve engineering efficiency, accelerate product development and reduce the risk of costly mistakes. Today, they serve another purpose: to provide the context that AI can depend on, which is an important distinction, since it changes how manufacturers should think about their next investment. 

If product knowledge remains fragmented, adding another AI application is unlikely to solve the underlying problem. It may help individuals work faster, but it will struggle to improve decision-making across the organisation. Conversely, when product knowledge is connected and traceable, AI becomes significantly more valuable because it can reason across the product lifecycle rather than within isolated datasets. 

This is why discussions about Product Lifecycle Intelligence are becoming increasingly relevant. Not because PLI introduces a completely new technology stack, but because it reflects a different expectation of what modern PLM should deliver. For years, success was measured by the ability to capture, govern and distribute product information. Increasingly, success will be measured by something else. 

• How quickly can an organisation understand the impact of a decision? 

• How confidently can it assess risk before implementing a change? 

• How effectively can engineering, manufacturing and service teams work from the same product context? 

Those questions define Product Lifecycle Intelligence far better than any technical definition. 

The value of Product Lifecycle Intelligence 

Ultimately, organisations do not invest in Product Lifecycle Intelligence simply to connect more product data. They invest in improving the quality and speed of product decision-making across engineering, manufacturing, quality and service. 

When product context is connected and accessible, organisations are better positioned to: 

• assess the impact of engineering changes more quickly, 

• detect quality issues before they become costly field failures, 

• shorten product failure investigations by tracing relationships across the lifecycle, 

• identify regulatory and supplier risks earlier in the development process, 

• create the trusted product context needed to scale AI beyond isolated pilot projects. 

The value of Product Lifecycle Intelligence is not measured by the amount of information it stores, but by the quality and speed of the decisions it enables. 

PLM isn’t becoming less important. It’s becoming more ambitious. 

Every major technology shift changes the role of existing systems. Cloud computing didn’t eliminate ERP – it changed how organizations expected ERP to be delivered. Digital transformation didn’t replace PLM – it expanded the number of business processes that depended on it. 

AI is following a similar path. The future of AI in PLM will depend less on the sophistication of AI models and more on the quality of the product context available to them. The technology itself is advancing at remarkable speed, but its long-term value in manufacturing will depend less on the sophistication of individual models than on the quality of the product knowledge they can access. 

That is why the conversation is gradually moving beyond AI features and copilots. The more interesting question is whether organizations have created an environment where AI can understand products, not just documents. 

Product Lifecycle Intelligence represents that shift. It is not a replacement for Product Lifecycle Management, but it is what Product Lifecycle Management is evolving towards. 

Explore the next stage of PLM 

If your organization already has a mature PLM environment but is struggling to move AI beyond isolated use cases, the challenge may not be the technology itself. It may be the way product knowledge is connected across the lifecycle.