For more than twenty years I have listened to the same PLM story, told in almost the same way, with the same slides and the same promises. After hearing it across countless conferences, demos, and customer meetings, I found something is wrong. I guess, the really turning point was ChatGPT that is capable of producing a super polished PLM pitch – no question asked. It is so polished and so fake at the same time, that it is hard not to see it.
The story that once helped people understand PLM has stopped reflecting the world that manufacturing companies actually live in. It no longer matches the pressures they face or the complexity they manage. It is a story frozen in time while everything around it has changed.
The traditional narrative still begins with the familiar set of problems. Files are scattered. Files and revisions are hard to track. Teams struggle to communicate. PLM is not connected to ERP. Mistakes slow production. There is no closed loop of information, yada, yada…
Then the punchline arrives.
A single system PLM database appears, the vendor offers a confident smile, and the PLM software system becomes the hero that solves the entire spectrum of challenges. The message is always the same. Adopt this platform, transform the way you work and order will replace chaos.
When I compare this story to conversations I’m having with industrial companies, startups and engineering teams, it sounds fake. Everyone knows the pitch and no one is really listening. Companies operate under relentless pressure to deliver products faster, at higher quality, and at lower cost. This is a regular – faster, cheaper, better (no changes).
At the same time, the complexity around them continues to intensify. Supply chains span multiple continents. Products integrate mechanical, electrical, software, and cloud components. Customer requirements shift rapidly. Regulations change. Teams are more distributed. Tools are more diverse. Processes are more intertwined.
The manufacturing world is not simplifying. It is diversifying. And as complexity rises, the idea that a single system can fix a neatly defined set of universal problems becomes less convincing every year.
This is why I think the old PLM story no longer works. It was designed 20+ years ago when combining records and files into relational databases and organizing a file vault for multi-site environment was a big deal. It was a world where companies were looking for the tech that can magically provide a “home” for their messy drawings, CAD files, and organize document workflows. That world does not exist anymore. Technology has advanced – you can get unlimited storage, you can search easily through millions of files, share images, chat with everyone in the world, get into virtual meetings and now also get an unlimited amount of cheap intelligence too.
Manufacturing organizations have evolved into highly specialized environments shaped by their own constraints, industries, business models, and cultural habits. Each company faces a different combination of challenges. Each organizes work differently. Each defines success differently.
A generic “single source of truth” database story cannot speak for all of them. It cannot even speak for most of them.
Over time I have seen the gap between the classic PLM narrative and the lived experience of engineering and operations teams grow wider. What was once a helpful simplification has become a barrier to understanding. I can see how companies are afraid of stepping into the PLM world and look for alternatives. I also see how existing PLM narratives are not resonate anymore and companies are looking for more details.
In my article today, I want to explore why that gap exists, why the traditional story has reached its limits, and how to turn this narrative upside down. What a more accurate and effective narrative must look like for companies working through modern product development challenges.
Why the Traditional PLM Story Breaks Down in Practice
The common PLM storyline assumes a universal set of challenges. In the traditional pitch, a company struggles with unmanaged data, disconnected processes, version confusion, and lack of traceability. It is portrayed as a situation that can be resolved by introducing a central platform that becomes the authoritative location for all product information. This idea sounds straightforward and even intuitive, but it overlooks the essential truth that companies are not abstract entities guided by a standardized model. They operate based on their own histories, industry pressures, organizational structures, product complexities, and talent pools.
Research and industry analysis consistently demonstrate that engineering organizations vary widely in how they think, behave, and prioritize work. Some companies organize themselves around speed and frequent iterations. Others value precision and risk mitigation above all else. Some manage long and complex supply chains, while others handle most production internally. Some rely on a single CAD environment, while many others support multiple tools and formats.
These conditions shape the problems organizations need to solve and influence how a PLM system must support them. A uniform narrative that assumes identical challenges is not capable of capturing such diversity. As a result, the standard pitch oversimplifies the situation in order to present the same product story to every customer. This is a structural weakness. When a system is positioned as a universal remedy, the nuance required for successful adoption is lost.
The outcome is predictable. PLM implementations often struggle not because the technology is inadequate but because the underlying story guiding the implementation never reflects the organization’s reality.
Reframing the Story: The Company as the Hero
A more effective PLM narrative begins with a conceptual shift. Instead of treating the system as the central figure in the story, the narrative should position the company as the hero. The system becomes a supporting element, a guide that helps the organization achieve the outcomes it seeks. This shift aligns with modern principles of system thinking, where transformation is understood as an interaction between people, processes, and technology rather than a direct substitution of old tools with new ones.
To create a meaningful PLM story, it is necessary to understand the organization’s journey. This requires answering analytical questions about purpose, friction, and aspiration. What is the company trying to accomplish? What slows it down? Where does energy and clarity disappear? What drives mistakes and inefficiency. What does success look like from both an engineering and a business perspective? How does the company measure improvement?
These questions create the foundation for a narrative that reflects real priorities. Once the organization’s story is understood, the system can be positioned in a way that supports the actual goals rather than imposing a predetermined model. This shift produces better alignment and more sustainable adoption because the story is built around the organization, not the vendor.
Understanding the Diversity of Company Stories
Industry research, customer interviews, and collective experience across the PLM ecosystem consistently show that companies operate according to highly individualized narratives. These narratives can be categorized, but not standardized. Consider several patterns observed across different sectors.
Some manufacturers focus intensely on preventing BOM mistakes. In industries where a single incorrect part can cost significant rework or jeopardize regulatory compliance, the story revolves around accuracy and governance. These companies value traceability and structured change processes.
Others struggle with supplier variability. Their challenges are driven by long lead times, unreliable forecasts, or inconsistent part availability. Their story centers on visibility and coordination more than on CAD management or document control.
Multidisciplinary engineering organizations often deal with fragmentation across mechanical, electrical, firmware, and software teams. Their story is defined by synchronization and timing, not by the issues presented in the standard PLM pitch.
In many companies, the friction lies between engineering and procurement. These organizations need alignment more than they need new file management tools. Their narrative revolves around shared data visibility and decision support.
There are also companies whose competitive advantage depends on speed. They prototype rapidly, iterate constantly, and measure success by how quickly they move from idea to physical test. Their story does not align with a narrative built around control and standardization.
These examples illustrate a central insight. Each company lives a unique story shaped by its constraints and the outcomes it values. A single PLM narrative cannot capture this diversity. As a result, generic pitches fail because they speak to an imagined average company rather than a real one.
Why Many PLM Implementations Falter
When the narrative guiding a transformation is misaligned with reality, the implementation encounters resistance, confusion, or stagnation. This is not because employees do not want to improve. It is because the project is anchored in a story that does not match the organization’s daily experience.
A generic story leads to generic goals. When goals are generic, implementation plans become vague. Expectations are not clearly defined. Architecture decisions become reactive rather than intentional. The process loses coherence and direction.
This is a common and documented pattern in PLM failure analyses. Organizations often discover late in the project that the system they are building does not address the challenges they actually face. At that point, the project becomes a negotiation between the original vision and the reality of daily work.
Successful PLM projects typically begin with a narrative that is precise, contextual, and grounded in the company’s identity. This narrative guides decisions, priorities, and scope. Without this narrative, even strong technology platforms can struggle to generate meaningful and lasting results.
What a New PLM Story Should Look Like
A new PLM story is built around a deeper and more analytical understanding of the organization. It does not begin with the system or the vendor. It begins with a structured analysis of the company’s environment, its sources of friction, and the outcomes it seeks.
A well constructed narrative identifies who the company is, how it designs and builds products, and what forces shape its decisions. It clarifies the conflict that needs to be resolved and the cost of inaction. It defines the transformation the company wants to achieve, not the transformation the vendor prefers to sell.
Once this story is established, the architecture becomes clearer. Decisions about data modeling, integration, workflows, and responsibility alignment become easier because they follow from a coherent narrative. This narrative provides structure for sequencing and prioritization. It creates a shared mental model across teams and reduces disagreement during implementation.
This approach is not about storytelling for emotional impact. It is about storytelling as a design discipline that supports strategic clarity.
Why Storytelling Has Become a Strategic Capability
As engineering and manufacturing systems become more interconnected, companies face growing complexity. AI influences decision making. Supply chains shift rapidly. Cloud systems reshape data access. Composable architectures allow flexible combinations of services rather than reliance on monolithic tools. In this environment, clarity becomes a competitive advantage.
A coherent PLM story aligns leadership and functional teams around a shared understanding of what needs to happen. It creates a common language that crosses departmental boundaries. It helps organizations select technology that supports their real needs rather than the needs assumed by vendors. It reduces implementation risk because the project is grounded in an analytical framework rather than assumptions.
Companies that invest in building their narrative early in the transformation process consistently make better decisions and experience smoother implementations. Storytelling becomes a practical tool for managing complexity rather than an abstract communication exercise.
A More Effective Approach to Changing the PLM Narrative
To change the PLM narrative, companies need to adopt a methodical approach that focuses on understanding themselves before evaluating systems. The process begins with listening to how teams describe their work, challenges, and goals. It requires translating fragmented pain points into a unified narrative that explains what is happening and why. It also involves identifying conflicts that matter, defining outcomes that support the business, and establishing a transformation pathway that reflects the company’s identity.
This practice helps organizations articulate what they truly need. Teams gain clarity before complex technology decisions are made. The result is not simply a better PLM strategy. It is a more stable foundation for long-term digital transformation.
What is my conclusion?
How to make a customer a hero? How to make a story that is not generic and build a customer specific PLM strategy to reflect that?
The reason the traditional PLM narrative persists is that it is easy to repeat. It simplifies a complex world into a single storyline. Yet companies that want to succeed in modern engineering environments need more than a familiar story. They need a story that reflects who they are and what they are trying to become.
Every organization has a distinct history, a unique set of challenges, and a particular vision of the future. A PLM strategy that ignores this individuality will struggle. A strategy built on a clear and analytical understanding of the company’s true story will be far more effective.
Organizations that want to define this story and align stakeholders around a realistic and grounded narrative can benefit from outside help.
Just thoughts…
If you want help building your story, one that reflects who you really are and what you’re truly trying to achieve, contact me. I would be glad to help.
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative and integration services between engineering tools including PDM, PLM, and ERP capabilities.
