Who Owns Product Knowledge? The Hidden Problem with PLM and Data

Why CAD, BOM, ERP, Excel, and even PLM don’t actually own your product knowledge.

Everyone knows who owns CAD. Engineering. Everyone knows who owns ERP. Operations, finance, supply chain. These are settled questions:  the kind that get answered in the first week of onboarding and never revisited.

But ask who owns product IP and knowledge, and something shifts.

In a smaller engineering team, the answer usually points at a person, the engineer who’s been around longest, the one you go to when you need to understand why something was designed a certain way. In a larger enterprise, the answer gets more institutional, PLM owns it, or engineering configuration management, or a team with “governance” somewhere in its name.

Both answers sound reasonable. Neither one holds up.

Ask the follow-up: where is your product IP actually stored? Not the files. Not the records. The knowledge – the decisions, the reasoning, the trade-offs that explain why your product is the way it is.

In the smaller company, someone starts describing a spreadsheet. In the enterprise, someone describes three systems that don’t quite connect, and a fourth that was supposed to fix that but didn’t really.

The confidence looks different. The underlying problem is identical.

Product IP and knowledge is the real competitive asset of a manufacturing company has no clear owner. It’s fragmented across systems, buried in tools that were each built for something else, and carried in the heads of people who may not be around next year.

That’s what this article is about.

Product Knowledge Fragmentation Across CAD, BOM, and ERP Systems

Here’s the thing – product IP and knowledge isn’t missing. It exists. It’s just scattered.

CAD holds the geometry, the design intent, the physical shape of the thing you make. BOM holds the engineering structure – what parts, how many, how they relate. Sometimes BOM extends into manufacturing views or service views, but that extension is almost always manual, almost always a copy, almost always approximate.

ERP holds execution. Supply chain, procurement, orders, inventory. It knows what you bought and what you built. It doesn’t know why.

And then there are the spreadsheets. There are always spreadsheets. They hold the analyses that didn’t fit anywhere else, the cost estimates that live in someone’s folder, the comparison tables that were built during a supplier decision and never cleaned up.

This is how product IP and knowledge actually lives in most manufacturing companies.

Now here’s the point that usually surprises people: this is not a system problem. Every one of those systems is doing exactly what it was designed to do. CAD manages geometry. ERP manages execution. They’re not broken.

The problem is that together, they reveal something far more uncomfortable: there is no single owner of product IP and knowledge. There is no unified view. And there is no one with clear responsibility for making sure that IP and knowledge stays connected, coherent, and findable.

That’s an organizational ownership problem. And it’s more costly than most companies realize.

Because product IP is not just files. It’s not just records and revision histories. Your product IP is the decisions you made. The trade-offs you worked through. The reasoning that explains why the design went in one direction and not another. The change history that tells the story of how the product evolved.

And right now, that IP is fragmented. Most of it exists only in the heads of the people who were in the room when it happened.

Why PLM Systems Fail to Capture Product Knowledge 

The natural response here is to point at PLM. That’s the system explicitly designed to manage product data across the lifecycle. And PLM vendors have spent decades positioning their products as the authoritative home for product IP and knowledge.

But let’s be specific about what PLM actually does.

PLM captures records. It manages revisions. It enforces workflows and approval processes. It gives engineering teams a structured place to store and track their work. These are genuinely useful things.

What PLM does not capture is the decision-making process behind the work. It doesn’t record the reasoning. It doesn’t hold the context of the conversation in which an engineer pushed back, a cost target was renegotiated, or a supplier constraint forced a design change. It stores the outcome – the approved document, the released revision – but not the understanding that led there.

There’s a phrase I keep coming back to: PLM owns snapshots, not memory.

A snapshot is the state of something at a point in time. A revision. A release. A configuration. Snapshots are important. But they’re not the same as understanding why you’re in that state, or how you got there.

Product IP is different. It’s contextual. It connects things. It accumulates over time. It makes the past legible so the present makes sense and the future can be planned thoughtfully.

PLM was built to manage snapshots. It was not built to carry product IP and knowledge.

The Cost of Missing Product Knowledge in Manufacturing Organizations

This might sound abstract, so let me make it concrete.

Someone on your team wants to understand a design decision that was made three product generations ago. Why did you choose that supplier for that component? Why is the tolerance set the way it is? Why does the assembly sequence work the way it does?

They start looking. They find the released drawings in PLM. They find the BOM in ERP. Maybe they find a change notice that references a problem that was solved. But the reasoning – the engineering discussion, the trade-off that was made, the context that would actually answer the question – that’s gone. It lives in an email thread that was never archived, in the memory of an engineer who left two years ago, in a meeting that was never documented.

So what happens? The team either makes a guess, or they start over. They redesign something that already has a good reason to exist. They repeat an analysis that was done before. They make a decision without understanding the constraints it was made under the first time.

This pattern has a real operational cost. It slows down onboarding – new engineers take years to become productive because product IP isn’t accessible, it can only be absorbed through proximity to people who already carry it. It slows down decision-making – every complex choice requires context reconstruction before it can be made. It creates accountability gaps, because when a decision can’t be traced, it also can’t be evaluated, learned from, or improved.

The more insidious cost is cultural. When people can’t trust the knowledge infrastructure – when they don’t know if what they’re looking at is current, complete, or the full story – they stop relying on it. They start maintaining their own local versions, their own spreadsheets, their own parallel records. Which further fragments the product IP. Which makes the problem worse.

Rethinking Ownership of Product Data and Knowledge

The instinct, when you see this kind of fragmentation, is to ask which system should own product IP and knowledge. Should it be PLM? A new platform? An integrated data layer that connects everything?

But I think that framing misses the real issue.

The problem is not which system holds the data. The problem is that we’ve confused data ownership with IP and knowledge ownership. They’re not the same thing.

Data ownership is about where something is stored. It’s a technical and administrative question. Engineering owns the CAD files. Operations owns the ERP records.

Product IP and knowledge ownership is different. It’s about responsibility – responsibility for making sure that the product’s reasoning is captured, connected, and reusable. Responsibility for ensuring that when someone needs to understand a decision, that understanding is findable. Responsibility for the continuity of what the company knows about what it makes.

That kind of ownership doesn’t live in a system. It lives in the organization’s practices, its culture, the habits it builds around capturing context alongside data.

When companies start to take this seriously – when they move from asking “where is the data?” to asking “what do we actually know about our product, and how do we keep knowing it?” – they start to approach something that functions more like Product Memory. Not just a repository of files and records, but a living accumulation of product IP and understanding that grows as the product evolves and can be drawn on when it matters.

Who Really Owns Product Knowledge?

If you ask most manufacturing companies who owns product IP and knowledge, you’ll eventually get an answer. Someone will claim it  engineering, or PLM, or a product manager, or the CTO.

But if you follow up with a concrete scenario – “someone needs to understand why we made this design decision five years ago, who do they ask and where do they look?” – the answer usually falls apart quickly.

The claim of ownership and the reality of access are two very different things.

Companies that treat product IP and knowledge as a serious organizational asset – that invest in capturing not just what was decided but why, not just what was built but how it evolved – build a compounding advantage over time. Their engineers make fewer repeated mistakes. Their onboarding is faster. Their institutional memory survives turnover.

The companies that don’t keep relearning the same lessons. Over and over again, from scratch. Everyone owns data. No one owns product knowledge.

REGISTER FOR FREE and check how OpenBOM can help. 

Best, Oleg