Why the PLM industry is converging on the same problem
This article is a summary of thoughts that have been building across multiple discussions, articles, and voices over the past year. Below are some data points and reference articles.
I want to thank everyone who contributed comments, discussions, and arguments over time, both at conferences and in online conversations. Here are a few references I wanted to mention.
I wrote about whether we are losing product knowledge outside PLM. The question was not rhetorical. Working with companies across industries, the pattern is impossible to miss: the most consequential product decisions, cost tradeoffs that forced uncomfortable compromises, supplier selections driven by delivery risk, quality risks consciously accepted because the schedule could not move, consistently happen outside the systems that are supposed to manage product data. The knowledge exists while the people who made the decisions are still around. When they leave, it leaves with them. That article asked the question. This one proposes the architecture.
The article by Jaya Gupta, Ashu Garg from Foundational Capital caught my attention AI’s trillion-dollar opportunity: Context graphs. The article resonated with my recent ideas about Why PLM Leaks to Excel which speaks about limitations of PLM systems and demand for collaboration and capturing activities outside of the formal lifecycle processes. Which led to my exploration of how context graphs as the broader framing for what PLM is missing. The trigger was a piece from Foundation Capital arguing that context graphs represent a trillion-dollar AI opportunity, and my recognition that the problem they were describing, connecting structured data to the reasoning and relationships that give it meaning, was exactly the problem PLM has been failing to solve for decades. PLM systems became very good at remembering what changed and when it changed. They never learned to remember why decisions were made. The reasoning, the debate, the alternatives considered and rejected, the tradeoffs that felt acceptable at the time: all of that lives outside the system. Context graphs offered a conceptual vocabulary for the missing layer.
One more article, where I wrote what I consider the core statement: Single Source of Truth was never the final answer. It was a station, an important one the industry needed to pass through, but not the destination. SSOT was built on the assumption that the main problem was data fragmentation, and that centralizing the authoritative record would solve it. It solved part of it. The part it did not solve, the coordination and context and decision history that surrounds the record, is what this article addresses.
Alongside my own writing, here are a few of my industry colleagues and frequent LinkedIn “discussion partners” have been pushing what I consider as the same direction from different angles, and their thinking deserves direct acknowledgment.
Martin Eigner, one of the most rigorous thinkers in PLM over the past three decades, has been articulating a vision of Product Memory connected to end-to-end Digital Thread as the defining challenge for the next five years. His framing is precise: Product Memory is not a feature to be added to existing PLM. It is a different architectural premise about where product intelligence lives and how it should be organized.
Benedict Smith, AI researcher and former PLM expert, has been making a related but distinct argument in his True Intelligence newsletter. His Goldrush PLM: Reasoning Explained piece makes the case for building on verifiable understanding rather than structured data management, which points toward the same gap from the AI side: the next generation of engineering intelligence cannot be built on records alone. It requires reasoning, and reasoning requires context that current PLM architectures do not capture or preserve.
Doug Macdonald, investor and self-described recovering PLM advocate, has been direct and vocal about the shortcomings of legacy PLM and the opportunity he calls the Future Platform for Hardware Engineering. His framing connects engineers across disciplines, uses AI to automate repetitive processes, and continuously supports engineering judgment rather than just managing its outputs. What he is describing is a coordination and intelligence layer above the existing system landscape, which is precisely what this article argues is missing.
One more signal comes from my long trajectory of communication and following with Adam Keating, CEO and co-founder of CoLab Software. Adam has been building toward this problem from the design review side for a long time. CoLab started with collaborative design review, giving engineering teams a structured place to capture feedback, markups, and decisions around CAD models and drawings across organizational boundaries. What made it interesting was not the review interface itself but the insight underneath it: that the most consequential engineering knowledge, the concerns raised, the trade-offs accepted, the lessons from the last program, lives inside review conversations rather than in any system of record. Their more recent moves, AutoReview make that explicit. CoLab is building a layer that captures expert knowledge as a byproduct of the review process and makes it retrievable for future decisions. Their article on institutional knowledge as the real competitive advantage for mechanical engineers is the clearest statement of what they are building toward: not a better review tool, but an institutional memory that compounds over time.
These are not the same arguments made five times. Martin is thinking from PLM architecture. Benedict is thinking from AI reasoning. Doug is thinking from investment and platform design. Adam is building a product that captures the knowledge lost in engineering review processes. I am thinking about broad product data (BOMs) captured across multiple lifecycle stages and the specific problem of how manufacturing organizations actually coordinate around product lifecycle. The convergence across five independent perspectives is the signal. When people arriving from different directions reach similar conclusions, the underlying problem is real.
What follows is my attempt to name that problem precisely, describe the architecture that addresses it, and explain why it requires more than better PLM, better search, or better AI on top of existing systems.
Imagine an engineer three years from now, working on a redesign of a product that shipped in 2022. She opens the PLM system. The BOM and CAD files are there. The revision history is there. The approved supplier record is there. But she has one question the system cannot answer: why was Part A replaced by Part B in revision C?
Was it a supply chain problem? A cost decision? A temporary workaround that became permanent? Did manufacturing approve it, or did they find out after the fact? The record is clean. The context is gone.
This is not an unusual situation. It happens in manufacturing organizations every day, at every scale, across every industry. And it is not a failure of the PLM system. The system did exactly what it was designed to do: it captured the approved record. What it was never designed to do is remember the story behind the record.
That distinction, between the record and the story behind it, is where most of the friction in modern product development lives. And it points toward a different way of thinking about PLM architecture, one that goes beyond the concept of a Single Source of Truth toward something more complete: Product Memory.
What PLM single source of truth actually solved — and where it stops
Before arguing that something is missing, it is worth saying clearly what Single Source of Truth accomplishes. It accomplishes a great deal.
Start with the landscape it was designed for. Every manufacturing organization, at every scale, operates across a fragmented set of systems. For a smaller company, the fragmentation is relatively contained: CAD files for geometry, a PDM system for file and revision management, and an ordering or ERP system for procurement and inventory. Even at that scale, the same part can exist in three different representations with no guaranteed consistency between them.
For larger organizations, the fragmentation is far more complex. A mature industrial manufacturer might operate multiple PDM systems: one for mechanical design, another for electronics, possibly a third for software or firmware. Above that sits a PLM system managing change processes, BOMs, and lifecycle states. Feeding into manufacturing is an MES for shop-floor execution. Underpinning all of it is an ERP, sometimes two ERP systems running in parallel after an acquisition, managing purchasing, inventory, costing, and production planning. Layered on top are supplier portals, quality management systems, and configuration management tools.
This is not a sign of poor architecture. It is the natural result of how organizations grow. Each system was introduced to solve a real problem in a specific domain. CAD vendors are better at geometry management than ERP vendors. ERP vendors are better at financial transactions than PLM vendors. The specialization is rational. The fragmentation is the price of it.
What Single Source of Truth, and the system-of-record discipline that came with it, got right was bringing order to each of these domains. Within the CAD and PDM layer, revision control meant that engineering was no longer working from conflicting versions of the same drawing. Within the PLM layer, item master governance meant that part numbers were not duplicated arbitrarily across programs. Within ERP, costing and inventory records became trusted enough to run the business against.
Before this discipline existed, manufacturing organizations routinely operated with multiple conflicting versions of the same BOM. Engineering had one version. Manufacturing had another. Procurement was working from a spreadsheet that nobody had updated since the last engineering change. Quality was inspecting against drawings that were two revisions behind. The waste was enormous and the risk was real.
Single Source of Truth fixed this, domain by domain. A released BOM means engineering and manufacturing are looking at the same structure. Approved vendor lists mean procurement is not guessing which supplier is qualified. Revision control means there is one authoritative answer, within each system, to the question: what is this product?
These are genuine gains. Organizations that have invested in this discipline have real advantages in quality, speed, and cost. The point is not that SSOT is wrong. The point is that it has a ceiling, and most manufacturing organizations have hit it.
The ceiling appeared when organizations tried to scale the SSOT vision beyond individual domains. If each system manages its own records well, the natural next step seems to be connecting them: one master item record that synchronizes across CAD, PDM, PLM, and ERP. One BOM that flows from engineering through manufacturing to procurement without manual re-entry. One change process that updates every downstream system automatically.
In practice, this vision consistently ran into three categories of problems. Technically, integrations between systems with different data models, different lifecycle states, and different notions of what a part number means proved fragile. Every software upgrade on either side risked breaking the integration. Organizationally, the question of which system owned the master record became a political issue. Engineering believed the PLM was authoritative. Finance believed the ERP was authoritative. Both were right for their domain and neither was willing to be subordinate to the other. And at the process level, enforcing a single master record across systems often meant imposing one function’s workflow discipline on another, which created resistance that no governance policy could fully overcome.
The result, in most organizations, is a hybrid that nobody designed intentionally: each system manages its domain records reasonably well, integrations exist but are maintained with ongoing effort and anxiety, and the gaps between systems are bridged by manual processes, spreadsheets, and tribal knowledge. The SSOT vision was partially achieved. The aspiration to extend it across the full landscape of systems was not.
Where PLM loses engineering knowledge every day
The ceiling appears when you ask not what the product is, but how it got there.
Every manufacturing organization has a formal system and a shadow system. The formal system is the PLM: items, BOMs, change orders, approvals, released documents. The shadow system is everything else: the email thread where a supplier substitution got approved, the Slack message where manufacturing flagged a fixture concern, the meeting where quality raised an issue that got overridden, the tribal knowledge held by the engineer who left eighteen months ago.
The shadow system is not a failure of discipline. It is a rational response to the fact that the formal system was not designed to capture the full texture of product work. PLM captures decisions. It was not built to capture the reasoning behind decisions, the alternatives that were considered, the concerns that were overridden, or the risks that were accepted and then forgotten.
Run a simple test with any cross-functional manufacturing team. Take one real product change, a design engineer replacing a component in a released assembly, and ask each function what happens when the information they need arrives late, incomplete, or wrong. What you hear is always the same: manufacturing maintains its own version of the BOM because it does not trust the one in PLM. Procurement receives part data too late to influence cost. Engineering changes components without knowing the supplier impact. Service discovers substitutions after the product ships.
These are not edge cases. They are the normal operating condition of most manufacturing organizations. The formal system has the record. The actual work happens somewhere else.
There is a harder problem underneath this one. Even when teams want to capture context, they have limited time and no obvious place to put it. The engineer who knows why Part A was replaced is busy. The supplier negotiation that created the exception happened over the phone. The manufacturing concern that got overridden was raised verbally in a review meeting. The system does not prompt anyone to record these things, so they do not get recorded. This is not a discipline problem. It is an architectural one.
The missing layer in PLM: product coordination across systems and teams
Organizations have always known the gap exists. They have been closing it with whatever tools were available.
A decade ago, master data management platforms became the popular answer. The idea was to build a unified view above the fragmented system landscape: one search layer, one consolidated record, pulling from CAD, PDM, PLM, and ERP simultaneously. For a period, these systems were straightforward to build and widely deployed. They gave people a place to find things across systems without navigating each system individually. But they were read-only by nature. They consolidated records. They did not capture the work around the records, and they could not resolve the deeper question of what happened between systems.
Then came Slack and its equivalents. Messaging platforms integrated with engineering and manufacturing systems became the de facto coordination layer for most organizations over the past decade. A supplier approval that used to happen over email moved to a Slack channel. An engineering concern raised in a review meeting got followed up in a thread. A procurement exception got discussed, decided, and forgotten in a message that nobody archived. Messaging systems captured an enormous amount of the real coordination work of product development. They just captured it in a form that is unsearchable by part number, unlinked to any BOM, and gone the moment the person who participated in the conversation leaves the company.
Virtual meetings added another layer. Video calls, recorded or not, became the place where the hardest cross-functional decisions happened. The recording, if it exists at all, is stored somewhere nobody will ever search. The decision it contains is not connected to the change order it influenced.
And underneath all of it, always, is Excel. The spreadsheet that manufacturing maintains because it does not trust the BOM in PLM. The cost model that finance built because ERP does not support the analysis they need. The supplier tracking sheet that procurement updates manually every week because the integration to the approved vendor list broke two years ago and nobody has fixed it. Excel is the universal gap fitter of manufacturing organizations. It works, individually, for the person who built it. It fails organizationally the moment that person is unavailable, moves roles, or leaves.
What all of these tools share is that they are general-purpose. Search systems were built for finding information, not for connecting product decisions to product data. Messaging systems were built for communication, not for structured memory. Meetings were built for conversation, not for institutional knowledge capture. And spreadsheets were built for calculation and analysis, not for coordination. Each was adapted to fill a gap it was not designed for. Each fills it temporarily, partially, and in a form that degrades over time.
The information that lives in this space is not small. Across an organization’s Slack history, email archives, recorded calls, and shared spreadsheets is a substantial portion of the actual product knowledge the organization has accumulated: the decisions that were made, the trade-offs that were accepted, the concerns that were raised and overridden, the supplier negotiations that shaped the BOM. It is all there. It is just not connected to anything. It is not retrievable by product context. And most of it will be lost.
What manufacturing organizations are missing is not another general-purpose tool. It is a designed layer for coordination around product data: a product coordination layer. The distinction matters. A product coordination layer is built specifically for the problem of connecting product decisions to product data, across systems, across functions, and across organizational boundaries. It is not a search interface. It is not a messaging system. It is not a spreadsheet. It is infrastructure, in the same sense that a data layer or an integration layer is infrastructure. It has a defined job: to capture the decisions, handoffs, rationale, assumptions, and open questions that surround product data, and to keep that context connected to the data it explains.
The idea grew up when I was watching how engineering teams drop BOMs into Google Sheet for handoff and collaboration.
When we built a collaborative workspace at OpenBOM, we were solving this problem before we had language for it. We saw that engineering teams and their suppliers needed a structured environment where product data could be worked on together, across company boundaries and used it as a handoff. Then we realized that the same mechanism is extremely efficient in coordinating multiple engineers about the data before it became a formal record. Think about it as a ‘BOM sandbox’. That was an idea that grew up from the re-thinking change management and collaborative layer needed for engineers and other departments and partners to work together.
I think similar ideas lead Jon Hirschtick and Onshape team to develop a better CAD+PDM and a workspace allowing engineers to work together to design live before saving an immutable version of the design.
The collaborative workspace is an early implementation of a product coordination layer: a place where the real coordination work could happen and leave a trace, attached to the actual product objects it concerned, rather than disappearing into a messaging thread or a spreadsheet on someone’s desktop.
What we understand more clearly now is why that mattered architecturally, and why the problem it solves cannot be addressed by making the authoritative data layer better, or by adding another general-purpose tool to the stack. The data layer answers the question: what is correct?
The coordination layer answers a different question entirely: how was correctness achieved, by whom, under what conditions, and with what remaining uncertainty?
How to design a product coordination layer: a 90-minute exercise for manufacturing teams
The product coordination layer is not something you configure in software before understanding how your organization actually works. The configuration comes second. First comes a clarity exercise.
Take one real product change. A component replacement in a released assembly works well. Put it at the center of a 90-minute session with engineering, manufacturing, procurement, quality, service, and whoever owns the PLM and ERP systems. Run five steps.
Start with a lifecycle walk-through. Ask each function what they need from the previous step and what they produce for the next one. Not what they are supposed to do, but what they actually do. This exposes the real lifecycle, not the PowerPoint version of it.
Then build a data ownership map. For every significant object: who creates it, who validates it, who consumes it. The important finding is almost always the same: many things are used by everyone and owned by nobody. That is where coordination breaks down.
Then run the handoff stress test. Ask: what happens when this data is missing, late, wrong, or changed after release? This is where the shadow systems surface. People describe the spreadsheet they maintain because they do not trust the BOM, the Slack channel where approvals actually happen, the tribal knowledge that only two people hold.
Then ask the decision capture question. For every important handoff: what decision was made here, by whom, based on what information, and where is that decision captured? This is where the gap between record and context becomes concrete. The BOM says Part B replaced Part A. Nobody recorded why.
Finally, produce a minimum coordination agreement: a short set of commitments about who owns which data, what constitutes a complete handoff, and what decisions must be recorded before a change can move forward. Not a 40-page process document. A working agreement the team can actually use.
This exercise is not a substitute for PLM configuration. It is the prerequisite for it. You cannot design a coordination layer without first understanding where coordination is currently breaking down. Organizations that skip this step and go straight to system configuration wonder why adoption fails. The system was configured for the PowerPoint lifecycle, not the real one.
PLM single source of truth vs. product coordination: why you need both
The objection worth addressing directly is this: traditional PLM vendors already have collaboration features, change management workflows, supplier portals, and AI roadmaps. What is different here?
The difference is architectural, not feature-level. Those capabilities were designed around the assumption that product knowledge lives in records, and that the job of the system is to manage those records correctly. The product coordination layer is built on a different assumption: that product knowledge also lives in the gaps between records, in the decisions and rationale and context that surround the data, and that this gap cannot be closed by making the record management system more sophisticated.
PLM vendors build a solid and practical system of records to manage engineering and broad product data. What they do not build is a layer designed to capture the work around the record. Their collaboration features are portals into the record system. That is useful. It is not the same thing as a coordination layer that captures context independently of whether it belongs in a formal record.
More importantly, SSOT and the coordination layer are not competing answers to the same question. They answer different questions. Single Source of Truth answers: what is the correct product data? The product coordination layer answers: how was that data created, validated, changed, and understood across the organization? Both are necessary. Neither is sufficient without the other.
The framing that works: Single Source of Truth gives you the record. The product coordination layer gives you the structure to create, validate, and understand the record. One is about correctness. The other is about the process by which correctness is achieved.
Product Memory architecture: connecting authoritative data, coordination, and AI
Product Memory is the name for an architecture that combines authoritative product data with the coordination layer that surrounds it, and the intelligence layer that makes both useful in practice. It has three layers, each with a distinct job.
The authoritative data layer is where Single Source of Truth does its best work. Items, BOMs, revisions, change orders, approved suppliers, compliance records, released documents. This layer reduces duplication and ambiguity. It gives every function a common answer to the question: what is the product? In OpenBOM terms, this is the catalog, the xBOM structure, the change process, the linked product objects. This layer gives you truth. But truth alone is not memory.
The product coordination layer surrounds the authoritative data with context. It captures events, decisions, rationale, assumptions, risks, review outcomes, and open questions. Not as a chat log. As structured memory: who made this decision, why, under what conditions, what alternatives were considered, what risks were accepted, and what still needs to happen. This layer reduces confusion and hidden work. It keeps the story attached to the record.
The workflow and intelligence layer uses the memory to guide work. Agents that surface the right context at the right moment. A review agent that checks whether a BOM is complete before release. A change agent that identifies every downstream impact before an ECO is approved. A procurement agent that flags missing vendor or lead-time information. And increasingly, an inference layer that does not just retrieve what was decided, but connects past decisions to current situations in ways that help people make better choices faster.
The component replacement scenario shows how the three layers work together. In the authoritative data layer, the system records: Part A replaced by Part B, revision B released, ECO-104 approved. This reduces ambiguity. Everyone knows what the approved replacement is.
In the coordination layer, the system captures: Part A had an 18-week lead time risk. Part C was considered and rejected because of thermal performance. Procurement confirmed availability from Vendor B. Manufacturing flagged a fixture update requirement. Quality requested a new inspection step. The supplier qualification for Vendor B is still pending. The decision was approved for prototype build only, with a follow-up task assigned to the quality team.
In the intelligence layer, the system can now answer: why did we change this component? What is still unresolved before production release? If a similar supplier risk emerges on a different part, what does our experience with this one suggest about the timeline and the risk profile?
One area where the coordination layer is hardest and most necessary is at supplier boundaries. Single Source of Truth assumes you can impose your system of record on everyone who contributes to the product. With suppliers, you cannot. A tier-one supplier operates their own PLM, their own revision control, their own change processes. The coordination layer is the place where cross-boundary work can happen and leave a trace without requiring every party to be in the same system. This is where the original collaborative workspace insight applies most directly: coordination across company boundaries requires infrastructure that works at the boundary, not inside either party’s system.
AI in PLM: why inference matters more than retrieval
Much of the current conversation about AI in PLM is about retrieval. Ask the system a question. Get an answer from the data. This is useful, but it is not where the architectural value lies.
The more significant capability is inference. A system that can answer why did we change this supplier last year is helpful. A system that can say, based on what happened with this supplier in 2021, and given the current state of this BOM and this supply chain, here is the risk profile of the proposed change you are considering, is something qualitatively different. That is not retrieval. That is the system reasoning across time, connecting past experience to present decisions in a way that reduces the cost of judgment.
This capability only exists if the coordination layer has been capturing context consistently enough to build genuine product memory. An AI layer built on top of a pure record system can retrieve records faster. An AI layer built on top of a coordination layer can help teams avoid repeating the mistakes that were recorded but never connected forward. That is the architectural difference, and it is why Product Memory is not just a better name for PLM. It is a different design premise.
Measuring the product coordination layer: outcomes for manufacturing organizations
Product Memory architecture is not a philosophical position. It has operational consequences that manufacturing organizations can measure.
The most direct one is the cost of engineering changes. In most manufacturing organizations, a significant portion of ECO cost is not the change itself but the effort to understand its impact: which BOMs are affected, which suppliers need to be notified, which inspection requirements change, which downstream systems need updating. A coordination layer that captures this context at the time decisions are made dramatically reduces the reconstruction cost when a change is initiated. Organizations that have invested in this have seen ECO cycle times cut by a third or more, not because the approval process got faster, but because the impact assessment got faster.
A related measure is the number of unresolved assumptions at BOM release. Think about intelligent BOM Review. Every BOM released with open questions, unvalidated assumptions, or deferred supplier qualifications carries hidden risk forward into manufacturing and procurement. A coordination layer that makes these visible before release, and requires them to be explicitly accepted as risks rather than silently ignored, reduces the downstream cost of surprises. The target is not zero assumptions at release. The target is zero invisible assumptions.
Supplier qualification cycle time is a third measure. When the context of previous supplier decisions is captured and accessible, new supplier evaluations do not start from scratch. The organization can see what it learned the last time it qualified a supplier for a similar component, what risks materialized, what the qualification process revealed. This compresses the cycle and improves the quality of the decision.
None of these outcomes requires a complete architectural transformation. They require starting with the coordination exercise described earlier, identifying the two or three highest-cost gaps in the current handoff model, and building the coordination layer around those specific gaps first. The architecture scales from there.
What is my conclusion? Post-SSOT is the architecture manufacturing needs now
The engineer from the beginning of this article, trying to understand why Part A was replaced by Part B, represents a failure mode that most manufacturing organizations have accepted as normal. The PLM system has the record. The context is gone. The organization will spend time and money reconstructing a decision that should have been remembered.
Product Memory is the architecture that makes that failure mode avoidable. Not by replacing the authoritative data layer. Not by abandoning the discipline of Single Source of Truth. But by surrounding the record with the context that gives it meaning: the decisions, the rationale, the assumptions, the risks, and the actions that explain not just what was approved, but how the organization got there.
Single Source of Truth was the right answer to the problem of the 1990s and 2000s: product data was fragmented, inconsistent, and untrusted. The discipline of centralized, controlled records fixed that, at significant cost and effort, for many organizations.
The problem of the 2020s is different. Product development is too distributed, too fast, and too cross-functional to be managed by records alone. Engineering, manufacturing, procurement, quality, and suppliers contribute to product knowledge from different systems, different organizations, and different time zones. The coordination between them is where most of the value is created and most of the risk is carried. And that coordination, for most organizations, leaves no trace.
Product Memory is post-SSOT. It accepts that trusted records are necessary and continues to build them. It adds what was always missing: a layer that remembers the work around the records, connects that memory to the people who need it, and makes the intelligence latent in years of product decisions accessible to the engineers and managers working on the product today.
Trusted data. Remembered context. Guided action. That is the architecture the next generation of manufacturing organizations will be built on.
Just my thoughts…
Best, Oleg
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.
