What Is Product Memory? The Missing Layer in PLM Explained

Last week I wrote about where product lifecycle knowledge gets lost, and I also published a longer piece on Beyond PLM arguing that Single Source of Truth was never the final destination — it was a station. An important one that the industry needed to pass through, but a station. The Digital Thread was the next station after that. And now I think we are arriving somewhere new.

The question I keep getting after those pieces is a practical one: fine, something is missing, but what would it actually look like if it existed? Not as a product pitch. Not as an architecture diagram. Just as a way of working. What would change?

That is what this article is about.

Product Memory Is Not a PLM System — Here’s What It Actually Is

Before I describe what Product Memory looks like, I want to be clear about what it is not.

It is not another PLM system. It is not a PDM vault. It is not a smarter spreadsheet or a document management platform. And it is definitely not a replacement for the systems companies already have.

Most companies I talk to are already storing data. Some do it in Excel, some in CAD and PDM, some have invested in PLM and ERP. The sophistication varies enormously, but the act of storing — keeping records, maintaining structure, tracking revisions — that part is not the gap. Companies have solved data storage, in one form or another, at virtually every level of maturity.

So the problem is not that information does not exist. The problem is what gets lost in the process of creating that information.

Every product decision starts as a question. It moves through a discussion. It gets shaped by constraints and trade-offs. Eventually it becomes a structured outcome — a released BOM, a change order, a CAD revision, a closed approval workflow. The system captures that outcome. It does not capture the sequence of reasoning that produced it.

That is the specific gap. And closing it requires something fundamentally different from a better system of record.

Why Product Memory Must Be Captured During Engineering Work, Not After

One thing I have noticed about how engineering work actually happens is that the most important activity takes place outside the formal systems.

An engineer is working on a new assembly. She saves version after version of the CAD model as she explores the design space. Meanwhile, there are email threads with the supplier about a lead time issue. A Slack message from a colleague flagging a tolerance concern. A shared spreadsheet where someone is tracking cost options. A meeting where two alternatives were laid out and the team chose one, with the reasoning living only in the memories of the people in the room.

By the time a BOM gets released into the formal system, all of that activity has already happened. The system sees the outcome. It does not see what produced it.

This is why the idea of memory is different from the idea of data storage. You cannot bolt memory onto the end of a process and expect it to capture what actually happened. Memory has to be created during the work itself, not documented after the fact as a separate activity.

What that looks like in practice: decisions are attached to the items they affect, not written in a separate notes field that nobody reads. Comments are connected to specific elements of the structure, not floating in a general discussion thread divorced from context. Tasks are linked directly to the changes they drove. The activity that shaped the product stays connected to the product, as a natural byproduct of how the work was done — not as an additional documentation burden layered on top.

This distinction matters. If capturing context requires extra effort from engineers who are already under schedule pressure, it will not happen consistently. It has to be structural.

How Product Structure (BOM) Becomes the Backbone of Product Memory

There is one concept that quietly sits at the center of how most engineering organizations work, regardless of their level of PLM maturity: structure.

In companies with mature PLM, this is the BOM — a hierarchy of items that defines what the product is made of. In companies that have not yet made that investment, it might be a spreadsheet, an internal parts list, some informal representation of how components relate to each other. The format varies. The function is the same: structure is how a product is described.

But today, structure is mostly passive. It tells you what exists. It does not tell you how things came to be that way.

Imagine instead that structure played a different role. Not just a list of parts, but the backbone that everything connects to. An item in the BOM is not just a record — it is a node. The discussion about whether to use this fastener or the one from a different supplier is attached to that item. The decision to increase the wall thickness is attached to that item, including the reasoning behind it. The change order that moved the assembly from revision B to revision C is linked to the specific items that changed, and the note that explains why is right there with them.

Different teams would see different views of this structure. Engineering looks at the design intent. Manufacturing looks at the build sequence. Procurement looks at suppliers and lead times. These are not separate systems fighting over data ownership — they are different perspectives on the same underlying context. The xBOM idea, different views of the same structure, is not a new concept. But it becomes much more powerful when the structure carries not just part data but the history of decisions that shaped it.

This is where structure stops being a list and starts being a backbone.

How Product Memory Evolves Across the Product Lifecycle

A product is not a snapshot. It is a sequence of decisions made over time, each one shaped by constraints that existed at a specific moment. Product Memory, to be useful, has to reflect that.

Before formal release, the activity is exploratory. Alternatives are being considered, sketches are being made, options are being compared. This is often the most important phase of the decision-making process, and it is almost entirely invisible to every system currently in use. The early reasoning — the reasoning that establishes direction — is the reasoning that is hardest to recover once it is gone.

During the change process, the mode shifts. Decisions become explicit. Trade-offs are made and documented, at least informally. Impact is assessed. This is the phase where current PLM systems work best, because change orders and approval workflows are designed exactly for this. But even here, what gets captured is the status — approved, released, effective. Not the reasoning that made this particular change necessary rather than the three alternatives that were discussed and rejected.

After release, the question changes again. Now teams are asking not what to build but how to understand what was built. Why was this component chosen? What changed between these two revisions? Can this subassembly be reused in the next program? If memory exists across all three phases, these questions have answers. If it does not, the answer depends on whether the right person still works at the company and happens to remember.

The point is that memory is not static. It grows with the product. And it is most valuable when it is continuous — not broken into phases, but accumulated naturally across the full arc of development.

Product Memory Works Across Distributed Systems — Without Replacing Them

One of the things that has made this problem hard to solve is that product knowledge is inherently distributed. It lives in CAD systems, in ERP, in spreadsheets, in email, in Slack, in the heads of the engineers who were there when the decisions were made.

Every previous attempt to solve this by forcing all of that into a single system has failed, for the simple reason that each of those places exists for a reason. CAD systems are optimized for geometry. ERP systems are optimized for transactions and planning. Spreadsheets are optimized for flexibility. You cannot replace all of them with a single platform without losing the specific value each one provides.

But what you can do is connect them. Not replace them — connect them. Capture the relationships between the data that lives in different places. Link decisions to outcomes across systems. Preserve context across tool boundaries so that when someone needs to understand why something is the way it is, the answer is assemblyable, even if no single system holds all of it.

In this model, Product Memory is not a container. It is a fabric. The data stays where it lives. What grows over time is the web of relationships and context that makes that data interpretable.

What Changes When Product Memory Exists: Less Rework, Better Knowledge Transfer

Let me make this concrete, because I think it is easy to lose the practical implication in the conceptual framing.

Today, a common scenario in engineering organizations looks like this: a product has been through several major revisions over five years. The current team includes a mix of people who were there from the beginning and people who joined more recently. Someone asks why the thermal management subsystem was designed the way it was. The people who made that decision remember some of it. The formal system shows what the design is. The reasoning — the alternatives that were evaluated, the supplier constraint that ruled out the preferred option, the cost target that forced the compromise — none of that is in any system. It lives in one person’s memory, partially. It may not be reconstructable at all.

With memory, that same question has a real answer. The items in the BOM carry the discussion that shaped them. The change that moved the design from one approach to another has a note attached to it, not added after the fact but captured as part of the process that made the change. The supplier decision has context. The constraint is visible.

The second scenario that changes is knowledge transfer. Today, onboarding a new engineer means months of orientation where they read BOMs and revision logs and eventually find someone who was there and ask them directly. The system shows the product. Other people explain it. When those people are not available — because they are in a different time zone, or they left the company, or they are busy — the onboarding slows down. Knowledge is tribal, not because the organization chose that, but because the system was not built to carry it.

With memory, a new engineer can navigate a product and find not just what it is but how it became that way. The story is in the structure.

The third thing that changes is the repetition cycle. Teams rediscovering decisions that have already been made — a cost reduction analysis that was done two years ago and then forgotten, a supplier evaluation that reached a conclusion nobody remembers — this is expensive. It is also invisible, because nobody knows they are repeating work. They just know the work feels harder than it should.

With memory, the prior analysis is findable. Not because someone documented it in a wiki that nobody updates, but because it is structurally connected to the product it was about.

The Missing Layer in PLM: Product Memory, Not Another System of Record

What I have been describing is not a product. It is a way of thinking about the relationship between work and the context that work creates.

We have systems of record. We have digital threads connecting them. What we do not have is a layer that preserves the reasoning that produced the records. The decisions, the discussions, the trade-offs, the history of how a product came to be the way it is — that layer is missing. Not because it is impossible to build, but because we have not treated it as a first-class problem.

Once you start looking at product development through this lens, the gap becomes very hard to unsee. The question is whether we are ready to treat it as something worth solving, structurally, rather than asking engineers to document more carefully or hoping that the right person is still around when the question gets asked.

We don’t need another place to store data. We need a way to remember how products come to life.

Interested to discuss more? Please contact me to discuss how your organization can start capturing Product Memory tomorrow. 

Best, Oleg