My PLM Journey From Testing to Architecting
How a simple test automation project in 2011 slowly shaped my entire career and eventually took me from India to Canada.
Where It All Started
My PLM story starts in 2011, just after I completed my engineering degree. I joined Mahindra Satyam in India as a fresher with a typical mix of excitement, curiosity, and a little bit of nervous energy. Like many of us early in our careers, I was eager to prove myself but still figuring out what I really wanted to do.
I was trained as a Java developer and was soon assigned to a project for a large high tech customer. The role given to me looked simple on paper. Take existing manual test scripts and convert them into automation using Selenium. In reality, it was my first real introduction to how large enterprise systems behave and how business processes are implemented through software.
Those first few months were all about learning the basics. I spent time understanding test frameworks, debugging failures, stabilizing scripts, and watching how different user actions flowed through the system. It was intense, but it was also rewarding to see tests that I wrote run successfully end to end.
The application under test was called Oracle Agile PLM. At the beginning, it was simply "the PLM system" that my scripts had to drive. But as I worked more with it, my curiosity started to move beyond the test layer. I found myself asking why a particular screen existed, why a specific field was important, and what business process a workflow actually represented. That is when PLM slowly entered my story in a serious way.
Understanding What PLM Really Is
As I explored Oracle Agile PLM in more detail, I began to understand what Product Lifecycle Management actually means in practice. Every product we use in our day to day life follows a path. It starts as an idea, becomes a design, gets engineered and reviewed, moves through manufacturing, reaches customers, and eventually reaches end of life.
PLM is the system that connects and manages this entire journey. It is not just about storing documents or part numbers. It is about how engineering decides what to build, how changes are controlled, how quality issues are tracked, how suppliers are involved, and how the product definition stays consistent across teams and systems.
When this clicked, Agile PLM stopped looking like "just another enterprise tool" and started to look like the heart of how that organization built and managed its products. That perspective changed how I approached my work. I was no longer only focused on whether a script passed or failed. I wanted to understand what that script actually represented in the product lifecycle.
Diving Deeper Into PLM
As time went on, my responsibilities gradually expanded. I started getting involved in discussions around workflows, change orders, and data structures. I spent more time reading through configuration documents and functional specifications to understand why the system behaved the way it did.
I began working more closely with functional consultants and business users. I listened to engineers describe their pain points in change management. I heard manufacturing teams talk about the impact of incorrect or delayed data. I saw how a missing attribute or a wrong lifecycle state could cause confusion downstream.
That shift, from "how can I test this screen" to "how does this screen support a real world process," is what firmly pulled me into the PLM domain. At that point, PLM was no longer just part of my job description. It became something I wanted to understand and grow in.
Growing in India (2011 to 2019)
Over the next several years, I continued to work in India across different PLM projects and customers. The domain gave me exposure to industries such as high tech, industrial equipment, medical devices, and semiconductors. Each customer had a slightly different way of using PLM, and every engagement taught me something new.
I saw how engineering and manufacturing teams could look at the same product very differently. For some, the main focus was on design accuracy and revision control. For others, it was about manufacturing readiness, part availability, or compliance requirements. PLM was the shared space where those views had to align.
I also learned how change management could influence company performance. A slow or unclear process could delay product launches and frustrate teams. A clear, well designed process could protect the business from costly mistakes and support faster decisions.
During this phase, my own role moved beyond testing into configuration, enhancements, and solutioning. I worked on setting up change workflows, defining roles and access models, supporting integrations, and helping to improve performance and data quality. That combination of technical and functional work is still what I enjoy most about PLM today.
Working Across Multiple PLM Systems
Over time, I was fortunate to work hands on with multiple PLM and PDM platforms. Each one gave me a different angle on how companies manage their product data.
- Oracle Agile PLM - My foundation and first entry into the PLM world.
- Siemens Teamcenter - Deep engineering structures, strong integration patterns, and enterprise scale.
- PTC Windchill - Rich CAD and product structure management with tight engineering context.
- MechWorks PDM - A fast and practical PDM solution that showed how design teams work in real time.
Working across these systems helped me see common patterns and differences. I saw how CAD and PLM fit together, how BOMs evolve across engineering and manufacturing, how workflows need to scale, and how integrations connect PLM to ERP, MES, ALM, and other systems. It also gave me a better understanding of what users actually deal with day to day.
PLM and PDM A Simple View
Over the years, I developed a simple way to explain the difference between PDM and PLM.
PDM manages engineering files.
PLM manages everything that happens before and after engineering.
PDM is often close to the CAD user. It focuses on models, drawings, revisions, and check in or check out. PLM covers a wider space. It connects requirements, design, BOMs, changes, quality, suppliers, and downstream systems. Working in both areas helped me see the complete product data journey, from first CAD model to released BOM and beyond.
PLM Opened Doors Beyond India
Around 2019, PLM did not remain just a technical domain for me. It became the reason I started travelling for work. The experience I had built with Agile PLM, Teamcenter, integrations, and process consulting began to create opportunities with global teams.
What started as India based delivery gradually expanded into onsite engagements and international roles. I began working with teams in different time zones, with different cultures and expectations. I had to adjust how I communicated, how I documented solutions, and how I aligned stakeholders with different priorities.
Through all of this, PLM acted like a common language. Whether the company was in India, North America, or elsewhere, they cared about similar things. Clear product definitions, controlled changes, reliable data, and traceability. That made the work both challenging and rewarding.
Canada Eventually Became Home
Those international opportunities eventually led me to Canada. At first, it felt like a new assignment in a new country, with a different climate and a different way of working. The products, regulations, and organizational structures were all new, but the underlying challenges around PLM were familiar.
I again found myself working across engineering, manufacturing, quality, and IT. The topics were the same. How do we manage changes better. How do we connect PLM and ERP. How do we improve traceability. How do we make systems easier for users without losing control.
Over time, what was supposed to be temporary started to feel permanent. New colleagues became friends. New cities became familiar. Winters became manageable. Step by step, Canada moved from being a work location to being home.
Why I Stayed in PLM
When I look back, it is clear that a single automation assignment in 2011 quietly set the direction for everything that followed. Even though I changed companies, roles, industries, and countries, one thing has stayed constant. I stayed in PLM.
PLM sits at the intersection of engineering, business processes, data, and people. It requires both structure and flexibility. It needs attention to detail and a view of the bigger picture. Every implementation is slightly different. Every organization has its own way of managing products.
That mix of complexity, learning, and impact is what keeps me interested in this domain. PLM still challenges me, still teaches me, and still feels relevant to how real products are designed, built, and supported.
That is why, even after all these years, I am still excited to work in PLM and to continue contributing to the digital thread that connects ideas to real products in the world.