Is Product Memory Just a New Name for PLM?

Product Memory extends traditional Product Lifecycle Management (PLM) by preserving connected product knowledge across engineering, manufacturing, supply chains, APIs, and AI systems. Let’s talk about it today. 

Understanding the Next Evolution of Product Lifecycle Knowledge

Recently someone commented on one of my articles: “Product Memory is just a new name for PLM. We already talked about this twenty years ago.”

I sat with that comment for a while before responding.

Because honestly? At first glance, it’s a fair reaction. If you go back to the original vision of Product Lifecycle Management, the ambition was genuinely expansive. PLM promised to organize product information across the entire lifecycle — from early design concepts through manufacturing and into service — and make it available to every team that needed it. It was supposed to be the digital backbone of a product company.

So in that sense, the commenter is not entirely wrong. The original PLM vision did include many of the ideas we now associate with Product Memory. There is real conceptual overlap.

But that is also exactly where the comparison stops being useful.

The real question is not what PLM presentations promised twenty years ago. The real question is what capabilities companies actually received when the implementations were done, the consultants went home, and engineers tried to use these systems to build real products.

Because the gap between that aspiration and the operational reality is precisely where the concept of Product Memory comes from.

What Is Product Memory?

Before going deeper, it helps to state the concept clearly.

Product Memory is the structured, connected, and reusable knowledge about a product accumulated across its lifecycle, preserved in a way that people, systems, and AI can continuously access and interpret. The scope of this product memory is contextual, it can be used in different ways for product development, ideation, engineering, production planning, maintenance, etc. It is not limited to a single system, database, or storage. 

Traditional Product Lifecycle Management (PLM) systems focus primarily on managing product data — files, revisions, workflows, and release states. Product Memory focuses on preserving the relationships, decisions, context, and dependencies that make that data meaningful.

In other words, Product Memory is not just about storing product information. It is about preserving the understanding of a product as it evolves over time.

What Traditional PLM Systems Actually Delivered

Over the past two decades, PLM systems became essential infrastructure for serious engineering organizations, mostly enterprise organization, but also some sizable SMEs with complex products. I have no interest in dismissing that. Companies used PLM to manage CAD files, track revisions, control releases, and run engineering change processes. For organizations building complex products — aerospace, automotive, industrial equipment — those capabilities are not optional. You cannot function without some form of lifecycle data management.

At the same time, many companies rejected the idea of PLM (software), but implemented their own DIY “PLM systems” made of spreadsheets, cloud drives, document systems, collaborative tools and other services. These days, with the introduction of AI, the capabilities of these DIY implementations are skyrocketing and the distance between “original PLM software” built on top of 1990s SQL architecture and modern tech stack is growing. 

But here is what I observed, again and again, working inside and alongside product companies: what organizations ultimately received were sophisticated systems of record.

PLM systems became very good at answering a specific category of question. Where is the official CAD file? Which revision is currently released? What workflow approved this change? Which document is attached to this part number?

These are genuinely important questions. Governance and control matter. But anyone who has spent time working inside a product company knows that engineers, manufacturing teams, procurement specialists, and program managers are constantly asking a completely different set of questions.

What actually changed in the product structure between revision 4 and revision 5? Why did we switch this supplier two years ago — was it cost, availability, or a quality problem? Which alternative components exist if our primary source goes on allocation? What downstream manufacturing processes depend on this part, and what will break if we change the geometry? What cost implications follow from this design decision? What should the factory expect to receive next quarter? What service parts failed from the products we shipped last year? Why did we change the suppliers two years ago?

These questions are not about retrieving files or confirming revision status. They are questions about understanding the product — its structure, its history, its dependencies, its reasoning.

And that is where the gap appears.

The Gap Between Product Data and Product Knowledge

Even in companies that have implemented PLM successfully — and I mean organizations with mature processes, trained users, and years of discipline — product knowledge is still scattered across a surprising number of places. I addressed it in my article – Context Graphs: PLM Beyond System of Records.

Some of it lives in CAD files. Some in BOM spreadsheets that nobody quite trusts but everyone uses. Some in ERP systems, locked inside transaction records that are hard to query meaningfully. Some in supplier portals that the engineering team barely knows exist. Some in email threads from three product generations ago. Some in Slack channels that will disappear the next time someone leaves the company. And a meaningful amount of it lives in the heads of two or three engineers who were around when the decision was made and remember why.

When people talk about “product data chaos,” this is usually what they mean. Not that data does not exist — there is actually enormous amounts of data in most product companies. The problem is that the knowledge connecting that data is fragile, inconsistent, and constantly at risk of being lost.

The reasoning behind a component selection vanishes after a project wraps up and the team disperses. The context of an engineering change gets buried in a one-line workflow comment. The supplier alternatives that someone researched carefully get logged in a spreadsheet nobody updates. Decisions that took months to reach become tribal knowledge — accessible only to the people who were in the room.

Organizations store product information. But they do not reliably preserve product memory. That distinction matters more than it may initially appear.

What Product Memory Means for Engineering and Product Lifecycle Management

Product Memory is not a new way to store product data. It describes something more specific — and, I would argue, more important.

Product Memory is the structured, connected, and reusable knowledge about a product accumulated across its lifecycle, preserved in a way that people, systems, and AI can continuously access and interpret.

Notice the difference from what PLM typically delivered.

PLM focused primarily on managing information. Product Memory focuses on preserving knowledge. Those sound similar, but they require completely different system designs.

Information can be stored. Knowledge must be connected — to related decisions, to alternatives considered, to the reasoning that led somewhere.

Information can be archived. Knowledge must remain understandable over time — across team changes, product generations, and evolving contexts.

Information can sit inside a system of record. Knowledge must travel across systems, teams, and decisions — it has to be accessible where work actually happens.

This distinction becomes sharper as products become more complex and organizations become more distributed. A team of twenty engineers building one product in one location can survive on tribal knowledge and shared context. A global organization running dozens of product lines with rotating teams and dispersed supply chains cannot. The knowledge architecture has to carry the load that informal memory used to carry.

Why Product Memory Matters for Modern Product Development

The environment in which product companies operate has shifted dramatically over the past decade, and not in ways that make this problem easier.

Products are no longer purely mechanical artifacts. Almost everything combines hardware, electronics, embedded software, and — increasingly — connected services that update in the field. Supply chains span continents and involve suppliers who themselves have complex sub-tier networks. Engineering teams are distributed across multiple companies and time zones. Product updates happen on continuous cycles rather than once every few years.

Under these conditions, the traditional lifecycle model — design, release, manufacture, done — no longer captures the reality of product development. Companies operate in a world of continuous iteration, where changes happen faster, dependencies multiply, and a decision in one part of the product can ripple through the entire system in ways that are genuinely hard to track.

I have seen organizations spend weeks reconstructing the reasoning behind a design decision they made eighteen months earlier because the engineer who made it had moved on, the documentation was incomplete, and the system only stored the outcome — not the thinking.

Storing product data is not enough anymore. Teams need to preserve the context of decisions and relationships so that knowledge does not disappear as projects evolve and people change roles. That is the operational challenge Product Memory is trying to address.

Ten Principles of Product Memory in Modern Product Development

If Product Memory were simply a rebranding of PLM, it would not require a different set of design principles. But when you examine seriously what it takes to preserve product knowledge across time, teams, and systems, a different set of ideas emerges.

1. Product Memory is about knowledge, not just data. Data can exist in many places — files, databases, spreadsheets, systems. Memory begins when that information is structured in a way that preserves meaning and relationships, not just values.
   
2. Product Memory must persist across time. Products evolve through revisions, releases, and changes over years. Product Memory must preserve not only the current state but also the reasoning and context that produced that state — otherwise future teams are flying blind.
   
3. Product Memory connects structures, not isolated objects. A product is not a collection of independent files. It is a network of relationships between parts, documents, suppliers, requirements, and decisions. Understanding a product means preserving those relationships.
   
4. Product Memory must survive organizational boundaries. Product knowledge does not belong exclusively to engineering. Procurement made sourcing decisions. Manufacturing translated design intent into process. Service teams discovered failure modes. Memory has to extend across all of those boundaries.
   
5. Product Memory preserves context, not just status. Knowing that a component is approved is useful. Knowing why it was selected, what alternatives were considered, and what trade-offs were accepted is far more valuable — especially when you revisit that decision years later under different constraints.
   
6. Product Memory must be reusable. If organizations must rediscover the same information in every new project, the knowledge has not truly been preserved. Product Memory allows teams to reuse decisions, proven patterns, and validated structures rather than starting from scratch.
   
7. Product Memory must be accessible through APIs. If knowledge only exists inside application screens, it stays trapped. APIs allow product knowledge to flow across systems, integrations, automation workflows, and services.
   
8. Product Memory must be understandable by machines. Modern product development increasingly relies on automation, digital workflows, and intelligent assistance. Machines need to be able to interpret product relationships and dependencies.
   
9. Product Memory must support decisions, not just compliance. Systems of record help enforce control and process governance. Product Memory should help teams understand consequences, evaluate options, and make better decisions.
   
10. Product Memory compounds over time. The value of Product Memory increases as more knowledge accumulates and becomes reusable across engineering, sourcing, manufacturing, and service operations.
    

Why Product Memory Is Foundational for AI in Engineering

One reason this concept is getting more attention right now is the rapid emergence of AI in engineering and manufacturing workflows. Every week there is a new announcement about AI tools that can assist with design, documentation, analysis, or procurement.

But there is a structural problem that most of these tools run into quickly.

AI systems can summarize documents, generate reports, and recognize patterns in data. Their usefulness, however, depends entirely on the quality and structure of the information they can access. Without connected product knowledge, AI tools operate at a superficial level — they can read files, but they cannot understand how product elements relate to each other.

An AI assistant might be able to summarize a component specification. But without structured product knowledge, it cannot reliably tell you which other components are affected by a proposed change, which suppliers are qualified for a particular subsystem, what downstream manufacturing processes depend on this part, or what alternatives exist if a supplier goes on allocation.

These questions require more than raw data. They require memory — structured relationships that explain how a product is constructed and how it has evolved.

Product Memory provides exactly that foundation.

Why APIs Are Critical to Product Memory Systems

There is another dimension to this that rarely gets enough attention.

Product knowledge cannot remain trapped inside a single application interface. Engineering tools, ERP systems, supply chain platforms, manufacturing execution systems, and service applications all rely on product information.

When product knowledge cannot move freely across systems, organizations end up rebuilding fragments of the same knowledge in multiple places. The BOM in PLM does not match the BOM in ERP. Supplier data in procurement does not reflect engineering intent. Manufacturing is working from a version of the product that engineering updated months ago.

This is where APIs become structural.

APIs provide the access layer that allows Product Memory to flow across the enterprise and its extended ecosystem. They allow integrations, automation workflows, and intelligent agents to retrieve product knowledge in a structured and consistent form.

The architecture that emerges from this is simple to describe:

Product Memory provides the knowledge structure.
APIs provide the access mechanism.
AI provides the reasoning and assistance.

Together they form a new operational layer for product development.

Conclusion: From Product Lifecycle Management to Product Lifecycle Understanding

Product Memory is not an attempt to rename PLM or dismiss its history.

PLM represented an important step in organizing product information and establishing systems of record for engineering organizations. But the next stage of product development requires something more than lifecycle transactions.

Companies need systems that preserve lifecycle understanding — the relationships, decisions, dependencies, and context that make a product intelligible to both humans and machines over time.

Not just a record of what was approved, but a record of why decisions were made and what those decisions mean downstream.

In that sense, Product Memory does not replace PLM. It extends the conversation PLM started.

The goal is no longer just lifecycle management.

The goal is lifecycle knowledge that persists, grows, and remains usable — to engineers onboarding on a new program, to procurement teams navigating supply disruptions, and increasingly to AI systems trying to understand what changed and why.

Because without memory, even the most sophisticated systems eventually forget what they once knew about the products they build.

Want to talk more about Product Memory and how it will come out in OpenBOM development? Contact us and we would be happy to schedule a meeting. 

REGISTER FOR FREE to check how OpenBOM can help you. 

Best, Oleg 

FAQ: Product Memory and PLM

Is Product Memory the same as PLM?

No. Product Lifecycle Management (PLM) systems primarily manage product data such as files, revisions, and change workflows. Product Memory focuses on preserving connected product knowledge — including decisions, dependencies, and context — so teams and systems can understand products over time.

Why is Product Memory important for AI?

AI systems require structured product knowledge to reason about relationships and dependencies. Without Product Memory, AI tools can read documents but cannot reliably understand product structures, design decisions, or supply chain implications.

How are APIs related to Product Memory?

APIs allow Product Memory to be accessed across engineering tools, ERP systems, supply chain platforms, and automation workflows. Without APIs, product knowledge remains trapped inside isolated applications.

Does Product Memory replace PLM?

No. Product Memory extends the ideas behind PLM. Traditional PLM systems focus on lifecycle data management, while Product Memory focuses on preserving lifecycle knowledge and context so organizations can continuously understand and reuse product information.