The Question PLM and Change Management Cannot Answer: Why Was It Designed This Way?

[HERO IMAGE] 

I have been writing about Product Memory for some time now, developing the idea that companies need more than product data, files, BOMs, revisions, and change records. They need to preserve the context of the product: what it is, how it changed, why decisions were made, and who was involved. Last week I found that this idea is starting to live its own life. Martijn Dullaart published an excellent article, The Question Your Configuration Management System Can’t Answer, in which he takes the Product Memory concept and examines it through the lens of a discipline he works and knows deeply: Configuration Management. 

What I liked about Martijn’s article is that he does not simply agree with the Product Memory argument, but he tested it against CM practice, identifies where the popular version of the story is imprecise, and sharpens the boundary. This is the type of validation and engagement for the idea I was looking for and I want to share more thoughts about Martijin work. .

Configuration Management Knows More Than We Give It Credit For

It is easy to build an oversimplified argument that says PLM and Configuration Management store the “what” while Product Memory stores the “why.” Martijn demonstrates convincingly that this framing is not correct and I agree with him. The same comments came in some earlier discussions with CM and PLM professionals saying that a well organized ECO might already include some information about “why” the change is needed.

A disciplined change process captures a substantial amount of genuine reasoning. A change request states the problem it solves. An impact assessment documents what the reviewing team judged would be affected and why. A disposition records the logic behind approval, rejection, or deferral. Requirements traceability connects a requirement to the design that implements it and the verification that confirms it, which is itself a structured form of recorded reasoning. Baselines record authorized intent at each level of product definition. A configuration management system run well is not a silent ledger of states.

So the problem is not that Configuration Management has no records about what was the reason for the change. The more interesting question, and the one Martijn answers precisely, is where that memory begins, where it ends and how it is connected to the rest of events happening around the product (both engineering, maintenance, sales, support).

Why Was the Tolerance Set This Way?

Martijn opens his article with an example I found very close to situations I observed many times in my PLM career. A change review stalls on a single tolerance. An engineer wants to widen it to simplify supplier qualification and reduce cost. The configuration is fully documented: the part is identified, the baseline is identified, the requirement is traceable. And still nobody in the room can answer the only question that matters:

Why was the tolerance set this tight in the first place?

The engineer who chose it moved to another program. The analysis that justified it, if it was ever written down, is in a folder nobody can find. The change is either rejected out of caution or approved out of optimism, and as Martijn puts it, neither is engineering.

His diagnosis is the thing in the article I like the most. CM reasoning is event driven. It is captured at the moments the change process creates: request, assessment, review, disposition, release. It covers the “why” of everything that happened after the configuration became stable enough to be changed. It says very little about the original design decisions, the trade-offs settled in analysis sessions and design reviews before any change event existed to record them. The tolerance was not chosen during a change. By the time the change process took custody of it, the reasoning behind it was already complete and, in most organizations, already unrecorded. Change Management can explain why something changed. Product Memory must also explain why it was designed that way before the change existed.

A Working Framework: What Can Today’s Systems Answer?

Martijn’s article made me want to map this boundary more explicitly. The table below is my first attempt. I consider it a working framework rather than a final definition, and I am specifically interested in feedback from people working in Configuration Management, systems engineering, and PLM.

I fully expect people to disagree with some rows, and I hope they do. Someone will say that their PLM system can store alternatives, and someone else will say that their change records already contain rationale. Both statements are true. The question is not whether a system can technically store this information. A more detailed question is about how reasoning is systematically captured, connected to the product objects it explains, retained across years of product development, maintenance and support, and retrievable by someone who was not part of the original decision. That is a much higher bar, and it is the bar Product Memory has to meet.

The Missing Why Is Not Only a Serial Engineering Problem

Martijn’s example describes a classic scenario: a serial product, a stable baseline, a change review. But when I think about the companies I worked with, the missing why multiplies in environments that do not follow this clean pattern. Engineering to order and custom product development is the most obvious one. When every order produces a variant, the reasoning behind each configuration decision, why this option was chosen for this customer, why this substitution was acceptable, why this requirement was waived, often never enters a formal change process at all, because there was no baseline change to trigger one. The product knowledge lives in orders, quotes, and customer conversations, and it evaporates faster than in any serial program.

Maintenance and retrofit is another dimension. Decisions about a product in service are made years or decades after the original design, usually by people who never met the original engineers. This is exactly the moment when the question why it was designed this way matters most, and exactly the moment when the answer is hardest to find. The same applies to new development that extends an existing product line. Reuse decisions depend on understanding why the original was designed the way it was. Without that reasoning, teams either carry over constraints nobody understands or violate assumptions nobody remembers.

And there is one more place where reasoning disappears that I find particularly interesting, because it happens inside the change process itself. When a team evaluates an ECO, the real analysis often happens in a sandbox: alternative CAD studies, what-if BOM comparisons, cost scenarios, supplier options. The formal record captures the disposition and the selected option. The alternatives that were analyzed and rejected, and the reasoning that eliminated them, rarely survive the moment of approval. The change process was followed with full discipline, and the reasoning still disappeared. This is why better CM discipline alone cannot close the gap.

Where I Want to Extend Martijn’s Argument

Martijn proposes a practical answer for the forward-looking part of the problem: the change process already convenes the right people at the right moments, so organizations should capture reasoning at the depth that would serve someone who was not in the room, turning the change record from an outcome document into a reasoning document. He also said, correctly in my view, that reasoning surfaced by AI from old presentations and email threads cannot be treated as authoritative knowledge without validation, and that governance principles from CM should apply to reasoning records as well.

I agree with both points, and I want to add a dimension that matters for how Product Memory can be implemented. The reasoning behind the tolerance in his example did not live inside the CM system. It lived in an analysis session, a supplier conversation, a simulation report, an email thread. Once you add order engineering, service history, product line reuse, and sandbox analysis, the number of places holding reasoning grows further, and none of them are places a change process can be extended to cover. These artifacts belong to systems that CM does not own and will never own: CAD, simulation tools, email, meeting notes, issue trackers, supplier portals, service records, quoting and order systems. This is why I keep arguing that Product Memory cannot be another controlled repository where reasoning documents are collected. It has to be a connected layer, a graph that spans the systems where product development actually happens, linking decisions, evidence, people, and product objects across system boundaries while each system of record continues to own its facts. Governance applies to the connections, the provenance, and the validation status of reasoning, not to a new database where reasoning is relocated.

In the definition I use in my Product Memory framework, this is what makes memory attributed and explainable: every piece of reasoning carries its source, its author, and its connection to the product objects it explains, and it remains recoverable by people and AI agents who were never part of the original decision.

This distinction also answers the trust question Martijn raises. When AI proposes a connection between a five-year-old design review and a tolerance, the graph records that connection as a candidate with its provenance visible. Validation by a person with authority promotes it. Nothing pretends to be more certain than it is. AI can discover potential Product Memory. People and governance establish trusted Product Memory.

What is my conclusion?

In my view CM and Product Memory need and complement each other. They are complementary layers, and Martijn arrives at the same place from the CM side. While CM is widely adopted discipline for many organizations, I have enough evidence that the formal ECO form used by many organizations is far from the ideal and sufficient to capture the entire information set needed for the future reasoning and analysis.

Configuration Management provides the authoritative structure: baselines, traceability, change control, and named accountability. Product Memory connects that structure to the reasoning, evidence, assumptions, and people that explain why the product became what it is, including the design-time reasoning that existed before the change process ever took custody of the configuration, and the reasoning produced in the places the change process does not reach.

CM without Product Memory produces auditable records that cannot answer why. Product Memory without CM produces reasoning that is not sufficiently connected to formal change records.

Martijn closes his article by asking what reasoning your organization is letting walk out the door this quarter. I want to offer a practical version of the same test. Think about one important engineering decision your team made this week. Six months from now, will another engineer be able to find what was decided, why, what alternatives were considered, what evidence and assumptions supported it, and who participated? If yes, you are already building Product Memory. If not, the information may still exist somewhere today, in a presentation, an email, or someone’s head, but it is not yet part of your product’s memory.

Thanks to Martijn Dullaart for a genuinely insightful article and for sharpening the boundary between Configuration Management and Product Memory. I strongly recommend reading his original article and following his work. And I would like to hear from the PLM and CM community: where do you think the boundary between Configuration Management and Product Memory should be?

Just my thoughts…

Best, Oleg 

Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.