Did PLM ever become more than PDM with a bigger marketing budget? Before we can answer that question honestly, we need to admit a problem with the question itself. The history of engineering data management is almost always told through the experience of mechanical CAD vendors, and a history with one narrator leaves out most of the witnesses. It leaves out the AEC and electrical design teams who were bringing files under version control in the early 1990s, the ECAD and PCB vendors who built their own data management capabilities, and the collaboration that early systems already supported before anyone printed a lifecycle diagram. Until we recover those parts of the story, every debate about whether PLM was real or invented is being argued from an incomplete record.
Product Memory Book and The Question Doug Macdonald Raises
The long weekend in the U.S. is the best time to work on my book and catch up on industry publications. This one came across and landed exactly at the place where I wanted it to land – Doug Macdonald’s conversation with Juliann Grant and Jonathan Scott in Razorleaf’s Stay Sharp Episode 151 is exactly what I was looking for writing historical chapters.
Doug brings a long career and some wonderful early industry stories to the discussion, starting with his encounter with PDM at Ford in 1985, which began with something very practical: finding CAD files that had been moved onto backup tapes. The discussion challenges a familiar industry story in a useful way. The standard account says PDM managed files, then PLM arrived and expanded everything to the lifecycle. Doug reminds us that the boundary was never so clean, because in his account PDM already supported MRP integration and change control before PLM became the accepted label.
The Label, the Software, and the Practices Are Three Different Histories
Doug’s strongest criticism concerns the distance between what vendors promise and what customers actually use. A lifecycle diagram can cover an entire business while the implementation remains concentrated on engineering files, BOMs, and changes, and calling that implementation PLM does not automatically expand what it accomplishes. That criticism lands. But the persistence of familiar functions does not settle whether anything meaningful changed, because two systems can both offer change management while involving different people, controlling different information, and reaching very different parts of a business. A feature name tells us less than the work it supports, which is why we need to separate three things the industry routinely collapses into one: the history of the label, the capabilities of the software, and the practices of the customer. Without that separation, criticism of marketing becomes just another oversimplified history.
PDM Was Never Only Mechanical: AEC, Electrical, and Electronics
The mechanical framing makes the problem especially visible. In the interview, Doug describes an earlier world in which product data was essentially MCAD data, and my own experience in the early 1990s gives me a broader picture. I was involved in several projects bringing CAD files under version control in architecture, engineering, and construction, as well as electrical design. We were dealing with engineering information that needed to be managed as teams worked on it, and the need extended across disciplines and industries. PDM, sometimes discussed under the name TDM, was already being developed and adopted in these environments. The terminology varied, but the practical problem was recognizable everywhere: how do you keep control of engineering files while allowing a team to work together?
Electronics had its own development path as well. I remember ECAD and PCB vendors developing and adopting their own data management capabilities, and during the 1990s they also explored how TDM and systems associated with mechanical CAD could be used to manage drawings. The evidence of these vendors exists and I took part in some of the meetings with leading EDA vendors considering acquiring and using existing PDM software for EDA design. There was both independent development and an exchange of ideas and tools across these areas. Describing electronics only as something PLM later needed to accommodate leaves out the data management work already happening within electronics design, and the broader history includes several communities addressing related problems from different starting points.
There is another part of early TDM/PDM that deserves more attention, and that is collaboration. The systems I remember allowed teams to collaborate in real time, which means their role extended into active engineering work, well beyond storing completed files and retrieving old versions. That changes how we should describe the transition to PLM, because collaboration was already part of the story before the lifecycle label became popular. The useful questions are how that collaboration worked, who could participate, and how far it reached across a project or organization. Reducing early PDM to a file vault makes the later marketing story look cleaner than the history actually was. In that sense, my experience reinforces Doug’s argument about continuity while challenging its MCAD-centered framing, because early PDM did more than a narrow retrospective definition gives it credit for, and it did so in more than one industry.
More Than One Starting Point: SAP and the Retail Counterexample
Business software was developing along another path entirely, and this is where the case for multiple starting points becomes unavoidable. SAP’s early history dates its materials management system integrating purchasing, inventory management, and invoice verification to 1975. This was a different entry point into a company’s information, built on materials and transactions rather than on a CAD assembly becoming the origin of every business process. None of this means we should retroactively call every enterprise application PLM, but it does mean that a history which begins with mechanical CAD files begins in the middle.
Razorleaf’s own podcast series contains an especially useful counterexample. In Episode 134 with Brion Carroll, the discussion turns to retail and footwear, and Carroll describes adapting Windchill around styles, materials, sourcing, and costing, with different participants and different ways of representing the product. That example cuts both ways. It supports Doug’s observation that established foundations continued to be used, and it also demonstrates that those foundations could be adapted to work substantially different from mechanical CAD vaulting. Technical continuity and business expansion can happen together, which is why I would not conclude that PLM was simply a marketing invention. The label certainly gave vendors room to make larger claims, but a larger claim and an imaginary business problem are two different things.
Before the Software Categories: How a Drawing Office Actually Worked
If the standard history starts too late and too narrow, the correction is to start earlier and wider, and this is the method I am applying to the opening of my book. A proper history of engineering information management begins before the software categories, with the work itself. Consider a drawing office before CAD. A drawing had to be prepared, checked, approved, issued, interpreted, and sometimes changed. Someone had to establish which version could be used. Someone had to determine whether a change affected work already underway. People needed ways to resolve the questions the drawing could not answer by itself. The important historical question is how a particular organization did that work: which parts were written into procedures, which were recorded on documents, and which depended on a colleague knowing the product and knowing whom to ask. Software vendors did not invent those responsibilities. They developed tools that could take over parts of them, make them faster, and apply control more consistently.
That framing also keeps us from romanticizing the past, because paper could be misplaced, copies could become outdated, and finding the right person could take time when that person might be unavailable at all. Human coordination was essential, but it had limits, and understanding both sides is necessary if we want to explain what changed when design became digital. We need to know what the file replaced and what work remained around it, since a digital drawing could improve the design task while leaving the surrounding coordination dependent on familiar human effort. Doug’s own backup story illustrates the pattern well: before a vendor supplied a solution, he wrote a utility to index the tapes, and only later did a software product address part of that need. That sequence, in which the work and the workaround precede the product, is a much more useful historical pattern than a clean procession of three-letter acronyms.
Doug’s closing argument points in the same direction. He describes products and manufacturing spread across more organizations and locations, and he explicitly says that extracting a BOM and applying change control is insufficient for that world, which I read as an acknowledgment that the business requirement extends beyond the familiar PDM scope. The question is how well our tools address that requirement, and where people still have to complete the work between them. Early systems already supported collaboration, but that does not mean they covered every discipline, participant, or handoff, and those boundaries need to be examined in the context of each implementation.
Conclusion and Request
I agree with Doug – big PLM success stories are coming from traditional industries (defense, aero, auto) and MCAD vendors own top 3 PLM platform stories. At the same time, the success of products like MatrixOne, Agile PLM, Eigner, and later Aras demonstrates that the history was more nuanced than pure MCAD/PDM.
We should be much tougher on PLM marketing and much more precise about PLM history. Early TDM/PDM was already developing across mechanical design, AEC, and electronics, and collaboration was part of its value, so a history that reduces this to MCAD file storage leaves too much out before we even reach the debate about PLM. As I work on the opening chapters of the book, I want to start with the people, documents, and procedures that made engineering and manufacturing function, and then judge what CAD, PDM, and PLM actually changed.
I’d like to finish this article with the question – What did your first TDM or PDM system manage, and how did it help people collaborate? All answers will count and be collected. I would especially like to hear from those who worked in AEC, electrical design, and electronics. Which parts of that experience are missing from the usual PLM history?
Looking forward to your feedback and comments…
[UPDATE: September 9, 2026] What the discussion added
Thank you to everyone who contributed to many-comment discussion. The feedback have helped me make this history more precise.
One useful point of agreement emerged between Doug Macdonald and Brion Carroll: substantial lifecycle capabilities existed before the PLM label became established. Doug recalled item lifecycle management, workflow, BOM and change management, and MRP integration at Sherpa in 1990. Brion agreed that the broader offering preceded the name. This makes a simple progression from file vaulting to lifecycle management harder to sustain.
The discussion also widened the starting points. Bobb Omel described an internal parts, document, and ECO system at Atari. Mark Reisig, David Thomson, and Christian Barlach brought in plant assets and database-driven design. Jack Saint added manufacturing-process documentation to the story, while his exchange with Martin Eigner showed why company history and technical lineage need separate evidence.
The sharpest disagreement concerns delivery. Doug challenged the tendency to blame customers when broad promises are not achieved. Andreas Lindenthal pointed to successful implementations with established PLM systems. Those positions raise several different questions: what worked, over what scope, with how much integration effort, and how easily it could be maintained. I want to collect specific cases before drawing broad conclusions about either success or failure.
Paul Empringham and Christine Longwell also helped distinguish owning a portfolio of capabilities from making them work together. Keith Hoover, Brion, and Charles Allard Jr reminded us that Excel and email can remain part of the process after enterprise software arrives.
My conclusion is that the business needs were real and the history had several paths. We need the same precision when assessing the software: what was promised, what was delivered, and what work remained around it?
For the book, a specific example will help most: the period, system or version, business task, and one thing that worked well or remained difficult. I am keeping disputed dates and capabilities attributed while checking the supporting records.
Best, Oleg
Follow up discussion on this topic – PLM Was Real. The Question Is What It Delivered.
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
