I went from product management to software engineering early in my career.
At the time, I did not understand how unorthodox that path was, which probably helped the switch (if I had known how rare the move was, I might have talked myself out of it).
My product experience did not make me a better engineer on day one. I was slower than people who had been living in code, and I had the imposter syndrome to match.
Nonetheless, I pressed on, and eventually, the benefit showed up.
Accountability gets less abstract
Product accountability is real, but it is diffuse.
Market timing, sales execution, design quality, pricing, distribution, leadership patience: a lot can make a good product decision look bad or a bad one look good.
Engineering removes some of that fog.
Your code works or it does not. The deploy succeeds or it fails. If a bug hits production, someone has to fix it, and there are only so many places to hide.
That kind of accountability is clarifying, but it's also humbling.
Product taught me to think in outcomes; engineering taught me that outcomes still have to survive contact with implementation.
Binary thinking helps until it does not
Engineering trains you to look for edge cases:
- does this handle nulls?
- what happens on retry?
- is the migration reversible?
- who gets paged when this breaks?
That paranoia helps because reliable systems are built by people who ask annoying questions before production asks them louder.
Product work, on the other hand, does not always reward binary thinking. Sometimes the right answer is not correct or incorrect. It is "directionally right, cheap to learn from, and not fatal if we are wrong".
I had to learn to switch modes. In engineering, ambiguity is often a bug. In product, ambiguity is usually the medium.
The hard thing is not always the important thing
Early on, I over-indexed on engineering difficulty.
If a problem was technically interesting, I wanted it to matter. Sometimes it did, but more times than not, the highest-leverage move was a config change, a clearer error message, or deleting a half-clever abstraction that had outlived its usefulness.
The product part of my brain started helping again once I stopped treating it as a previous life.
It helped me ask:
- why are we building this?
- who changes behavior if it works?
- what is the smallest version that teaches us something?
- is this hard because the problem is hard or because we modeled it badly?
Those questions are not separate from engineering. They are part of good engineering.
The value is translation
The PM-to-SWE path gave me a better angle on the gap between product intent and system reality.
I can sit in a planning meeting and hear the feature request that sounds small but implies a new data model. I can hear the engineer say "technically impossible" and usually translate it into "possible, but expensive in these three ways." I can hear the PM say "we need it by Friday" and understand which part of the ask is actually immovable.
That translation work matters more than people admit.
Most waste does not come from people being careless. It comes from teams using the same words for different things until the code reveals the disagreement.
I would still do it
Going from PM to engineering was not efficient. If the only goal was to become a strong engineer as fast as possible, there were cleaner paths.
But I would still do it.
The combination works: product gave me taste for problem selection, and engineering gave me respect for the cost of being vague.
The value is not in leaving product thinking behind, but rather, it's in bringing it into the places where systems are designed, tradeoffs are made, and "we can probably ship this" becomes an operational commitment.