A recent analysis about enterprise UX from Technology Evaluation Centers made a striking observation: AI agents are fundamentally reshaping enterprise software UX. The interaction model is moving from screen-first to agent-first, from navigation to intent. Users no longer start with a menu. They start with an outcome.
That observation is important for enterprise software broadly. For PLM specifically, it names something the industry has quietly known for years but rarely said out loud: the way PLM systems present themselves to users has always been a problem. Not just a usability problem. A structural one.
There is a specific kind of frustration that every engineer who has worked with PLM software knows well. You need to check something simple — an item or BOM status, a revision history, a supplier record. You open the system. You navigate a menu tree. You find the right module. You fill in a search form. You click through several screens. But it is painful and time consuming. You count clicks and burn time. I know companies that hire workers because their skilled employees refuse to use PLM tools. So, they hire cheap PLM operators that can be guided by engineers.
That experience – complex navigating software in order to do work – defined PLM user experience for three decades. The interface was the product. Learning the system was part of the job. Organizations hired administrators to help people find their way around. Certifications existed because the tools were genuinely hard to use. Entire implementation methodologies were built around training humans to adapt themselves to software.
I think that version of PLM UX is dying. Therefore, here is my question today. What is going to replace the old PLM UI and UX?
In my article I want to explore and share my thoughts about the future of PLM UX. Is it a chatbot in the corner of an existing screen, a modernized dashboard, or a conversational overlay on top of legacy workflows using AI infrastructure?
I think the change will be deeper. What PLM systems know – their product substrate, their historical memory, their relationships, their decision and change history matters more than how that information and knowledge is presented.
In an agentic world, the presentation layer becomes temporary. The knowledge layer does not. PLM UX is not disappearing. It is being rebuilt on a completely different foundation.
The “PLM Editor” Era: Why PLM UX Became So Complex
It is tempting to look back at early PLM interfaces and conclude that vendors simply made poor design choices. Complex forms. Deeply nested navigation. Workflow screens that mirrored database schemas more than actual engineering work. Role-based menus so elaborate that new users needed weeks of training before they could accomplish anything independently.
But the complexity was not accidental. It reflected real constraints.
Enterprise software interfaces were expensive to build and expensive to maintain. A single screen had to serve thousands of users across engineering, manufacturing, procurement, quality, and supply chain — each with different needs, different permissions, and different workflow expectations. Vendors had to make every workflow configurable enough to fit every organization. The result was generalization at the cost of clarity.
There was also a deeper architectural reason for the complexity that is worth naming specifically: PLM systems were built around flexible data models. Flexibility was a key and differentiator at the same time. Unlike CRM or ERP systems, which deal with relatively stable object types, PLM had to accommodate an enormous variety of product structures such as parts, assemblies, documents, specifications, configurations, manufacturing processes, supplier records, and the relationships between all of them. Every organization modeled these differently. Every industry had its own conventions. In reality it might be not true, but as a practice, customization (and later configuration) became one of the key elements of PLM.
To handle this, PLM vendors developed what became known in the industry as the “PLM Editor” – a flexible, data-model-driven UI layer that could be configured to reflect whatever schema an organization had defined underneath. The interface was not designed around how engineers thought about their work. It was generated from the data model itself. Attributes became form fields. Relationships became tabs. Lifecycle states became dropdown menus. The UI was, in a very literal sense, a projection of the database schema onto a screen.
This approach solved a real problem. It gave PLM systems the flexibility to serve wildly different industries and organizations without rebuilding the interface from scratch each time. But it also meant that every deployment looked and felt slightly different, and that the cognitive burden of operating the system fell almost entirely on the user. You had to understand the data model to navigate the interface. You had to know what the administrator had configured in order to find what you needed.
There were also legitimate reasons for rigidity beyond the data model. Product development involves auditability, traceability, revision control, regulatory compliance, and approval chains. Aerospace companies, medical device manufacturers, and automotive suppliers cannot improvise their workflows. The structure that made PLM systems difficult to use was often the same structure that made them trustworthy.
The deeper problem was not the screens themselves. It was the assumption underneath them: that the interface was the right place to encode organizational knowledge. Navigation trees became institutional memory. Workflow configurations became process documentation. Training manuals became the bridge between how the software worked and how engineering work actually happened.
This created a fragile dependency. When software changed, organizational knowledge had to be retrained. When organizations changed, workflows had to be reconfigured. The system and the work were tightly coupled in ways that seemed necessary at the time but would become increasingly difficult to sustain.
For smaller organizations, the friction was often fatal. Spreadsheets and shared folders survived alongside official PLM tools not because engineers were undisciplined, but because the cognitive overhead of operating PLM systems was simply too high relative to the immediate value they delivered.
That tension has existed in PLM for decades. AI is now forcing it into the open.
AI Changes the User Model
For thirty years, PLM systems had one type of user: a human being sitting in front of a screen, navigating the interface, filling forms, routing approvals, and searching for data. The entire UX conversation was about making that experience less painful.
AI introduces a second type of user. One that does not navigate screens at all.
AI agents are becoming operational participants in the digital thread. They monitor conditions, validate data, trigger workflows, escalate exceptions, and coordinate handoffs — not by clicking through interfaces, but by interacting directly with the product knowledge underneath them. This is a fundamental change in who, or what, PLM systems need to serve.
The Technology Evaluation Centers analysis describes this through two emerging interaction models. The first is Human-to-Agent Experience (HAX) where humans collaborate with AI agents that handle analysis, monitoring, and automation while humans retain judgment and decision authority. The second is Agent-to-Agent Experience (AAX) where agents communicate directly with other agents, exchanging context, updating records, and orchestrating workflows without human involvement at every step.
Both models are already appearing at the edges of PLM. A BOM validation agent might continuously monitor supplier data completeness. A release readiness agent could track lifecycle conditions across an assembly. A CAD file agent may organize dependencies, manage derivatives, and flag revision conflicts automatically. A manufacturing agent might verify routing completeness before ERP synchronization even begins.
This matters for UX in a way that goes beyond adding an AI assistant to an existing screen. Agents do not compensate for ambiguity the way humans do. An engineer navigating a poorly configured PLM system can draw on tribal knowledge, remember what the administrator told them during onboarding, and infer meaning from incomplete information. An agent cannot do that safely. It requires structured relationships, explicit workflows, callable actions, traceable history, and explainable logic.
In other words: everything the PLM Editor era often failed to enforce.
This is where the UX turns into architecture. If AI agents are now users of PLM systems, then the quality of the product knowledge model and not the quality of the interface, determines whether the system can be usefully operated at all. A beautiful screen on top of fragmented, poorly structured data helps a human muddle through. It does not help an agent do anything reliably.
PLM UX is no longer only about helping humans navigate software. It is increasingly about making product knowledge legible to systems that do not navigate at all.
Tool-Shaped AI vs. Colleague-Shaped AI
Not all AI interactions are the same. This is an important distinction that is easy to miss when the conversation focuses narrowly on chatbots and copilots.
Nate Jones, speaks about the future of AI interfaces, draws a useful line between two fundamentally different interaction models: tool-shaped AI and colleague-shaped AI. The difference is not about capability. It is about the nature of the work being done.
Tool-shaped AI behaves like a focused utility. The interaction is specific, transactional, and bounded. You ask for something concrete and the system delivers it. In PLM, this looks like comparing two revisions, generating a release package, validating a BOM against supplier records, producing PDF or STEP derivatives, or synchronizing records with ERP. These are well-defined operations with clear inputs and expected outputs. The AI makes them faster, smarter, and less dependent on the user knowing exactly where to click.
Colleague-shaped AI is different in kind, not just degree. The interaction becomes ongoing, contextual, and collaborative. You are not asking for a specific output. You are asking for help with a process that unfolds over time, involves multiple people and systems, and requires memory of what happened before.
In PLM, colleague-shaped interactions sound like this. Help me prepare this product for release. Watch for supplier risks across this assembly. Coordinate this engineering change across mechanical, electronics, and procurement. Tell me why this BOM failed validation last week and what has changed since. Monitor manufacturing readiness and flag me when something blocks the handoff.
This is not a tool responding to a command. This is a participant in the work.
The distinction matters especially in PLM because engineering work naturally contains both patterns simultaneously. A CAD export is tool-shaped. A product release process is colleague-shaped. A BOM comparison is tool-shaped. Managing a cross-functional engineering change over several weeks is colleague-shaped. These are not different categories of software. They are different modes of the same work, happening in the same environment, often on the same day.
Consider a collaborative BOM review. The initial comparison — pulling two revisions, highlighting differences, flagging cost or weight deltas — is tool-shaped. It is a bounded operation with a clear output. But the moment that comparison surfaces a question about a supplier substitution, involves a procurement lead who needs context from three months ago, and requires an engineering decision that will affect manufacturing routing downstream, the interaction becomes colleague-shaped. The work did not change categories. It crossed a threshold. The same BOM review that started as a tool interaction became a coordination problem requiring memory, context, history, and judgment. A PLM system that can only do the first part will leave the second part — the harder, more consequential part — to email threads, spreadsheets, and institutional memory that lives only in people’s heads.
Future PLM systems will need to handle both interaction models fluidly. The mistake would be to optimize for one and neglect the other. A system that excels at tool-shaped AI but has no memory, no context, and no ability to track work over time will feel powerful for isolated tasks and frustrating for anything that spans a lifecycle. A system that is deeply contextual and memory-rich but cannot execute precise, reliable operations quickly will feel intelligent but slow.
The most important insight here is temporal. Engineering work is tool-shaped at the moment of execution, but colleague-shaped across the lifecycle. The future PLM interface will need to know which mode is required and shift accordingly.
From Static Screens to Generative UI
There is a third shift happening alongside the agent model and the tool-versus-colleague distinction. It is less obvious but equally important. The interface itself is becoming temporary.
For the entire PLM Editor era, interfaces were treated as long-lived assets. Vendors invested heavily in designing screens that would serve organizations for years. Administrators spent weeks configuring forms, layouts, and workflow panels. Users built spatial memory around where things lived. The interface was stable by design, because stability was expensive to replace and organizations depended on it.
AI changes this assumption at its root.
If the system understands intent — what the user is trying to accomplish, in what context, with what product — then the interface does not need to be fixed in advance. It can be generated around the work. A purpose-built experience for the specific task being performed, assembled from product context, user role, lifecycle state, and the history of decisions made before.
A writer on generative UI put it plainly: not all requests are the same, and compelling products route users to different experiences based on intent. Handle the common requests with specific, focused flows. Route the complex or ambiguous ones to more flexible agent workflows. That insight translates directly into PLM.
Imagine an engineer asking: “Check if this BOM is ready for release.” The system does not open the standard item page. It generates a release readiness workspace — a checklist of unresolved issues, lifecycle conflicts, missing approvals, supplier gaps, impacted assemblies, risk indicators, and recommended next actions. Everything relevant to that specific question, assembled around that specific product, at that specific moment.
Or: “Explain what changed between these two revisions.” The system generates a comparison workspace — visual differences, cost and weight deltas, supplier substitutions, impacted assemblies, linked engineering changes, approval history, and manufacturing consequences. Not a generic diff tool. A contextual view shaped by what this product is, who is asking, and what decisions preceded this moment.
Or: “Prepare the manufacturing handoff.” The system generates a handoff workspace — MBOM mapping, routing validation, ERP synchronization preview, missing manufacturing data, operation assignments, procurement gaps. A temporary surface built entirely around completing this specific transition.
None of these is a fixed PLM screen. Each is a generated workspace shaped around intent.
This is the concept some are beginning to call disposable pixels. The interface becomes temporary while the product context beneath it remains persistent. Traditional PLM systems assumed the interface was stable and work adapted to it. AI-native systems reverse that relationship. The work becomes primary. The interface becomes a momentary projection of product context, intent, and the decisions that led here.
The interface is no longer the system. It is a surface the system produces when needed and discards when the work moves on.
The Three-Layer Architecture of Future PLM
If the interface is becoming temporary, what becomes permanent? That question leads to the most important architectural idea in this entire discussion.
The future PLM stack is not flat. It is not a single system with a better UI on top. It is three distinct layers, each with a different role, a different lifespan, and a different relationship to the work being done.
The first layer is the product substrate. Traditionally PLM architects called it data model or flexible data model. I wrote about it in many articles and highlighted the importance of robust graph based data models in the future PLM. This is the stable foundation: BOMs, revisions, files, relationships, permissions, workflows, lifecycle states, traceability, and change history. This layer has always existed in PLM systems. What changes in an AI-native world is its strategic importance. The product substrate is what agents actually rely on. It is the raw material that makes everything above it possible. A substrate full of clean relationships, explicit schemas, and traceable decisions can support agents, generate contextual interfaces, and sustain memory over time. A substrate full of disconnected records, implicit conventions, and workflow logic buried inside UI click paths cannot.
The future moat of PLM systems may not be their screens. It may be the quality of their product substrate.
The second layer is product memory and agentic intelligence (I first wrote about it in 2025 when analyzing context graphs and knowledge graphs). This is where the strategic value accumulates over time. Product memory is not simply a log of what happened. It is the accumulated context of how and why work was done — engineering decisions, supplier negotiations, change rationales, unresolved questions, ownership, dependencies, and the reasoning behind every revision. It is what allows an agent to answer not just “what is the current state of this BOM” but “why does this BOM look the way it does, and what would change if we substituted this component.”
This layer is also where agents coordinate. Monitoring agents watch conditions. Orchestration agents route work. Validation agents check completeness. Specialist agents handle specific domains — supplier intelligence, manufacturing readiness, regulatory compliance. Without a strong product memory layer, these agents operate in isolation, handling discrete tasks but unable to participate meaningfully in the broader lifecycle.
This is also where colleague-shaped AI becomes most powerful. When product memory is rich — when the system knows not just the current BOM but the supplier conversation that led to a component choice, the engineering change that preceded the last revision, the procurement concern that was raised and resolved two quarters ago — an AI colleague can participate in work that spans time, teams, and systems. A release review is no longer a snapshot audit. It becomes a conversation grounded in everything the product has been through. A cross-functional BOM review stops being a coordination challenge and becomes a structured collaboration where the AI brings context that no single participant could hold in their head. A supplier substitution decision stops being an isolated judgment call and becomes an informed analysis of precedent, risk, and downstream consequence.
This is the opportunity that most current PLM discussions understate. The conversation tends to focus on automation — agents doing tasks faster. The more transformative possibility is augmentation — agents making collaborative work smarter, more informed, and less dependent on institutional memory that walks out the door when people leave.
This is the layer that most current PLM systems are missing entirely. The product substrate exists, in varying degrees of quality. The generated UI layer is beginning to emerge. But the memory and intelligence layer — the connective tissue between structured data and useful action — remains largely unbuilt.
The third layer is the generated UX. This is the disposable pixels layer: dashboards, review workspaces, task panels, approval surfaces, conversational overlays, mobile micro-experiences. These interfaces are assembled on demand, shaped by intent and context, and discarded when the work moves on. They draw from the substrate. They are informed by memory. They are temporary by design.
The relationship between these three layers is what matters most. A strong substrate without memory produces a well-organized archive that agents can query but cannot reason about. Memory without a clean substrate produces confident hallucination — agents that sound authoritative but operate on incomplete or inconsistent foundations. Generated UX without either produces beautiful interfaces that cannot be trusted.
In AI-native PLM, pixels become disposable. Product memory does not.
AI Will Expose Weak PLM Architectures
There is a version of the AI-in-PLM story that is almost entirely optimistic. Agents automate the tedious work. Interfaces become smarter. Engineers spend less time navigating software and more time doing engineering. Product knowledge accumulates rather than evaporates. Collaboration improves. Release cycles shorten.
That version is possible. But it depends entirely on what is underneath.
The most immediate temptation for PLM vendors and implementers is an obvious one: take an existing system with an established data model, a large installed base, and years of workflow configuration, and layer AI on top of it. Andreas Lindenthal offers it in his PLMgpt. The idea is interesting and it reflects an immediate possibility to apply it to existing customers. Add a conversational interface. Connect a large language model to the existing API. Surface an AI assistant inside the existing UI. Ship it as a new release. This is the path of least resistance, and it is genuinely attractive. The substrate already exists. The customer relationships already exist. The integration work is already done.
But this approach carries specific risks that are worth naming directly.
The first is context collapse. Most legacy PLM systems were not designed to expose the reasoning behind their data — only the data itself. An AI layer built on top of such a system can tell an agent what the current revision is, but not why it was created. It can report that a BOM was approved, but not what concerns were raised and resolved during the review. It can show that a supplier was substituted, but not the engineering rationale behind the decision. When an agent operates without that context, it produces answers that are technically correct and practically misleading. An engineer asking “is this product ready for release” gets a checklist response that passes every field validation but misses the unresolved supplier risk that three people discussed in an email thread six weeks ago. The AI is not wrong. It just does not know what the system never captured.
The second is workflow hallucination. Legacy PLM systems frequently encode business logic inside UI configurations — form behaviors, conditional field visibility, approval routing rules, lifecycle transition guards — that were never exposed as callable, inspectable logic. They exist as screen behavior, not as documented rules. When an AI layer attempts to orchestrate workflows on top of such a system, it encounters a gap between what the API exposes and what the system actually does. The agent may believe a workflow step is complete because the API returned a success status, while the actual business rule — visible only to a human navigating the screen — was never triggered. The result is workflows that appear to execute correctly and produce incorrect outcomes. These failures are particularly dangerous because they are hard to detect and easy to attribute to other causes.
The third is trust erosion at the moment of adoption. AI-native UX promises engineers that they can express intent and trust the system to act correctly. That promise depends on the system being reliable. When an AI layer built on a weak substrate produces confidently wrong answers — a release package with missing approvals, a BOM validation that passed fields but missed relationships, a supplier recommendation that ignored an existing qualification issue — the damage to trust is disproportionate. Engineers who were skeptical of PLM systems before will not give AI a second chance easily. The window for earning that trust is narrow, and a poorly architected AI layer can close it permanently.
AI does not fix broken architecture. It amplifies it and in enterprise software, where decisions have downstream consequences across manufacturing, procurement, and supply chain, the amplification is rarely symmetric. The failures are louder than the successes.
This reframes what PLM implementation means going forward. In the PLM Editor era, implementation was largely a UX and workflow configuration project. In an AI-native context, it becomes a knowledge architecture project first. The questions that matter are different: Are your schemas clean enough for agents to reason about? Are your workflows callable or only navigable? Does your system accumulate memory or only record state? Can an agent explain why a decision was made, or only report what the current value is?
AI is arriving whether or not those questions have been answered. The organizations that have invested in substrate quality will find it accelerating their capabilities. The ones that have not will find AI the most honest audit their PLM architecture has ever had.
From Workflows of Screens to Systems of Work
There is a phrase that has quietly shaped enterprise software design for decades: the system of record. The idea was that important business data should live in one authoritative place, and that people who needed it would go there to find it. PLM was built around this idea. The system was the destination. Work happened inside it.
AI is dismantling that assumption in a very practical way.
Engineering work has never actually been contained inside a single system. It happens in CAD tools, in spreadsheets, in email threads, in supplier conversations, in manufacturing floor discussions, in Teams channels, in shared drives, and occasionally — when required — inside the official PLM interface. PLM systems captured the formal artifacts of that work: the approved revision, the signed-off BOM, the completed change order. But the work itself, the reasoning, the negotiation, the iteration, happened everywhere else.
AI agents change the economics of that gap. Instead of requiring engineers to bring their work into the PLM system, agents can go where the work is. A CAD-side agent monitors file dependencies and flags revision conflicts without the engineer opening a separate application. A Teams-based agent attaches supplier conversations to the relevant product record automatically. A mobile approval surface generates the right context for a sign-off decision without requiring the approver to navigate the full PLM interface. A manufacturing agent validates routing completeness inside the ERP environment rather than waiting for a human to reconcile two systems manually.
The PLM system becomes less of a giant destination and more of a distributed operational substrate. Its value is no longer primarily expressed through its own interface. It is expressed through the quality of the product knowledge it holds and the accessibility of that knowledge to agents operating across the broader technology environment.
This shift has significant implications for how engineering organizations think about where work happens and where knowledge lives. In the screen-centric model, knowledge lived in the system because that was where work was done. In the work-centric model, knowledge needs to follow the work — capturing context from wherever decisions are made, attaching memory to product records regardless of which tool the engineer was using when the decision happened.
This is harder than it sounds. It requires PLM systems to become genuinely open — not just in the sense of having APIs, but in the sense of being able to receive context from external environments, not only export data to them. A PLM system that can push a BOM to ERP but cannot receive a supplier decision from a Teams conversation is still operating in the screen-centric model, regardless of how modern its interface looks.
The organizations that will navigate this transition most successfully are probably not the ones asking “how do we get engineers to use PLM more.” They are the ones asking “how do we make product knowledge capture happen naturally, wherever engineering work actually occurs.” That is a fundamentally different question. It leads to different architecture decisions, different integration priorities, and a different relationship between the PLM system and the people who depend on it.
Enterprise software is moving from designing for the system to designing for the moment. In PLM, that means following the work rather than waiting for the work to arrive.
What Remains Stable
It would be easy to read everything in this article as an argument that traditional PLM interfaces are simply going away — that screens, dashboards, and structured workflows will be replaced entirely by conversational agents, generated workspaces, and distributed knowledge capture. That conclusion would be wrong, and it is worth being specific about why.
Some things in PLM are stable by necessity, not by inertia.
Regulated industries do not have the option of making their workflows ephemeral. An aerospace company preparing a design review, a medical device manufacturer managing a product change, a defense contractor releasing a configuration — these processes require reproducibility, auditability, and shared operational views that are consistent across reviewers, auditors, and time. A generated workspace that looks different every time it is opened is not acceptable in environments where the interface itself is part of the compliance record.
Experienced engineers also build genuine value around stable interfaces. This is not resistance to change. It is spatial memory and pattern recognition accumulated over years of practice. An engineer who has reviewed hundreds of change orders in the same interface has developed intuitions about what looks right and what looks wrong that are difficult to replicate in a dynamically generated environment. That expertise is worth preserving, not discarding.
There is also a subtler point about collaboration. When multiple people need to look at the same thing together — a cross-functional design review, a supplier qualification meeting, a manufacturing readiness gate — a shared, stable view matters. Generated interfaces optimized for individual intent may fragment the shared context that makes group decision-making coherent.
The more realistic future is not a binary choice between fixed screens and fully generative systems. It is a hybrid architecture: stable operational shells that provide consistency, auditability, and shared context, with generative experiences assembled inside them for the work that benefits from adaptability.
Think of it as the difference between the structure of a building and the furniture inside it. The load-bearing walls do not move. The rooms are defined and consistent. But within those rooms, the arrangement can change based on what the space needs to accommodate. Future PLM systems will likely work similarly. The governance layer — lifecycle states, approval chains, compliance workflows, audit trails — remains fixed and traceable. The experience layer — how information is surfaced, what context is assembled, how work is presented — becomes adaptive.
This distinction also protects against one of the more serious risks of AI-native enterprise software: the erosion of accountability. When interfaces are generated dynamically and agents act autonomously, it becomes easy to lose clarity about who decided what, when, and on what basis. Stable governance structures are not obstacles to AI-native PLM. They are the framework that makes AI-native PLM trustworthy enough to use in consequential decisions.
The goal is not to replace structure with fluidity. It is to make structure intelligent enough that the experience of working within it no longer requires navigating complexity that should never have been visible to users in the first place.
The Future of PLM UX Is Not About Screens
For three decades, the PLM industry measured user experience progress in screens. Cleaner forms. Better navigation. Modern web interfaces replacing thick clients. Mobile access. Low-code configuration. Each generation of improvement made the system somewhat easier to operate, without fundamentally changing what operating the system required of the people using it.
That measuring stick is no longer sufficient.
The shifts described in this article — from screen-centric to intent-centric interaction, from fixed interfaces to generated workspaces, from human-only users to agents as operational participants, from systems of record to systems of work — are not incremental improvements to PLM UX. They are a change in what PLM UX means.
In the PLM Editor era, user experience was a presentation problem. How do you surface a complex, flexible data model in a way that humans can navigate without too much friction? The answers were dashboards, workflow inboxes, role-based menus, and training programs. They were reasonable answers to a real problem. They were just never enough.
In the AI-native era, user experience becomes a knowledge problem. How do you build a product knowledge foundation rich enough that agents can reason about it, interfaces can be generated from it, and collaborative work can be augmented by it? The answers are substrate quality, product memory, agent addressability, explainability, and trust. These are not UX features in the traditional sense. They are architectural commitments.
The organizations and vendors that understand this distinction earliest will have a significant advantage. Not because they will build better screens — though they might — but because they will build systems whose value compounds over time. Every decision captured becomes context for the next decision. Every agent interaction that goes well builds the trust that makes the next one possible. Every workflow that runs without requiring a human to navigate complexity creates space for humans to do the work that actually requires judgment.
That is the real promise of AI-native PLM UX. Not the elimination of human involvement, but the elevation of it. Engineers who spend less time navigating software spend more time engineering. Procurement teams with access to product memory make better supplier decisions. Manufacturing organizations with agents monitoring readiness catch problems before they become delays.
The interface was never the point. The work was always the point.
For decades, PLM systems asked humans to understand the software. The next generation of PLM will increasingly require the software to understand the work: the product, the context, the decisions, and the people behind them.
PLM UX is dead. Long live PLM UX.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a collaborative digital thread platform that helps engineering and manufacturing teams work with connected, structured product data, increasingly augmented by AI-powered automation and insights.
