Introduction
Over the years I have spent a significant part of my career around product development, engineering information and PLM.
And if there is one thing I have learned, it is this: PLM is one of the most important investments an industrial company can make.
It provides structure, governance, traceability and control. Without it, managing modern product development would be almost impossible.
Yet I have repeatedly seen organizations place expectations on PLM that no system could realistically fulfill.
Not because the technology was inadequate. Not because the implementation failed. But because the underlying problem was larger than the system itself.
Over time I started noticing a recurring pattern. Many companies were not struggling with a PLM problem. They were struggling with a product lifecycle problem.
The two are related. But they are not the same thing.
How PLM Became So Important
It is difficult to overstate what PLM has done for industrial companies.
Before PLM became commonplace, product knowledge was often scattered across departments, files, spreadsheets and individual experts. Product structures were difficult to trust. Engineering changes were hard to manage. Configuration control was inconsistent. Traceability was limited.
PLM changed all that.
For many organizations, it became the foundation of structured product development. Product definitions became visible. Changes became controlled. Information became easier to manage. Engineering became more scalable.
This success created something interesting. The more value PLM delivered, the more responsibility organizations began assigning to it.
Eventually, in some companies, the distinction between product development and product lifecycle began to blur. And that is where misunderstandings often begin.
The Product Is Larger Than Engineering
For a long time, I unconsciously viewed the product lifecycle through an engineering lens. Many of us do.
After all, engineering is where products are designed. Requirements become specifications. Specifications become solutions. Solutions become products. It feels logical to think that the lifecycle starts and ends there.
But eventually I realized that customers do not experience engineering. Customers experience products.
And products live much longer lives than engineering projects.
A customer need may trigger a requirement. That requirement may drive development. The resulting product may be sold, configured, manufactured, delivered, operated, serviced, upgraded and eventually replaced.
Somewhere during that journey, the customer decides whether the company created value or not.
That judgment is rarely based on engineering alone. It reflects the performance of the entire lifecycle.
The Three Products
One observation has shaped much of my thinking. Many organizations are actually managing three different representations of the same product.
THE PRODUCT AS DESIGNED
Requirements, architecture, parts, documents, configurations and changes. This is traditionally where PLM is strongest.
THE PRODUCT AS SOLD
The commercial offering: what customers can buy, how options are presented, how pricing is structured and how solutions are configured.
THE PRODUCT AS DELIVERED AND OPERATED
The individual product in the customer's environment, with its unique configuration, service history, software versions, upgrades and operational experience.
All three products are important. All three are connected. Yet many organizations manage them separately.
This is often where lifecycle friction begins.
When the Symptom Appears in PLM
Because PLM is so central to product development, many lifecycle problems eventually become visible there. And this can be misleading.
A company may discover that product structures have become difficult to maintain, configuration complexity is increasing, engineering changes take too long or traceability feels inadequate.
The natural conclusion is often: "We have a PLM problem."
Sometimes that conclusion is correct. But not always.
In many cases, the underlying cause exists somewhere else. The company may lack configuration governance. Ownership may be unclear. Commercial offerings may have evolved independently of product strategy. Engineering and service may have become disconnected. Product decisions may not have clear accountability.
These issues eventually affect PLM. But they do not originate in PLM.
The symptom appears there because PLM sits at the center of engineering information, not because PLM caused the problem.
Where Complexity Changes the Game
This becomes even more visible as products become increasingly configurable.
A simple product can often be described relatively easily. A complex industrial product is different.
Products now include physical variants, regional requirements, software options, connected services, feature subscriptions, regulatory adaptations and customer- specific configurations.
The challenge is no longer just defining a product. The challenge is maintaining consistency across thousands, sometimes millions, of possible outcomes.
And once complexity reaches that level, the lifecycle extends far beyond engineering.
Now sales decisions matter. Operational decisions matter. Service decisions matter. Software decisions matter. Customer usage matters.
PLM remains important. But the challenge itself has outgrown engineering.
The Sales Perspective
One question I often ask is surprisingly simple: can your sales organization reliably sell what your engineering organization has designed?
Many executives answer yes. Then the discussion becomes more interesting.
Can they sell it consistently? Can they explain it? Can they configure it correctly? Can they understand the consequences of what they are selling? Can they understand what should not be sold?
These questions are rarely answered by engineering systems alone.
Because sales operates in a different reality. Customers think in outcomes. Engineering thinks in solutions.
Somewhere between those two worlds sits product knowledge. The lifecycle depends on translating that knowledge accurately. That responsibility extends beyond PLM.
The Service Perspective
The same pattern appears after delivery.
Service organizations often need answers to questions such as:
- What was delivered?
- What software is installed?
- Which upgrades are possible?
- What options are active?
- What changes have been made since production?
Customers typically assume these answers are easy to obtain. Many organizations discover they are not.
The information exists. But it is scattered across multiple systems, processes and functions.
What appears to be a service challenge often originates much earlier. A decision made during product definition may influence maintenance costs years later. A configuration choice may affect a service technician on the other side of the world.
Again, the lifecycle extends beyond engineering. And beyond PLM.
Why This Matters Now
For years, organizations could partially tolerate these disconnects. The pace of change was slower. Products changed less frequently. Service models were relatively stable.
That world is disappearing.
Today products continue evolving after delivery. Software updates introduce new capabilities. Connected products generate operational data. Customers expect ongoing improvement. Engineering, sales and service are becoming increasingly interconnected.
As a result, lifecycle performance is becoming more important than departmental performance.
The competitive advantage is shifting. It is no longer enough to optimize engineering. Organizations must learn to optimize the lifecycle.
A Different Question
Perhaps one of the most valuable changes a leadership team can make is a surprisingly small one.
Instead of asking, "How do we improve our PLM environment?" ask, "How do we improve our product lifecycle?"
At first glance, the difference appears subtle. In reality, it changes the entire conversation.
Now we start discussing product definition, configuration, commercial offerings, manufacturing, service, operational learning and customer outcomes.
PLM remains a critical part of the answer. But it is no longer expected to be the whole answer.
Final Thoughts
PLM has transformed industrial product development. I have spent enough years around it to appreciate both its power and its importance.
But I have also learned that expecting PLM to become the product lifecycle places an impossible burden on the platform, the implementation team and the organization itself.
PLM helps manage product development. The product lifecycle is much larger.
It begins before engineering. It continues long after delivery. And it increasingly determines how effectively an organization can learn, adapt and compete.
Understanding that distinction is one of the most important steps an organization can take.
Because customers do not experience PLM. They experience the lifecycle.
And the companies that understand the difference are increasingly the ones that pull ahead.