Engineering to Product Management: Lessons from My Journey

Introduction

I didn't plan a path toward product management. For four years, my job was to keep electrical systems running — installing ABB drives, commissioning plants, tracing failures back to their root cause. Nobody on those job sites talked about "product strategy." We talked about downtime, root causes, and whether the shift would end on schedule.

Looking back, that's exactly where the lessons started.

The Pattern I Kept Noticing

Every role added something. At VDEAL, I learned the unglamorous basics: how to install a drive correctly the first time, and how to stay calm when a client's line is down and everyone is watching you fix it. At Logix, I started leading — mentoring junior engineers, becoming the person clients called when something needed to just get handled. At Quess, I sat in the middle of a plant commissioning, watching how badly things slip when mechanical, civil, and instrumentation teams don't talk to each other on schedule. At JK Paper, I owned reliability at a scale where a missed root cause meant real, repeated cost.

Somewhere in the middle of that — I don't remember the exact moment — I noticed I was spending as much energy thinking about why a decision made sense as I was on the technical fix itself. Why was this maintenance schedule the right one, not just a safe one? Why did this vendor's proposal make commercial sense when a cheaper option existed? That question kept showing up, and it wasn't going away.

What Engineering Actually Teaches You

People outside engineering sometimes assume the job is mostly technical: read the manual, follow the procedure, fix the machine. In practice, most of what I did was closer to diagnosis and coordination than pure technical execution.

A few things stuck with me:

• Precision matters because consequences are real. Skip a detail in a plant and it doesn't stay hypothetical — it becomes an outage.
• Most hard problems are coordination problems. The technical fix is often the easy part. Getting five teams aligned on when and how to apply it is the hard part.
• Documentation is not overhead. It's what makes the next person's job possible, whether that's the next shift engineer or an auditor two years later.

None of that is unique to electrical maintenance. It's just where I happened to learn it first.

The best engineers I worked with weren't the ones who knew the most facts — they were the ones who asked the right question before touching anything.

Why I Chose an MBA Instead of a Lateral Move

I could have stayed in engineering and moved laterally — a bigger plant, a management title, more scope within the same kind of work. That path is completely valid, and I respect the people who take it.

But the question I kept circling back to — why does this decision make sense, not just how do I execute it — pointed somewhere else. Product management, as far as I could tell from the outside, was the discipline built entirely around that question. It asked engineers and businesses to sit at the same table.

So I started an MBA specializing in Product Management¹, not as a rejection of engineering, but as an attempt to formalize the half of the job I'd already started doing informally: translating technical reality into business decisions, and business priorities into technical ones.

What I'm Carrying Forward

I'm still early in this transition. I don't have a product management job title yet, and I'm not going to pretend the MBA has taught me everything I need. What I do have is four years of evidence that I can take ambiguous, high-stakes problems and work them down to a fix that holds up under pressure. That instinct doesn't disappear when the "machine" becomes a product instead of a motor drive — it just needs new tools pointed at it.

That's the bet I'm making, one project at a time.

Footnotes

1. Specializing in Product Management at Hari Shankar Singhania School of Business, starting August 2025. ↩