The Product Memory Flywheel: Rethinking PLM, Product Data Management, and the Digital Thread

From Document Control to Continuous Product Intelligence

Engineering teams today are surrounded by product data, yet many organizations still struggle to understand their own products clearly.

In my previous article about fixing product data chaos in engineering teams, I introduced the concept of Product Memory — a structured way to capture, connect, and maintain product knowledge across the lifecycle of a product.

Many engineers immediately recognized the problem. Product data is everywhere: CAD files, spreadsheets, ERP systems, supplier portals, engineering notebooks, and shared folders nobody is quite sure are current. Every company has its own version of this mess. And despite decades of PLM systems and product data management software, engineering teams still spend a surprising amount of time answering questions that should be trivial.

What is the correct product structure? Which version of the BOM is current? Which supplier parts are actually approved? What changed since the last release?

These questions sound simple, yet in many organizations they remain surprisingly difficult to answer. CAD files often become disconnected from engineering BOM structures. Purchasing teams maintain their own spreadsheets to track supplier components. ERP systems frequently receive product structures late, incomplete, or inconsistent. Engineering change processes sometimes begin only after problems appear in manufacturing or procurement.

At first glance this situation seems paradoxical. Product lifecycle management (PLM) has been a mature industry for more than twenty years. Enormous resources have been invested in PLM implementations. Yet the daily experience of many engineering organizations still feels fragmented, manual, and oddly artisanal for something that is supposed to be under software control.

The reason is subtle but important. Most PLM systems were originally designed with a big vision mostly focusing these days to control documents, not to continuously organize and understand product knowledge. At the same time, many engineering and manufacturing teams are using CAD and PDM while managing the entire downstream process using spreadsheets, emails and chats. 

Engineering teams became very good at managing files and approvals. They can track revisions, enforce release workflows, and maintain audit trails. But the knowledge that actually defines the product — the relationships between parts, suppliers, costs, configurations, and engineering decisions — continued to live across many systems and tools.

This is where the idea of Product Memory begins.

But once we introduce Product Memory, another question immediately follows. If Product Memory captures product knowledge, how does that knowledge actually improve over time? How does an organization become smarter about its own products as engineering work progresses?

That question leads to the idea of the Product Memory Flywheel.

What Is Product Memory in Product Lifecycle Management (PLM)?

Product Memory should not be confused with a traditional document repository or a simple replacement for an existing PLM database. Instead, it represents a structured and continuously evolving representation of product knowledge.

Within Product Memory, information about the product becomes connected. Parts and assemblies relate to suppliers and sourcing options. Engineering structures connect to cost information and lifecycle states. Product configurations and variants are linked to the engineering decisions that created them.

This distinction is important because engineers rarely think about products as collections of files. When engineers design a system, they think about components, interfaces, dependencies, constraints, supplier options, and design tradeoffs. Product Memory attempts to capture this network of relationships in a form that can be analyzed, shared, and improved over time.

Unlike traditional PLM records usually representing released documents, Product Memory evolves as the product evolves. It grows richer as engineering teams interact with the product structure and add knowledge from manufacturing, suppliers, and field experience.

This raises the natural next question: if Product Memory represents product knowledge, how does that knowledge develop and improve?

The answer is the Product Memory Flywheel.

Why Traditional Methods Struggle with Modern Product Data

For many years the PLM industry promoted a simple and appealing vision. The idea was that a single system with a single database could contain everything related to the product lifecycle. If every engineering artifact could be stored in one platform, the entire lifecycle could theoretically be controlled from one place.

This approach worked reasonably well during the era when PLM systems focused primarily on document vaulting and significantly focused on MCAD. Drawings and CAD files were checked into a central repository, revisions were controlled, and approval workflows ensured compliance with release procedures.

However, modern product development environments look very different from the environments where that model originated.

A single product today may span mechanical CAD models, electrical schematics, electronics designs and PCB, embedded firmware, cloud and mobile software, simulation results, supplier catalogs, planning systems, and manufacturing execution platforms. Each of these environments uses specialized tools optimized for a specific domain.

Trying to force all of that information into one monolithic PLM database often creates friction rather than clarity. Integration becomes complex. Adoption slows down. Engineers, who are usually pragmatic about their tools, tend to route around systems that interfere with their daily work. Beyond that, tons of spreadsheets, mails, legacy databases are involved. 

What organizations increasingly need is not a single database that contains everything. Instead, they need an architecture capable of organizing product knowledge across systems, connecting the dots without forcing every system into the same platform.

Companies come these days and “search for AI that can help to solve the problem”, but they often miss the point. This is where Product Memory becomes particularly interesting.

The Product Memory Flywheel: A New Model for Product Data Management

Product knowledge does not appear all at once. It accumulates gradually as engineering teams design, review, improve, and build products. Information emerges from design work, supplier collaboration, manufacturing feedback, and lessons learned in the field.

The Product Memory Flywheel describes how this knowledge grows through continuous cycles of engineering work. Instead of treating product data as something static that is captured once and stored, the flywheel views product knowledge as something that evolves continuously.

Each rotation of the flywheel involves three connected activities. Engineering data must first be captured from the systems where design work occurs. That information must then be reviewed collaboratively so teams can understand the product structure and manage engineering change. Finally, the information must be synchronized across multiple downstream and upstream functions, procurement, manufacturing planning, and service systems so the entire organization works from the same product knowledge.

Over time these cycles reinforce each other and gradually build product intelligence.

Product Memory Flywheel Diagram

Check the picture with a Product Memory flywheel. It represents the process of work with the product information. It has three main stages – (1) Connect; (2) Review; (3) Flow.  Let speak about each of them in a more details. 

Image title: Product Memory Flywheel for PLM and Product Data Management
Image alt text: Product Memory Flywheel diagram showing capture, review, and synchronization of product data across engineering, ERP, and manufacturing systems

Capturing Product Data from Engineering Work

Modern products rarely originate from a single design environment. Mechanical engineers typically work in MCAD systems. Electronics engineers design circuits and PCB layouts using ECAD tools. Embedded software teams develop firmware within their own toolchains. Systems engineers often define functional structures and configurations in yet another environment.

Each of these activities produces valuable information about the product. Assemblies and drawings describe the physical structure. Supplier data and part numbers connect the design to the supply chain. Cost estimates reveal the financial implications of design decisions. Design attributes describe performance characteristics and engineering constraints.

Historically, much of this information remained trapped inside the tools that generated it.

Today, technologies such as CAD integrations, APIs, automated data extraction, and AI-assisted interpretation make it increasingly possible to convert engineering artifacts into structured product knowledge rather than simply storing them as files.

The goal is straightforward. Engineering artifacts should become structured product data, not static files stored in folders.

This transformation represents the first rotation of the Product Memory Flywheel.

Reviewing the Product and Managing Engineering Change

Once product data is captured and organized, something important becomes possible. Engineering teams can examine the product as a coherent system rather than as a disconnected collection of files.

Questions that were previously difficult to answer suddenly become easier. Teams can see whether the design is complete, whether every component has an approved supplier, what the design may cost, and where potential risks exist.

Traditional PLM systems placed heavy emphasis on approval workflows that occur after the design has been finalized. In practice, the real value often lies earlier in the process, when teams still have the ability to improve the product structure before it becomes locked.

When product data is organized through Product Memory, engineers, supply chain specialists, and product managers can collaborate directly around the evolving product structure. Discussions, tasks, and design reviews can take place within the product data itself rather than through disconnected documents and emails.

Increasingly, AI systems may also assist by identifying missing data, suggesting suppliers, or highlighting potential risks.

At this stage Product Memory becomes more than a repository of information. It begins functioning as a decision support system for engineering teams.

Synchronizing Product Data Across the Organization

Products do not exist only within engineering teams. As designs mature, product information must flow across the organization so that procurement, supply chain, ERP, manufacturing, and service teams can operate effectively.

Historically this information moved through manual handoffs. Engineers exported spreadsheets or documents, which were then re-entered into downstream systems. By the time the data reached its destination, it was often already slightly outdated.

Modern engineering environments increasingly replace this process with automated synchronization between systems. APIs allow product structures to move directly between engineering platforms and ERP systems. Integration layers ensure that changes propagate automatically. Agent-based workflows can monitor updates and keep downstream systems synchronized in near real time.

When these mechanisms work properly, the digital thread becomes something tangible rather than theoretical.

Equally important, information can flow back upstream. Manufacturing teams may identify assembly constraints. Suppliers may update availability. Procurement teams may find cost optimization opportunities. Service organizations may report product failures observed in the field.

All of this feedback enriches the underlying Product Memory.

Why the Product Memory Flywheel Matters

The concept of a flywheel is important because it describes a system that builds momentum. Each rotation reinforces the next.

Within the Product Memory Flywheel, product knowledge flows through a continuous cycle of capture, review, and synchronization. Each cycle generates insights that improve the underlying product data. As this process repeats, the organization gradually accumulates a richer understanding of the product.

This dynamic differs significantly from the traditional PLM model where a product record is created, approved, and stored as a final artifact.

Product Memory is not static. It is a living representation of the product that becomes more valuable as engineering teams interact with it.

The more the flywheel spins, the more product intelligence accumulates.

Composable PLM Architecture: Moving Beyond the Single Database

The flywheel model also implies a different way of thinking about PLM architecture.

Traditional PLM systems attempted to centralize everything within a single platform. While it was a very solid and sounded well idea, in practice it never really happened well. In reality companies work with multiple enterprise systems, while many engineering and manufacturing teams are using combinations of PDM systems, spreadsheets, different collaboration tools, SharePoint storages and cloud drives. 

Modern engineering environments, however, are inherently distributed. Multiple specialized tools coexist within the same product development ecosystem.

A composable architecture aligns better with this reality. Engineering tools continue to capture design information. Product Memory platforms organize and structure product knowledge. Integration layers synchronize information between systems. Analytics tools extract insights from the accumulated data.

Instead of forcing all systems into one database, these components collaborate through APIs and integrations.

This model reflects how engineering organizations actually operate today — as ecosystems of specialized tools that must work together rather than as tightly controlled monolithic environments.

Conclusion: A Question for the Future of Product Platforms

PLM systems were originally designed to control product information — documents, revisions, approvals, and release workflows. That was the right problem to solve for the environment in which those systems were created.

But engineering environments have changed dramatically. Product development now spans multiple disciplines, tools, and organizations. Information flows continuously across engineering, supply chain, manufacturing, and service.

The question worth asking today is no longer simply how to control that flow more tightly. The more interesting question is how to make the entire system smarter over time.

Should product platforms function primarily as systems of control?

Or should they evolve into systems of product intelligence?

The Product Memory Flywheel suggests one possible direction.

And perhaps the most interesting aspect of this idea is that many of the technologies required to build this flywheel already exist. The challenge is not primarily technical. The harder part is learning to think about product information differently — not as something that must simply be stored and controlled, but as something that can continuously learn.

At OpenBOM, we are developing a new architecture of digital systems. Stay tuned with our announcements and research. Would you like to talk more about how OpenBOM can help you today – contact us directly at OpenBOM support. 

Best, Oleg 

FAQ: Product Memory and the Product Memory Flywheel

What is Product Memory?

Product Memory is a structured representation of product knowledge that connects parts, suppliers, BOM structures, configurations, lifecycle data, costs, and additional related information (e.g. comments, notes, actions), etc. It allows engineering teams to continuously capture and improve product intelligence across the lifecycle.

What is the Product Memory Flywheel?

The Product Memory Flywheel describes a continuous cycle where product data is captured from engineering work, reviewed collaboratively, and synchronized across engineering, ERP, supply chain, and manufacturing systems.

How is Product Memory different from traditional PLM databases?

Traditional PLM systems primarily manage documents, BOMs and approval workflows. Product Memory focuses on organizing product knowledge and continuously improving product data through collaboration and automation. It can be easily shared across multiple companies and teams and collect not only released data, but the entire context graph of information associated with the product. 

Why is composable architecture important for modern PLM?

Modern engineering environments rely on many specialized tools. Composable PLM architectures allow these tools to integrate through APIs instead of forcing all product data into a single monolithic database.