Doug Macdonald published a report in July 2026 called “The Future of Product Lifecycle Management: After 40 Years, Where Are We And What’s Next?” It argues that legacy PLM has failed, proposes a successor category called the Future Platform for Hardware Engineering, and evaluates eight emerging vendors against that model.
I appreciate Doug’s dedication to the problem and his experience. Being a frequent commentator of my posts and ideas, I think Doug always brings an interesting perspective. He is a persistent critic of MCAD based PLM explaining that PLM vendors are gaslighting customers and protecting their MCAD assets.
Therefore I was super interested to learn more about Doug’s strategy and vision.
I read the report twice. The first time I marked the places where I disagreed. The second time I noticed something more interesting than disagreement: nearly every promise the report identifies as a PLM failure reappears later in the report as a requirement for its successor. Not a variation on it. The same promise, sometimes in the same words.
That is what I want to write about, because it explains something about how this industry keeps producing the same vision under new names.
The diagnosis is accurate and the industry has been too polite about it
Let me start from the problem, because I think this is a place where Doug is absolutely right.
The section describing a normal day in a product development office is the strongest writing in the report. Engineers work heads down in whatever tool supports their discipline. When they need to coordinate across disciplines, they export a PDF, take a screenshot, build a spreadsheet, and attach it to an email. When designs are released to manufacturing planning and procurement, the same thing happens again. The report observes that this has hardly changed in decades.
That is true. It is true in companies that have a simple SolidIWorks PDM and the same for accounts that have spent tens of millions of dollars on PLM. It is true in companies whose vendors would describe them as reference accounts. Anyone who has spent time in engineering organizations recognizes the scene immediately, and the report deserves credit for describing it without softening it. In other words – every company uses Excels, PDFs, Emails, and Slack/Teams at a certain point.
The report is also right that AI does not fix this by being aimed at a pile of documents. I wrote about exactly the same thing arguing that – Bigger AI Context Windows Will Not Fix Your BOM. Agents need structured context – items, relationships, provenance, configuration, and access control before they can do anything beyond summarizing. That observation is correct and underweighted in most of what gets written about AI in engineering.
So the diagnosis holds. The prescription is where the trouble starts.
The report calls the rename a marketing exercise and then performs it
Appendix 1 narrates the history that produced the current market. It describes Gartner and CIMdata rebranding PDM as PLM in the early 2000s, and characterizes it as a new name promising greater scope while the underlying technology stayed the same. That rename is presented as one of the industry’s foundational deceptions.
Then the report argues for FPHE. The reasoning offered is that a familiar term produces a fixed response, while a new term makes people curious and willing to learn. The section concludes that the term itself matters less than the fact that there is one.
I want to be precise about what is happening here. The report is not accidentally repeating the PDM to PLM rename. It is recommending it, with the marketing rationale stated openly, a few pages after presenting that same maneuver as evidence of bad faith.
The report discredits the benefit claims and then instructs the new vendors to reuse them
Early in the report there is a list of things PLM vendors have told customers over the years, presented as claims that did not hold up. Here is a quote:
If you work with PLM, you’ve probably been told many things in the past and continue to hear them to this day. Here are some of the main ones: PLM gathers all product information using digital threads into a “single source of truth” PLM connects all users of product information, allowing them to collaborate PLM eliminates the need for spreadsheets, Slack, and email PLM plus AI will reduce time to market, improve sustainability, accelerate innovation, reduce costs, etc.
The list closes with a short line: if only it were all true.
The benefits section of the report claims improved time to market, increased margins, improved customer satisfaction, and increased revenue without adding headcount. That is the same list.
And the report says so. In its recommendations to the emerging vendors, it observes that the bigger benefits previously claimed by legacy PLM are arguably still valid and suggests the new companies use them as a guide for their own claims. The vocabulary discredited on page 6 is issued as guidance on page 22.
The email elimination promise is a falsehood in one chapter and a qualifying test in another
The same early list includes the claim that PLM eliminates the need for spreadsheets, Slack, and email.
A few pages later, defining what the successor platform must do, the report proposes a critical test for user communications: do we still need Slack, email, and spreadsheets to communicate between users? The following page states that all user interactions go through the platform, with no more email or Slack messages, and no more Excel, PDF, or STEP files.
Two other items from that list return the same way. Single source of truth is listed as a claim that did not hold up, and later appears as an approving description of one of the selected vendors. Digital thread is set aside as a term with no firm definition, and two of the eight companies are then described as digital thread platforms in a way that reads as a credential.
The monolith objection is dismissed rather than answered
The report attributes PLM’s failure throughout to a system that tried to be everything and could not be deployed. When the objection is raised that the proposed platform is another monolith, the response is that this seems more emotional than technical, since most large businesses already tolerate a monolith in ERP.
That does not engage the argument. The objection is not that monoliths are distasteful. It is that a single system claiming full coverage of every discipline and every lifecycle stage accumulates configuration surface faster than customers can absorb it, and that this accumulation is the specific mechanism by which the promised experience failed to arrive. Pointing at ERP does not address it. It concedes it and asks for tolerance.
The centralized ontology is the deepest repetition, and the one that deserves technical attention
Of everything in the report, this is the claim I would want engineers to examine most carefully, because it is presented as the architectural advance and it is the oldest idea in the document.
The first capability requires a structured ontology that normalizes entities, attributes, relationships, and operational semantics across systems, with information items and key attributes replicated inside the platform and synchronized with the source. Several of the vendor summaries in the appendix are credited specifically for using a standard ontology.
That is a unified data model. The data model is one of the oldest debates in PDM and PLM. I wrote about it many times including the evolution data models in PLM. Vendors have attempted this idea repeatedly for thirty years. STEP and ISO 10303, the PDM Enablers work, PLM Services, PLM platforms and then, inside nearly every large implementation, a multi year enterprise data model program intended to normalize what a part is, what a document is, and what a change means across the whole company.
These attempts did not fail because the people doing them were unserious. They failed because engineering semantics are organizational, not universal. Two companies in the same industry will disagree about when a part is released, what effectivity means, whether a phantom assembly is an item, how a change order relates to a revision, what approved signifies and who is allowed to say it. That disagreement is not sloppiness to be normalized away. It is their process, and often it is their competitive method. Therefore flexibility was one important conclusion of the attempts to bring something called “standard ontology”.
So a central ontology faces a fork with no good branch. Keep it generic enough to cover everyone, and it loses exactly the semantics an agent or a workflow needs in order to act on anything. Extend it per customer, and you have reinvented data model configuration, which triggers customization, which is the single largest driver of PLM implementation cost and the reason deployments run for years.
That is the mechanism that made PLM heavy. The report opens by describing the consequences of that weight, in an office where people fall back on spreadsheets because the system was too rigid or too slow to change, and then places the cause of that weight at the center of the successor architecture and calls it the differentiator.
Legacy PLM is not MCAD only, and the way it actually expanded is a better criticism
This is an objection of a different kind from the ones above. It is not a repetition. It is a factual claim that runs through the entire report and does not survive contact with the last fifteen years of this market.
The report states that legacy PLM systems are limited to managing MCAD data, mechanical part BOMs, and design phase change processes. It says the Big 3 have taken no steps to address the coverage gap, with MCAD still the focal point, and that they have largely focused on rebranding, rehosting, and re-monetizing.
The claim faces a rich list of companies and techs PLM vendors actually bought. Siemens acquired Mentor Graphics, an electronic design automation company, and separately acquired Polarion for application lifecycle management and requirements, LMS for simulation and test, and Supplyframe for supply chain intelligence. Dassault Systemes acquired Medidata, a clinical trial data platform with no mechanical design in it anywhere, and acquired No Magic, whose MagicDraw and Cameo products are among the most widely used MBSE toolsets in the industry. PTC acquired ALM through MKS and later Codebeamer, field service through ServiceMax, and cloud BOM centric PLM through Arena Solutions. This is just a short list.
Whatever else that is, it is not rebranding, and it is not a moat around a mechanical CAD business. Dassault owning the one of the leading commercial SysML toolsets is worth thinking about for a moment, given that two of the eight companies the report celebrates are positioned primarily on systems engineering.
So the factual claim is wrong. But there is a real criticism underneath it, and it is more damaging than the one the report makes.
These portfolios were assembled through acquisition, and acquired capability as a separate company: a separate data model, a separate deployment, a separate license, a separate implementation project, a separate consulting practice. Customers therefore experience breadth as a price list rather than as an environment. The capability exists, it can be demonstrated, and it can be bought. What cannot be bought is the coherence between the pieces, and coherence is the thing the customer actually wanted.
That is the accurate version of the problem. The vendors are not withholding scope. They are selling a scope that does not compose together and sometimes requires an additional effort. But that is not the main problem. The reality is that to standardize the toolset to a single vendor is a hard problem that companies have difficulties to do and actually they object to.
And here is where it connects back to the ontology, which is why this matters beyond fairness to incumbents. Every one of these vendors has spent years trying to unify semantics across its own acquisitions, with full control of the source code, full access to the roadmaps, unlimited engineering budget, and total commercial authority over every product involved. None has fully succeeded. Teamcenter, Mentor, and Polarion do not share one data model – those are separate tools integrated together. Neither do Windchill, Codebeamer, and Arena.
If a single vendor with absolute control have hard time to normalize entities, attributes, relationships, and operational semantics across five products it owns outright, the proposition that a third party will do it across seventy external systems it does not own, cannot modify, and does not control the release schedule of deserves considerably more scrutiny than a checkmark in a capability table.
The eight companies are doing real work, and the framing does not serve them
I want to separate the vendors from the report that grouped them, because I know several of these companies and I think the framing does them a disservice.
Cognyx is building BOMs from information scattered across ERP and PLM. Dalus is doing serious work on SysML v2 as a collaborative environment. EXP Software and Makersite are building graph based layers that make digital twins and lifecycle analytics practical, Makersite with unusually deep materials and supply chain data. Flow Engineering holds an entire program as one connected model, which is a genuinely useful idea. Intercax has been federating across modeling and simulation tools since 2007, long before this was fashionable. SPREAD connects across Teamcenter, Windchill, 3DX, and SAP and reasons about change impact on top of them with special focus on the aftermarket. Violet Labs has built an impressive breadth of integrations, more than seventy by the report’s own count.
Now read that list again and notice what it has in common. The reality check and acceptance that companies are using multiple systems. Every one of these products reads from, connects to, synchronizes with, or federates across the systems the report tells customers to leave behind. The report’s own appendix confirms it company by company: pulls data from CAD, PLM, MES and ERP; source data stays connected; connected data is federated; connects to CAD, ERP and PLM to import BOM; integrations to over seventy tools including PDM, PLM and ERP.
I didn’t find any evidence that those companies are attempting to replace legacy PLM or ERP vendors. They are building a complementary layer on top of it, and that is a legitimate, valuable, and honest market position. From my perspective it is only realistic GTM motion in the market. It is also the position their architecture actually supports.
The report notices this, treats it as a transitional weakness, and suggests they may need to become fully independent of legacy PLM later in order to give customers a reason to migrate fully. I think that gets it backwards. Their dependence on systems of record is not a phase to grow out of. It is what they are for. Recasting a complementary layer as a replacement category sets them up to be judged against a promise none of them made, and the report’s own capability tables show what that costs: item management appears in two of eight, data transfer workflows in three, user communications in three. Those are not failures. They are simply the wrong questions to ask a company that was never trying to be the system of record.
Scope was never the problem, which is why widening it cannot be the answer
Strip the report to its core and the differentiator claimed for the new category is scope. All disciplines, all lifecycle stages, all systems, all users. The seven underlying capabilities beneath that are information access, item management, typed relationships, data transfer workflows, user communications, applications, and openness to AI, which is (except for AI) a description of PDM and PLM as vendors have documented them for more than twenty years.
That is why the repetitions keep happening. If your architectural thesis has wider coverage, you will end up making the coverage promises, and the coverage promises are the ones that failed. The recursion is not carelessness. It is what the thesis forces.
Scope expansion is what PLM has been doing since the term was coined. Requirements, systems engineering, manufacturing planning, quality, service, sustainability, and supplier collaboration were absorbed one after another, each addition justified the same way. The result is the deployment weight that sends engineers back to email. Covering everything again, correctly this time, is not a conclusion drawn from that history.
A test that can embarrass everyone
The email elimination test is appealing and it measures the wrong thing.
Email, spreadsheets, PDF, and STEP files persist because they cross organizational boundaries, work with suppliers running different systems, degrade gracefully, and require no license. A platform whose value depends on their disappearance has set a precondition it does not control.
The problem was never that these artifacts exist. It is that everything around them evaporates and the knowledge is lost without the wider context. A supplier emails a deviation request, an engineer approves it in a thread, someone edits a quantity in a spreadsheet, and eighteen months later the part is wrong and nobody can reconstruct why. The file exists, but the context and the meaning did not.
So here is the test I would use instead. Take any item in your product structure and ask whether you can determine what it is, where it came from, which configuration and revision it belongs to, what it depends on, customers use it, suppliers supplied it, who changed it, when, why, what was considered and rejected, and whether the answer is still up to date.
That test does not care whether the PLM vendor is old or new, whether the architecture federates or consolidates, or whether the data lives in one database or multiple data stores. It applies identically to Teamcenter, to Windchill, to every company on the report’s list, and to a spreadsheet on a shared drive. Most of the time the answer is no, and it is no for the same reason everywhere. A test worth using has to be capable of embarrassing everyone.
What that test measures is product memory
Systems of record capture what the product is. They are good at it. The problem is that the reality is many SORs. This is a reality all engineering and manufacturing lives in. But what was sold for a long time as a single source of truth doesn’t exists. What almost nothing captures is how all these things are connected and why the product came to be that way.
The data from system of records is important. But then there is the next layer. The rationale behind a decision, the alternative rejected and why, the tradeoff accepted under schedule pressure, the supplier conversation that moved a tolerance, the reason a part was superseded: none of this is transactional data, and none of it survives in the systems we have built. It lives in Excels, files, threads, in meetings, and in the heads of people who eventually leave.
This is what I have been calling product memory, and it is the next step in the evolution of PLM systems (and not the same thing as digital thread). Digital thread connects formal records to each other. It establishes that this requirement links to that part and that test. It does not tell you why the part is what it is. Connection is not memory.
It also points at a different answer to the ontology problem. Meaning does not have to be normalized at the center to be usable – a universal single ontology is probably a dream. The technology to build a modern graph based data model and context layer is real. Context can travel with the information: local models that stay local, typed relationships that carry their own semantics, provenance that says where a value came from and what it meant there, and translation at the boundary instead of a single schema everyone must agree to first. Graph based models can make data portable. While that is a harder engineering problem than a standard ontology, it is also the only version that survives contact with two companies who define a released part differently and are both right.
And it is the specific gap that matters for AI. An agent limited to connected records will restate what is already stored, which is precisely the criticism the report levels at PLM plus AI. An agent that can see decision history, rationale, and the shape of past change can evaluate impact, detect inconsistency, and explain itself. The constraint is not model capability. It is that the context was never captured by anything.
What is my conclusion?
The name will not decide this. PDM, PLM, FPHE… The report closes by recommending that the eight vendors form an alliance to promote the category, and that press, analysts, and event organizers cover it.
I understand the desire to be bigger. Small companies with real technology struggle to be heard, and shared vocabulary lowers the cost of explaining yourself. But categories are not established by alliances and coverage. They are established when enough customers independently describe the same problem and then discover that a class of products solves it. ERP became a category because finance and operations leaders kept describing the same failure. The name followed the demand.
Doug Macdonald is right that the status quo is not acceptable, right that product complexity outgrew the systems built to manage it, and right that AI needs governed context rather than document piles. Those points deserve the attention this report will get them.
Where I part company is the conclusion, and not because the criticism of MCAD PLM is too harsh. It is because the proposed successor is built from the same materials. A new name, a wider scope, a central data model, and the same benefit claims are what the industry produced last time, and they produced the office the report opens with.
The gap between what engineering organizations need and what they have is not a gap in coverage. It is a gap in memory. Until product context survives across disciplines, systems, companies, and time, we will keep building platforms that describe the product accurately and cannot tell us how it came to be that way.
That is the unfinished work behind the original PLM vision, and it is still the opportunity in front of us.
Just my thoughts…
Best, Oleg
FAQ
What is FPHE?
FPHE stands for Future Platform for Hardware Engineering, a category proposed in a July 2026 report by Doug Macdonald as a successor to what the report calls legacy PLM. It defines seven underlying capabilities: full product and lifecycle information access, item management, relationships between managed items, data transfer workflows, user communications, user applications, and openness to AI.
Which vendors does the FPHE report identify?
The report names eight companies as FPHE Visionaries: Cognyx, Dalus, EXP Software, Flow Engineering, Intercax, Makersite, SPREAD, and Violet Labs. It concludes that Violet Labs comes closest to the proposed model.
Is legacy PLM really limited to MCAD?
The report argues that PLM systems manage mechanical CAD data, mechanical part BOMs, and design phase change processes, covering ten to fifteen percent of the product and lifecycle. Major PLM vendors document considerably broader capability including multi domain BOMs, requirements, systems engineering, manufacturing planning, and service. The more defensible criticism is not that these capabilities are absent, but that architecture, implementation complexity, and commercial packaging often prevent customers from experiencing them as a coherent environment.
What is the difference between digital thread and product memory?
Digital thread connects formal records to one another, establishing traceable links between requirements, parts, tests, and manufacturing data. Product memory refers to the layer that preserves reasoning, rationale, alternatives considered, and decision history. Digital thread tells you that two records are related. Product memory tells you why the product is the way it is.
Why does AI need product memory?
An AI agent limited to connected records can retrieve and restate what is already stored. Impact evaluation, inconsistency detection, and explainable recommendation all require decision history, rationale, and the shape of past change, none of which is captured by transactional systems.
Is legacy PLM really limited to MCAD?
No. Siemens acquired Mentor Graphics for electronic design automation, plus Polarion for ALM and requirements and LMS for simulation and test. Dassault Systemes acquired Medidata in clinical trial data and No Magic, whose MagicDraw and Cameo products are on the leading MBSE toolsets. PTC acquired MKS and Codebeamer for ALM, ServiceMax for field service, and Arena for cloud BOM centric PLM. The accurate criticism is not that scope is missing. It is that scope assembled through acquisition arrives as separate data models, licenses, and implementation projects, so customers experience breadth as a price list rather than as a coherent environment.
Why do central ontologies fail in engineering software?
A central ontology normalizes entities, attributes, and semantics across systems. Engineering semantics are organizational rather than universal: companies disagree about when a part is released, what effectivity means, how a change order relates to a revision, and what approval signifies. A generic ontology loses the meaning needed to act. A per customer ontology becomes data model configuration, which drives customization and implementation cost. This is the pattern behind all standard initiatives and enterprise data model programs inside large PLM deployments.
Are the FPHE vendors replacing PLM?
Based on the report’s own capability appendix, none of the eight is architecturally positioned to replace a system of record. Each reads from, connects to, synchronizes with, or federates across existing CAD, PLM, ERP, and MES systems. They are building a complementary layer above systems of record, which is a legitimate market position distinct from replacement.
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native collaborative digital thread platform connecting engineers and manufacturing teams. My opinion can be unintentionally biased.
