From ML Engineer to Product Manager: Why I'd Do It Again
I used to write the code. Now I manage the product. Here's what nobody tells you about making that switch — and what you carry with you when you do.
I used to spend my weekends debugging segmentation faults in C++ code that ran on factory floors in Illinois. The robot I worked on sorted optical fibers a quarter of a millimeter wide, aligned to five microns. That's the kind of work that teaches you what precision means.
Nobody tells you, when you're deep in that world, that the hardest problems aren't technical.
The code was fine. The models were fine. What wasn't fine was the meeting where nobody could agree on what to build next. The product spec that changed three times in a week. The founder who had fourteen ideas and no north star.
The Moment I Stopped Just Writing Code
There was a specific afternoon — I was deploying a computer vision system to a supermarket in Qatar, watching it hit 95% accuracy on edge devices, thinking: this is incredible. We built something real.
And then three months later, the client changed direction. Not because the technology failed. Because nobody had clearly defined what success looked like from the start.
That's when I started paying attention to the product side of things.
What the Switch Actually Looks Like
A lot of engineers think switching to PM means giving up technical work. It doesn't. It means applying technical thinking to a different set of problems.
Instead of debugging code, you're debugging a roadmap. Instead of asking "why is this function returning null," you're asking "why are users dropping off here." The mindset transfers. The tooling changes.
The first thing I noticed as a PM was how much faster I could move with engineering teams. I wasn't translating — I was participating. When I pushed back on a timeline, I could explain exactly why. When I scoped a feature, I could already see the edge cases.
What You Carry With You
There are three things engineering gave me that I use every single day as a PM:
- The ability to know when something is technically risky vs. just unfamiliar.
- Knowing what "done" actually means versus what it looks like on a spec.
- The patience to sit with a problem until I understand it completely before proposing a solution.
Most PMs are optimizing for speed. Engineers are optimizing for correctness. The sweet spot is somewhere in the middle, and having lived on both sides means I can find it.
I'm not a PM who learned to talk to engineers. I am the engineer. I just also happen to understand people, products, and why startups stall.
The Honest Truth About the Transition
It's uncomfortable for a while. You give up the satisfaction of seeing a green build. You give up the clarity of knowing exactly when you've solved a problem.
Product is messier. Success is harder to define. The feedback loops are longer.
But the leverage is 10x. One good product decision affects millions of users. One bad one can kill a company. If you're the kind of engineer who's always wondering why you're building what you're building — the transition isn't a career change. It's the next logical step.