I went from product management to software engineering early in my career. At the time, I didn't know it was unconventional. Looking back, the naivety probably helped — if I'd understood how rare the move was, I might have talked myself out of it.
Here's what I actually learned from living on both sides.
Accountability hits different
As a PM, success is diffuse. Market conditions, sales execution, design quality — a dozen factors outside your control determine whether you win or lose. You can do everything right and still fail. You can do everything wrong and get lucky.
Engineering strips that ambiguity away. Your code works or it doesn't. The deploy succeeds or it fails. If there's a bug in production, it's yours to fix.
Engineering accountability boils down to two things: your code has to work, and it has to ship. Simple to say. Brutally hard to do consistently.
Binary thinking is a trap
Engineering rewires your brain. You start thinking in boolean:
- Does this handle all edge cases?
- Is this system fully redundant?
- Is this feature complete?
That thoroughness is a superpower for building reliable systems. But it's a liability when you carry it into product decisions. In engineering, ambiguity is a bug. In product, ambiguity is the default state. Learning to hold both modes was one of the hardest adjustments.
The "how" obsession
Early on, I went full engineer brain. How to implement this feature. How to design this system. How to debug this issue. I stopped asking why we were building things at all.
That's the trap most engineers fall into. You start equating difficulty with importance. You spend a week on an elegant caching solution when the highest-impact move was changing a config value. The PM part of my brain eventually kicked back in: the hardest problem is rarely the most important one.
It's a one-way door
Going from engineering to product is a well-worn path. Engineers build product intuition naturally — every technical decision forces you to think about users, business goals, tradeoffs.
Going the other direction is much harder. You can learn to code. You can ship side projects. But inhabiting the engineering mindset — the instinct for system design, the paranoia about edge cases, the muscle memory of debugging — takes years of focused practice. I did it, but I wouldn't describe it as efficient.
Passion arbitrage
In product, you can't fake it. If the domain doesn't excite you, your team will feel it. Your roadmap will reflect it. You'll coast.
Engineering has a cheat code: the craft itself is interesting. You can work on the most boring product imaginable and still find deep satisfaction in a clean architecture or a well-optimized query. Engineers can borrow passion from the work itself. PMs have to bring it from the domain. That's a real structural advantage.
The real leverage
The PM background gives me something most engineers don't have: I can smell when a project is going sideways before the code tells you. I can sit in a planning meeting and know which "simple" feature request will take three sprints. I can translate between the engineer who says "it's technically impossible" and the PM who says "we need it by Friday" — because I've been both of those people.
That's the leverage. Not that I'm a better engineer or a better PM than someone who's only done one. It's that I can operate in the gap between the two, where most miscommunication and wasted effort lives.
If you're a PM considering a similar move: do it. But know that the value isn't in leaving product behind. It's in carrying product thinking into engineering, where it's desperately needed.