A perspective on product operations

Jim Smith

CEO

My PLM Story

My career in PLM didn’t start in software — it started on the manufacturing floor.

In 2006, I began as an assembler, working hands-on in production environments where output quotas, quality standards, and operational efficiency weren’t abstract concepts — they were daily realities. Over time, I was promoted into lead roles, then into quality engineering, and eventually into production management overseeing operations and teams for years. In those environments, failure wasn’t an option. If a process didn’t work, production stopped. If a system failed, people found workarounds — immediately.

That experience fundamentally shaped how I view systems, data, and process today.

While working in production, I pursued a bachelor’s degree in software development. At the time, my goal wasn’t to leave manufacturing — it was to diversify my skill set and continue advancing. I enjoyed working with computers, and I understood that technical fluency would be increasingly important in modern operations.

That decision changed the trajectory of my career.

During my degree program, I accepted an internship one day a week — Fridays — providing help desk support for Verdant, a Seattle-based implementation partner specializing in Oracle PLM for Process. After completing my degree, I transitioned fully from production management into a junior technologist role supporting PLM implementations.

The contrast was striking. I went from physically demanding, time-critical production work to solving complex technical and process problems — and I loved it. For the first time, I could see how software, data models, and workflows connected directly back to the operational realities I had lived for years.

Although I initially viewed PLM as just another enterprise system, I quickly realized it sat at the intersection of production, quality, compliance, procurement, packaging, and product development. My background allowed me to understand the full stack — not just the technology, but how decisions upstream affected execution downstream.

That combination moved me rapidly into consulting — somewhat against my original intentions. There were few people in the PLM for Process space who deeply understood production operations, business process, and technical architecture at the same time. As a result, I was often brought in at the end of implementations as the “cleaner.”

If a project was struggling, incomplete, or stalled, I was sent in to finish it — configuration fixes, data migration, reporting gaps, training issues, operational workflows, or adoption challenges. Over time, I was asked to build and lead a Business Process Outsourcing (BPO) function, providing ongoing administrative and operational PLM support for clients.

That work exposed a pattern I couldn’t ignore.

Across every system, every industry, and every implementation, the same issue appeared:

the software was live, but the business wasn’t using it.

Not in the way it was intended — and not enough to support daily work.

I could see system usage at a technical level. Login frequency. User behavior. Actual adoption. The reality was often shocking. After 9–12 months of implementation effort, businesses quietly reverted to spreadsheets, emails, and workarounds. PLM existed, but it wasn’t operational.

Coming from manufacturing, this was baffling. In production environments, once a system goes live, there is no alternative. You use the system — or operations fail. Yet in enterprise PLM, non-use was somehow tolerated.

Over time, another realization followed:

the tool itself wasn’t the problem.

I began seeing my own configuration and data work still in place years later — even when the original project teams were long gone. The foundation was sound. What was missing was operational ownership, maturity, and ongoing alignment with how people actually work.

That realization led to the creation of Dazmii.

Dazmii was built to address the gap between PLM implementation and PLM value. We are system-agnostic by design. If your team is required to use a PLM system, we can support its operation — regardless of platform.

But we also learned that “PLM operational support” alone is not enough. Too often, it’s reduced to data entry — turning PLM into the most expensive spreadsheet a business owns.

The real value lies in

PLM maturity

.

PLM maturity is what transforms a system from a repository into an operating model. It enables change management, new product development, regulatory compliance, reporting, and cross-functional decision-making to function as a cohesive machine rather than a collection of disconnected activities.

Today, my work is focused on helping organizations move along that maturity curve — stabilizing operations, standardizing execution, and enabling PLM to support how the business actually runs.

At its core, my career has always been about problem-solving. Whether on the production floor or inside enterprise systems, I’m motivated by helping teams succeed, reducing friction, and turning intent into execution.

PLM has become a tight-knit, highly capable community — and it’s where I plan to continue contributing. The people, the products, and the challenges are what keep this work meaningful.