As I’m moving forward in the exploration of Product Memory development and working on my book, From CAD Files to Product Memory, one question keeps coming up in the discussion. It is about the invention of new buzzwords and names. Sometimes it arrives as a question and sometimes as a statement that sounds like this: PLM is an established discipline that works fine but requires skills and must be implemented correctly, so instead of reinventing a new name we need to focus on how to implement PLM correctly. The PLM industry has spent thirty years inventing acronyms instead of solving problems, and here comes another one. PDM became PLM. PLM acquired digital thread, then digital twin, then MBSE, then AI assistants. Now somebody wants to call it product memory. Enough. Fix the implementations and leave the vocabulary alone.
I have a lot of sympathy for this. More than sympathy, I think the underlying complaint is correct. PLM does have a relabeling habit that is technological trend driven, and the PLM industry does have an execution problem that no amount of naming will touch. Implementations still take too long, the overall user experience and data modeling are still too complicated, and customization is still the thing customers complain about first. Anyone selling a new term as a substitute for solving those problems deserves skepticism.
But the objection assumes something I want to challenge, which is that product memory is a proposal to rename PLM software. It is not. PLM software stays PLM software. The argument I am making is narrower and more specific. PLM software models records. It is a system of records describing product data. The broader context and the reasoning behind that data were never modeled at all, and that gap is now the binding constraint on everything the industry wants to do with AI.
Since the term keeps getting defined by whoever is arguing against it, let me state it plainly. Product Memory is the layer that captures the reasoning behind product decisions and links that reasoning to the items those decisions govern. PLM records what was decided, when, and by whom. Product Memory records why it was decided, what alternatives were rejected, and on what grounds. It holds no authority over any fact and it replaces no system of record.
I can see where some of the confusion comes from. Most systems of record expanded over time to cover a bigger data spectrum and more functional domains. It was visible in ERP, which started from MRP, became MRPII, then absorbed finance, procurement, and much else. The same pattern was applied to PLM software, which started from PDM and expanded upstream and downstream of engineering into requirements, simulation, manufacturing planning, maintenance, and other elements of the lifecycle. Each expansion was an argument about absorbing more specific functions into an existing system.
My argument about Product Memory is completely different.
I made half of this argument a few weeks ago when I asked whether product memory is a new system of record. The answer there was no, and the reason was authority, which is another way to describe what makes a system of record a system of record. A system of record is defined by exclusive authority over a set of facts, and product memory has authority over nothing. It holds the data, semantics, connections, and history that live between systems it does not own. This article is the other half of the same argument, approached from the naming side rather than the architecture side.
The car analogy for PLM proves the opposite of what it appears to prove
The sharpest version of this objection came recently from Andreas Lindenthal, a long time industry veteran and frequent commenter here, who compares PLM to cars. Here is how the argument goes. We did not rename the car when it gained GPS, cameras, adaptive cruise control, an electric drivetrain, or the ability to drive itself. It is still a car. Same with PLM. New capabilities, same discipline, same name.
The analogy is good, and it fails for an instructive reason. We kept calling cars cars because none of those additions changed what a car is for. It moves a person from one place to another. Cameras made it safer at that. Electrification changed how it is powered. The object of the thing never moved.
Consider the cases where we did invent a new word. We did not call the computer a calculator with programs, even though calculation was one of its earliest and most important functions. We adopted a new name because the primary object was no longer the calculation. It became programmable information processing. Closer to enterprise software, we did not call CRM an address book with workflows. The contact record remained, and it is still there, but it stopped being the primary object. The object became the relationship, its history, its opportunities, and the processes around it. And we did not call cloud computing hosting with more servers, because the unit being consumed stopped being a machine and became capacity.
So the test is not whether capabilities got added. The test is whether the object being managed changed. That is the question worth arguing about, and it is not answered by asserting that additions are only ever additions.
PLM models product data records, and it models them well
Open any PLM data model and look at what it actually holds. Part numbers and identity. Revisions and revision rules. Bill of materials structure, with variants and effectivity. Documents and their relationships to items. Change requests, change orders, approvals, signatures. Released state. Where-used. Lifecycle transitions. Access control over all of it.
This is a record system, and I mean that as a compliment. It is the reason PLM survived thirty years of vendor churn. When you need to know what the released configuration was on a given date, who approved it, and which serial numbers it shipped on, PLM answers. The audit holds. The regulator is satisfied. That capability was hard to build and it works.
Now notice what the model does not hold. Part of it is data belonging to other systems, the records that live in ERP, MES, CRM, and supply chain platforms. That absence is the known problem. The industry has been attacking it for twenty years under names like integration, interoperability, and more recently digital thread, and it has a vocabulary, a budget line, and a shelf of standards behind it.
The other absence never got named at all. It is the why. Why this tolerance and not a looser one. Which three suppliers were evaluated and what disqualified two of them. What the thermal argument was that pushed the housing from aluminum to a filled polymer, and what would have to change for that decision to be revisited. Which alternative architecture the team spent six weeks on before abandoning it, and on what grounds.
A change order captures that a change happened, who approved it, and what it affected. The reasoning that produced the change is a free text description field at best, filled in under deadline pressure by an engineer who already knows the answer and is not writing for a reader five years out.
The reasoning exists, it is just not anywhere PLM can query it
None of this context is lost, exactly. It is scattered. It lives in the connections between systems, in the Excel files where the real work happened before the change order was approved, in email threads, in Teams and Slack channels, in redline markups on PDFs, in the comment column of a spreadsheet, in a supplier call that nobody recorded, in the slide from the design review that never got attached to anything, and above all in the heads of four or five people who were in the room.
Every company I talk to knows this and treats it as normal. Which it is. It has been normal for so long that it stopped registering as a gap, the way a missing tooth stops registering after a while. The reasoning behind a product is understood to be tribal knowledge, and the mitigation is to keep the tribe employed.
The reason nobody modeled it was economic, not conceptual. Capturing rationale at scale used to require humans to stop and write things down in a structured way, at the exact moment they were least inclined to. Every methodology that demanded this failed for the same reason, which is that the person who has the context has no incentive to serialize it and the person who needs it does not exist yet. So the industry did the sensible thing and modeled what could be captured as a byproduct of work that had to happen anyway: the approval, the release, the revision.
That constraint is the thing that broke recently. Transcription is nearly free. Storage is nearly free and getting cheaper, and almost no system today is technically limited by it, although it remains a business model question, which is a separate discussion. Extraction from structured database records and unstructured text works. Linking an extracted decision back to a part number is a solvable engineering problem. Databases scale to a size that crosses company boundaries. For the first time the reasoning layer can be populated as a byproduct rather than as a discipline. This is a change in what is possible to model, not a change in marketing.
AI is why the missing reasoning layer stopped being tolerable
If the reasoning layer were merely nice to have, I would not spend time on it. What makes it urgent is that the industry has decided to put AI on top of PLM, and AI is a retrieval technology before it is anything else.
Point a well built assistant at a PLM database and ask it something a new engineer actually asks. Why is this part specified this way? Can we substitute this component? What did we learn the last time we tried this? The assistant will retrieve records, because records are what is there. It will return a revision history, a change order, and a document link, and then, because that is what these systems do, it will produce a fluent paragraph that sounds like an answer and contains no reasoning, because there was no reasoning in the index.
This is the failure mode I keep seeing in AI for PLM demos, and it does not get fixed by a better model or a better prompt. It is a data problem wearing an AI costume. You cannot retrieve what was never captured. Every serious attempt to build an intelligent layer over engineering data runs into the same wall, which is that the corpus contains outcomes and not arguments.
Digital thread does not solve this either, and I want to be careful here because the two get conflated. Digital thread connects records that already exist, across systems and across the lifecycle. That is valuable and it is hard. But connecting records more thoroughly does not create rationale where none was recorded. A perfectly traced thread through a decision with no documented reasoning gives you a very well connected gap.
Moving to AI, here is my article speaking about why tools need shared context – every tool got an AI, each captured a fragment of reasoning, none shared it
Both objections assume Product Memory is competing with PLM
It is worth putting the two challenges side by side, because they arrive from different directions and rest on the same assumption.
The first says product memory is just a system of record by another name. The second says product memory is just PLM by another name. Underneath both is the belief that whatever product memory is, it must be competing for the position PLM already occupies. Either it claims the authority PLM holds, or it claims the label.
It does neither, and the two answers reinforce each other. It cannot be a rename of PLM because it has no authority over any fact, and authority is the entire basis on which PLM earns its place. The released BOM is authoritative. The approved change order is authoritative. Product memory asserts nothing about what is true. It records what was argued, by whom, and on what grounds, and connects that reasoning to items governed elsewhere. A layer with no authority is a poor candidate for replacing the system whose whole function is authority.
The case I looked at in that earlier article makes the point better than the abstraction does. A change order was processed correctly. Every fact was recorded, every signature collected, every system behaved as designed. What went missing was not a fact. It was the reasoning that would have told someone downstream which of those correctly recorded facts actually mattered. No stronger system of record would have caught it, because the system of record was working. The gap was in a layer that did not exist.
Naming a missing capability is not rebranding PLM
Here is where I will defend the vocabulary, narrowly.
There is a difference between renaming something that exists and naming something that does not exist yet. Renaming is what the industry rightly gets criticized for. Naming an absence is how the absence becomes actionable. Until a capability has a name, nobody scopes it, nobody budgets for it, nobody writes a requirement for it, and no evaluation asks a vendor whether they do it. Requirements management was engineering judgment before it was a category with a name and a line item. So was configuration management.
I am not claiming the term product memory is the right one, or that it will survive. Terms are cheap and most of them die. I am claiming the thing it points at is real, is not currently modeled by any PLM system I know of, and is about to become the difference between AI that helps and AI that hallucinates confidently over a change log.
I applied exactly this test to PTC earlier this year and asked whether intelligent PLM was a rename or a new architecture.
Which brings me to the argument I will accept, and I want to state it clearly because it is the strongest form of the objection.
Product Memory is a concept, not a product. Digital thread is the useful precedent here. It was introduced by U.S. Air Force research roughly a decade ago, and it has never belonged to any one vendor. Siemens implements it one way, PTC another, Aras another, and a systems integrator stitches it together across all three. It remains the same concept regardless of who builds it, and nobody today argues that digital thread was a rename of PLM.
Product Memory can follow the same path. As the industry explores what its position, role, and function should be, existing platform vendors can decide to implement it and make product memory a first class object inside their systems, structurally embedded, queryable, and linked to the items it describes. If that happens, then in those products it becomes part of that platform’s scope, the same way requirements management became part of PLM after starting life somewhere else. I would count that as the argument being settled in the right direction, not as a defeat. The point of naming a missing layer is to get it built. It matters much less who builds it.
Product Memory concept is tightly connected to human behavior. Check what I learned about it at Share PLM Summit: AI Needs Product Memory, and Product Memory Needs People.
What I will not accept is the claim that it is already there. It is not in the data models, and pointing an assistant at a change log does not put it there.
The PLM execution problem and the memory problem are the same problem
I want to end by taking the execution critique seriously rather than deflecting it, because I think it points at product memory rather than away from it.
Ask why PLM implementations go badly. Not the surface answer about scope and organizational change management, the deeper one. A team spends nine months making thousands of decisions: how to structure part numbering, why the workflow branches where it does, which of three data model options they chose and what the tradeoff was, which requirements they deliberately deferred. Then the project ends. The consultants leave, the internal champion moves on, and eighteen months later phase two begins with a new team that inherits a configured system and none of the reasoning that produced it.
So they rediscover it. They change things that were set deliberately, they re-litigate settled questions, and they conclude that the previous team did not know what they were doing. Every PLM consultant reading this has watched it happen more than once. The configuration is the record. The reasoning behind the configuration was tribal knowledge, and the tribe dispersed.
Some people call it a handover problem. It is not a naming problem and it is not a branding problem. It is the same absence showing up in the implementation of PLM that shows up in the products PLM manages. Improving usability, simplifying data models, and accelerating deployment are all worth doing and I am for all of them. But a large share of what looks like an execution problem is a memory problem, and it will keep recurring for as long as the only thing we model is what was decided rather than why.
Just my thoughts. YMMV.
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
FAQ
What is Product Memory? Product Memory is the layer that captures the reasoning behind product decisions and links that reasoning to the items those decisions govern. PLM records what was decided, when, and by whom. Product Memory records why it was decided, which alternatives were rejected, and on what grounds. It holds no authority over any fact and replaces no system of record.
Is Product Memory just a new name for PLM? No. PLM stays PLM. Product Memory refers to a capability PLM data models do not contain, which is the capture of decision reasoning as a queryable object linked to the items it governs. PLM models records such as revisions, approvals, structure, and effectivity. Reasoning was never modeled at all.
Is Product Memory a system of record? No. A system of record is defined by exclusive authority over a set of facts, and Product Memory has authority over nothing. It holds the semantics, connections, history, and attribution that live between systems it does not own. This is covered in more depth in a companion article, Is Product Memory a New System of Record.
What is the difference between Product Memory and digital thread? Digital thread connects records that already exist across systems and lifecycle stages. Product Memory captures context that was never recorded in any system. A fully traced digital thread through an undocumented decision still returns a gap, only a better connected one.
Could an existing PLM vendor implement Product Memory? Yes, and that would settle the argument in the right direction. Product Memory is a concept rather than a product, in the same way digital thread is a concept implemented differently by different vendors. If platform vendors embed decision reasoning as a first class object, queryable and linked to the items it describes, the missing layer gets built. Who builds it matters much less than whether it exists.
Why is Product Memory becoming relevant now? Because capturing rationale at scale used to require humans to write things down in structured form at the moment they were least inclined to, and every methodology that demanded this failed. Low cost transcription and reliable extraction from unstructured text make it possible to populate a reasoning layer as a byproduct of normal work rather than as a discipline.
Why do AI assistants on PLM data give shallow answers? Because AI is a retrieval technology before it is anything else, and PLM contains outcomes rather than arguments. Ask why a part is specified a certain way and the system retrieves a change order and a revision history, then generates fluent text that sounds like reasoning without containing any.
Does the PLM industry have a branding problem or an execution problem? Execution, and a significant share of it traces to the same absence. Implementation teams make thousands of decisions that are never recorded as reasoning, the team disperses, and the next phase re-litigates settled questions from a configured system it cannot interpret.
