The bridge between operations and product
Nearly a decade ago, I started as a sourcing engineer dealing with supplier delays, cost pressure, and production constraints. Today, I work on Oracle TMS implementations across enterprise logistics environments. The path was not planned, but the skills have been connected: understanding operational problems, translating them into workable solutions, and staying close enough to execution to know whether the solution actually holds up.
That thread has carried through every role. At Classic Auto Tubes, it meant managing sourcing operations and supplier follow-ups where delays directly affected production. At Insulet, it meant improving procurement workflows, supporting supplier decisions, and helping cross-functional teams manage cost, availability, and manufacturing readiness. At IBM, it means working with business users, IT teams, carriers, and operations stakeholders to gather requirements, configure workflows, coordinate testing, and support adoption.
Across those environments, the work has rarely been just about a process or a system. It has been about the gap between what the business needs, what the system can support, and what users will actually adopt. That means asking where the process is breaking, identifying the root cause, prioritizing what needs to change, and negotiating through the real constraints — time, budget, data, stakeholder alignment, and competing expectations.
That is where product thinking entered the work. What started as process improvement evolved into a focus on better tools, clearer requirements, stronger adoption, and measurable outcomes. My work has always sat at the intersection of People, Process, Platform, and Product. I'm now focused on roles where that combination is an advantage — not a detour.