This is the last post in a series of 30 blogs about OpenBOM. That matters less as a milestone and more as a forcing function. Writing every day for a month has a way of stripping away surface arguments. What remains are the ideas that keep resurfacing even when you are not trying to make a point.
This series did not start as a manifesto. Most posts were grounded in practical topics: BOMs, PDM limitations, spreadsheets, collaboration, digital threads, and more recently AI. But somewhere along the way it became clear that these were not separate conversations. They were different expressions of the same underlying tension: engineering teams are surrounded by software, yet still struggle to work with product data in a coherent way.
This article is not a summary of what came before. It is a pause. A moment to explain what all of this work has been converging toward, and how we think about the direction ahead.
The Control Story That Shaped PLM
For a long time, the dominant story in PLM has been about control. Control of files, control of revisions, control of processes. The underlying assumption was that complexity could be managed by centralizing information and constraining behavior.
That approach made sense in an earlier context. Products were simpler. Teams were co-located. Hand-offs were more linear. Systems were designed around clear phases and gated transitions.
What has changed is not the intent of those systems, but the environment in which they are used. Engineering work no longer follows clean lines. Decisions overlap. Feedback arrives late. Supply chains change mid-project. Yet many of the tools in use today still assume a level of predictability that no longer exists.
When reality drifts away from that model, the system does not adapt. People do.
How Engineering Work Actually Unfolds
When you look at how engineering teams actually work, a different picture emerges. Design, planning, sourcing, and manufacturing considerations start early and evolve together. Multiple people look at the same product data with different questions in mind, often at the same time.
This is not a disorder. It is how complex systems are built.
The problem is that many tools still expect work to happen in sequence. Information is supposed to be complete before it is shared. Decisions are supposed to be final before they move forward. That expectation does not hold up in practice.
Instead, teams are forced to improvise. They create temporary structures, side calculations, and parallel conversations to bridge the gaps. None of this is malicious or careless. It is adaptive behavior in response to rigid systems.
Why People Export Data
Spreadsheets show up in these situations for a reason. They are flexible. They allow people to reshape data quickly to answer a specific question or explore an alternative.
The issue is not that spreadsheets exist. The issue is what happens once data leaves the system. Context is lost. Relationships are flattened. Decisions become detached from the product structure they were based on.
When this happens repeatedly, knowledge fragments. Teams spend more time reconciling information than using it. The system remains technically correct, but practically irrelevant.
This is not a tooling gap. It is a modeling gap.
Starting From Data, Not Files
OpenBOM started from a different premise. Instead of treating files as the primary asset, we focused on data itself. Items, structures, relationships, attributes, and links became the foundation.
Files still matter. Drawings and models carry critical information. But they are not sufficient on their own. They do not express how a product is assembled, sourced, or changed. They do not capture trade-offs or alternatives.
Once product data is treated as a structured dataset, rather than an attachment to files, new possibilities emerge. Information becomes easier to connect, reshape, and reuse without losing meaning.
One Product, Many Valid Structures
One of the first consequences of this shift is the recognition that there is no single correct structure for a product. Engineering, manufacturing, procurement, and project teams all view the same product through different lenses.
Trying to force all of those perspectives into one hierarchy usually leads to compromises that satisfy no one. This is why multiple structures are not an exception, but a necessity.
In OpenBOM, different BOMs are not copies or exports. They are different views of the same underlying data. Changes propagate, but perspectives remain distinct.
This does not eliminate complexity. It makes it explicit.
Collaboration Lives With the Data
Once multiple people work with the same product data at the same time, collaboration becomes unavoidable. The question is whether the system supports it, or whether it happens elsewhere.
When collaboration tools are separated from product data, conversations drift away from context. Comments lose their anchor. Decisions become hard to trace.
We approached collaboration as something that belongs with the data itself. Reviews, comments, and tasks are not side channels. They are part of the same working space as the structure being discussed.
This does not make collaboration perfect, but it keeps it grounded.
Why No Single System Can Own the Product
Another pattern that emerged throughout this series is the limitation of monolithic thinking. No single system can cover the full range of modern engineering work without becoming rigid.
Products move through CAD, PDM, ERP, MRP, supplier systems, and planning tools. Each has a role. Problems arise when data cannot move between them without distortion.
OpenBOM was designed to coexist with other systems, not replace them. Integration is not a feature added later. It is the only way product data can remain relevant across different stages of work.
Composable systems are not about choice. They are about resilience.
The Problem of Lost Continuity
As products move from concept to delivery, something subtle often disappears: continuity. Decisions are made, alternatives are considered, constraints are discovered, and trade-offs are negotiated. But much of that reasoning is not preserved.
What remains are snapshots. A released BOM. An approved change. A revision number. These are important, but they do not explain how or why the product arrived at its current state.
When continuity is lost, teams are forced to reconstruct intent repeatedly. This slows work and increases risk.
Thinking in Terms of Product Memory
This is where the idea of product memory becomes useful. Not as a formal definition, but as a way of thinking.
Product memory is the accumulation of structure, decisions, relationships, and context over time. It is not just what the product is, but how it came to be that way.
When product memory exists, teams do not start from zero at every phase. They build on what is already known. Data carries meaning forward instead of resetting.
This perspective reshapes how systems are designed and how they are evaluated.
What This Changes About AI
There is a lot of discussion about AI in engineering systems. Some of it is thoughtful. Some of it assumes that intelligence can compensate for missing structure.
Without connected, well-modeled data, AI has little to reason about. It can generate output, but it cannot understand context or consequences.
We see AI as something that should sit on top of product memory, not replace it. When data is structured and connected, assistance becomes possible. Change impact can be analyzed. Alternatives can be explored. Cognitive load can be reduced.
Without that foundation, AI becomes noise.
Beyond the Boundary of One Company
Most products today are built across organizational boundaries. Suppliers, manufacturers, and partners all hold pieces of the product story.
If product data cannot move across those boundaries without losing meaning, the digital thread breaks. File transfers freeze information. Exports create divergence.
A multi-tenant, cloud-based approach allows product data to remain connected while respecting boundaries. Not everyone needs access to everything, but the structure must support continuity across the network.
Infrastructure That Fades Into the Background
The ultimate goal is not to make systems more visible. It is to make them less noticeable.
When product data works, teams spend less time managing tools and more time making decisions. Planning becomes part of the flow of work instead of a separate exercise. Collaboration feels natural rather than forced.
Good infrastructure does not demand attention. It supports work quietly.
Conclusion: Product Memory and Collaborative Work
As this series comes to an end, one idea stands out more clearly than it did at the beginning. Product memory is not something separate from data. It is data, structured in a way that preserves meaning over time, including the history of changes and multiplied by a history of operations. This is a goal we are building towards.
When product data is fragmented across files, exports, comments, and side conversations, memory disappears. Teams may still move forward, but they do so by constantly reconstructing context. They repeat discussions, revisit decisions, and spend energy figuring out what is current instead of working on what matters next.
Product memory begins to exist only when data stays connected. Structure, changes, decisions, alternates, costs, and discussions all remain part of the same system, evolving together. Not frozen into documents, not scattered across tools, but available as a continuous record of how the product is taking shape.
This is also where collaboration tools matter (BOM Review), but not in the way they are usually discussed. Collaboration is not about adding more communication. Most teams already communicate constantly. The problem is that conversations are disconnected from the data they are about. The new BOM Review connects these two together.
When collaboration tools are tied directly to product data, they stop being distractions and start becoming anchors. Reviews, comments, and tasks do not pull people away from the work. They keep attention on it. They reduce the need to search for context, reconcile versions, or translate intent from one tool to another.
In that sense, collaboration tools are not about speed. They are about focus. They help teams stay aligned on what needs to be done, why it needs to be done, and what has already been decided.
This is the direction we are building toward. To put the product data that carries memory, and collaboration tools that keeps teams grounded in the work instead of managing around it.
This post is not a conclusion in the sense of an answer. It is a checkpoint. A clearer understanding of what matters and what does not. The work continues.
REGISTER FOR FREE to check how OpenBOM can help you.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
