Understanding the gap between PLM, Digital Thread, and the need to preserve product reasoning.
The Reaction Was the Real Story
Yesterday, I published an article asking a simple question: is Product Memory just a new name for PLM? It was part of a series I’ve been writing about how AI is reshaping PLM and how the pieces fit together. If you missed the earlier pieces, here they are:
- Why Manufacturing Needs Product Memory: Fixing Product Data Chaos in Manufacturing
- Building Physical Products Like Software: Five Transformations for Manufacturing Teams
The backstory was a comment on my last article — The Product Memory Flywheel: Rethinking PLM, Product Data Management, and the Digital Thread— that simply said: “ha, it looks like PLM.”
Honestly, I expected pushback. From where I stand, Product Memory isn’t a rebranding exercise — it’s not PLM with a fresh coat of paint. I expected some people to say “we’ve been talking about this for twenty years.” I expected others to say “no, this is genuinely different.” Both would have been fair.
What I didn’t expect was the intensity. Or the range.
The discussion didn’t stay in the comments. It spilled into separate posts, side conversations, and threads that wandered far from the original article. Some people were reacting to the word PLM. Some were reacting to the phrase Product Memory. Others jumped straight to AI, Digital Thread, sustainability, lifecycle ownership.
The more I read, the more I realized: the reaction itself was the real story.
What looked like a naming debate was actually pointing at something much deeper.
Why the Word “PLM” Still Triggers Strong Emotions
It became clear pretty quickly that people weren’t just reacting to the idea of Product Memory. They were reacting through the lens of what PLM means to them personally.
For some, PLM still represents an aspiration — a broad strategic discipline for managing product information across the full lifecycle. For others, it’s the software they’ve lived inside for years: CAD files, BOMs, release workflows, change orders, systems of record. And for others still, the term has become so stretched that it no longer communicates anything clearly.
So when a new concept shows up — especially one with equally ambitious framing — it doesn’t land in a vacuum. It lands on top of years of experience, frustration, and very different interpretations.
That’s why the reaction was charged. And that’s exactly why it’s worth paying attention to.
Naming debates usually signal that something underneath isn’t fully resolved yet. This was no different.
Three Debates That Got Mixed Together
The more I followed the thread, the more I noticed something that was obscuring the real conversation: people weren’t arguing about the same thing.
At least three separate debates were running in parallel.
- One was about scope. A group kept pulling the conversation toward business outcomes, sustainability, lifecycle responsibility, value creation. For them, anything that sounds engineering-centric immediately feels too narrow — and they’re not wrong to be suspicious.
- Another was about architecture. Several people pointed out that even when systems are integrated, even when Digital Thread does what it’s supposed to do, something important is still absent: the ability to preserve reasoning. Design rationale. The context behind a decision, not just the decision itself.
- And then there was a more practical concern. Even if we agree something is missing, how do you actually capture it? Context doesn’t naturally flow into systems — it has to be deliberately pulled in, and most workflows don’t do that.
Once I started separating these threads, the whole discussion became much easier to read.
What PLM Systems Actually Delivered
Let me be direct about something that sometimes gets lost in these conversations: PLM systems solved real problems.
They brought structure to environments that were genuinely chaotic. They created discipline around revision control, release processes, and product configuration. They made it possible to answer basic but critical questions — what’s the current approved state of this product? What changed between revision B and revision C?
That’s not nothing. That’s actually a lot.
But those systems also shaped what we think of as “normal” to capture.
PLM is quite good at recording outcomes. It can tell you what the approved state is, which revision is current, what changed. Where it falls short — and this is the part that matters — is explaining why.
Why was this supplier chosen over the other three? Why was this design approach rejected in the first review? Why did the team accept a certain trade-off at that particular point in the program?
Those answers typically live outside the system. In emails. In meeting notes. In someone’s memory. Or nowhere at all.
And the consequence is subtle but compounding: every new engineer ends up rediscovering decisions that were already made. Every new project reopens questions that were already settled. Sometimes the same mistake gets made twice simply because the reasoning behind the original fix was never written down anywhere a system could preserve it.
Digital Thread: Connecting Data Is Not the Same as Understanding It
Digital Thread was a genuine step forward. It pushed us to connect information across engineering, manufacturing, supply chain, and service. It challenged the assumption that product data could live in isolated functional silos. That was important work.
But connection is not the same as understanding.
A connected system can show you relationships between data points. It can surface that a design change rippled into three downstream systems. It can help trace the path from requirement to final product.
What it usually can’t do is explain the reasoning behind that path.
You can follow the thread. But you still don’t know why it went where it did.
From Product Data to Product Understanding
This is the point where the discussion started to clarify.
We have systems that store product data. We are building infrastructure to connect that data. But there is a layer between connected data and actual business outcomes that we haven’t fully built yet.
A useful way to frame it:
Systems of Record → Digital Thread → Product Memory → AI Reasoning → Business Outcomes
The gap sits in the middle. Not between storage and connection, but between connection and understanding.
What’s missing is the “why” — and without it, we aren’t accumulating knowledge. We’re accumulating states.
What Is Missing: The “Why” Behind Product Decisions
One comment in the discussion stopped me when I read it:
“What is missing is the WHY.”
That sentence cuts through a lot of complexity.
Because the real divide isn’t between systems. It’s between capturing outcomes and understanding them.
We’ve gotten quite good at recording what happened. We’re building the tools to connect those records. But the reasoning behind those outcomes — the context that would make them genuinely useful to someone later — is still fragile. It exists briefly, in the moments when decisions are being made. Then it disappears.
Product Memory as a New Layer of Product Understanding
This is where Product Memory becomes useful as a concept.
Not as a replacement for PLM. Not as a new umbrella term that swallows everything. But as a name for the layer that’s actually missing.
Martin Eigner put it well in the discussion:
“If we add one more layer — Reasoning, or better Design Rationale — we arrive at Product Memory level.”
That layer isn’t about storing more data. It’s about preserving the context that makes data meaningful — decisions, assumptions, dependencies, trade-offs, and the thinking behind them.
It’s also worth saying: Product Memory is unlikely to live in any single system. It’s something that emerges across systems, workflows, and interactions. Less like a database, more like a fabric.
The Hardest Problem: Capturing Context Before It Disappears
But here’s where the conversation gets uncomfortable. Because defining Product Memory is relatively easy. Actually building it is not.
In most companies, reasoning doesn’t disappear because people are careless or undisciplined. It disappears because the workflow never asked for it in the first place.
A supplier gets swapped. A design decision gets made under schedule pressure. A trade-off gets accepted. The system records the result. But the context — the real reason — is already gone by the time anyone opens a change record.
As someone put it in the comments:
“The actual reason… dies in someone’s inbox.”
The problem isn’t storage capacity. The problem is timing.
If Product Memory depends on engineers writing careful explanations after the fact, it will fail. People are busy. Memory fades. The moment passes.
The only realistic path is capturing context while decisions are actually happening — in conversations, in collaboration tools, in the natural flow of work — not after the fact in a structured field that nobody fills out honestly.
Why AI Makes This Gap Impossible to Ignore
AI didn’t create this problem. But it’s made it much harder to pretend the problem doesn’t exist.
AI can work with documents and data. It can summarize, classify, search, and generate. But without context, it can’t explain. It can tell you what changed. It can’t tell you why — and that’s precisely when “why” would be most valuable.
AI doesn’t fail on these problems because it lacks data. It fails because it lacks product understanding.
Without that layer, AI becomes a very fast and confident way to repeat decisions that were already considered and rejected. With it, something genuinely more useful becomes possible: institutional memory that doesn’t retire when people do.
From Managing Data to Preserving Lifecycle Understanding
One comment described the underlying shift in a way that’s stuck with me:
“Feels like a shift from managing data to preserving lifecycle understanding and decision context.”
That’s a subtle but meaningful distinction.
It’s not about replacing PLM. It’s about recognizing that managing data — however well you do it — only solves part of the problem. Understanding is the other part. And without understanding, engineering decisions remain opaque to everyone outside of engineering: manufacturing, supply chain, and ultimately the business making decisions about the product.
A Missing Layer, Not a New Buzzword
I want to be careful not to oversell this.
Product Memory is not a business strategy. It doesn’t replace lifecycle thinking. It won’t solve sustainability problems or improve market fit by itself. It’s not a slogan or a brand position.
It’s a way to describe something that has been absent for a long time — a layer that preserves explainable product understanding across time, teams, and systems.
That’s a specific and bounded claim. I think it’s an important one.
The Real Question Going Forward
Looking back at everything that came out of this discussion, the disagreement was less interesting than the convergence.
People arriving from PLM, Digital Thread, AI, engineering operations, and product strategy were all pointing at the same gap — they just named it differently and approached it from different angles.
We know how to store product data. We’re learning how to connect it. What we still haven’t solved is preserving the understanding behind the decisions that shaped it.
So the real question isn’t what we call the concept.
The real question is: can your systems explain why your product is the way it is?
If they can’t — and for most companies, they can’t — then we’re not really managing products.
We’re managing their snapshots.
Just my thoughts…
Best, Oleg
FAQ: Product Memory, PLM, and Digital Thread
Q: What is Product Memory? Product Memory is the ability to preserve and reuse the reasoning, decisions, and context behind a product — not just the data states it passed through.
Q: How is Product Memory different from PLM? PLM systems manage product data and processes. Product Memory focuses on preserving understanding — the why behind decisions, not just the what.
Q: Is Product Memory replacing PLM? No. It describes a missing layer that extends beyond systems of record and Digital Thread — something those systems were never designed to capture.
Q: Why is Product Memory important for AI? AI needs structured, explainable context to reason about product decisions. Without it, AI can access data but can’t explain it — and that’s the gap that matters most in engineering environments.
Disclaimer: I’m the co-founder and CEO of OpenBOM, a collaborative digital thread platform that helps engineering and manufacturing teams work with connected, structured product data, increasingly augmented by AI-powered automation and insights.
