Back to profile

Why PDM Feels Broken (Even When It "Works")

I did not start out wanting to rethink PDM. In fact, for a long time, I assumed PDM was a solved problem. Files go in. Versions are tracked. Approvals happen. Audits pass. On paper, everything works.

And yet almost every engineer I know quietly works around PDM instead of with it. That bothered me.

"If PDM Exists, Why Is Everyone Still Using Excel and Slack?"

This question came to me not as a big architectural thought, but as a recurring irritation. Why is the BOM in Excel again? Why is change impact discussed in meetings instead of tools? Why does every "small change" feel risky? Why does manufacturing feedback arrive late, incomplete, or not at all?

None of this is because people are careless. It is because PDM systems do not think the way engineers think. They store. They lock. They version. But they do not help. Engineers do not want another place to upload files. They want answers.

The First Crack: PDM Is a System of Record, Not a System of Reasoning

At some point, I stopped blaming users and started blaming the mental model. Most PDM systems are built around a simple idea: "If we store everything correctly, intelligence will emerge." It does not.

What you actually get is perfect traceability, rigid workflows, brittle change processes, and a lot of human glue in between.

The Moment I Realized "Files" Are the Wrong Primitive

Traditional PDM thinks in terms of files, folders, revisions, lifecycle states.

But engineers think in terms of intent, relationships, consequences, tradeoffs.

A drawing revision does not tell me what actually changed, why it changed, what else it affects, or whether it is safe. So engineers do what humans always do when tools do not help: they bypass them.

BOMs Are Where the Pain Really Shows

Every PDM system claims to manage BOMs. But if you have worked on anything non-trivial, you know the truth: BOMs are treated like reports, not like living structures. Flattened. Exported. Re-imported. Broken. Variants become spreadsheets. Alternates become comments. Context disappears. And the bigger the product, the worse it gets.

That is when I started suspecting that the BOM problem is not UI or workflow - it is structural.

Why Change Management Feels So Heavy

Most PDM systems slow engineers down in the name of control. Change requests. Approvals. Meetings. Reviews. All necessary, but also exhausting.

The irony is that the systems enforcing all this rarely help you understand the change. They make sure it is documented. Not that it is understood. So humans step in. Again.

Cloud Did Not Fix This (Because It Was Not the Point)

A lot of modern PDM marketing talks about "cloud-native." But moving a file vault to the cloud does not change the core issue. If the system is still file-centric, workflow-heavy, and intelligence-light, then it is the same problem, just with a login screen. Cloud enables something better. It does not magically create it.

The Subtle Inefficiency No One Measures

Here is the inefficiency that rarely shows up on dashboards:

None of this shows up as a red flag. It just quietly taxes every product. That is when I stopped asking, "How do we improve PDM?" and started asking, "What is PDM actually supposed to do?"

The Shift in My Thinking

I do not think PDM is obsolete. I think it is incomplete. It was built for storage, compliance, and control. But the world now needs reasoning, context, adaptability, and feedback loops. Especially when manufacturing, repair, and robotics are entering the picture.

Where This Series Is Going

This post is intentionally incomplete. Because the problem is not one thing. In the next posts, I want to unpack:

But before all that, I wanted to start here. With the feeling many engineers have, but rarely articulate: "This system works... but it is not on my side." That is the gap worth fixing.