That’s the vibe former software engineers who moved into product management whether they’re happy with the change. The answers range from “not happy, don’t recommend” to “I miss being assigned a problem, getting paid a bunch, and not having to make a million and one decisions.”
But here’s the thing about career transition stories: they’re never as simple as the headlines suggest. The full picture is messier, more nuanced, and frankly more interesting than either the “PM life is amazing” LinkedIn bros or the “I regret everything” doom-scrollers would have you believe.
Let’s dig into what’s actually happening when engineers cross the aisle into product, and whether the move is worth the emotional baggage.
The Unvarnished Reality: It’s Harder Than Anyone Admitted
“Not happy. Much more difficult. Don’t recommend.”
You’re responsible for everything that goes on and get no recognition when things go well!! Being an Eng was the best – you are super pampered and shielded from a lot! I didn’t realize that until I switched functions.
That sentiment echoes across the thread with startling consistency. One engineer-turned-PM describes the role as “being a janitor sometimes, nobody notices the work you do until there’s a giant shit on the floor that hasn’t been cleaned up yet, and then it’s your fault.”
This tracks with what Ryan Murphy, former engineering manager at Yelp and founder of EM Accelerator, tells engineers considering leadership roles: “Going into Engineering Management isn’t a promotion, it’s a career change… You should not be a manager because you think it’s a step up. That’s one way to regret your life choices and fast.”
The skills that made you a great engineer, deep focus, technical problem-solving, elegant solutions, don’t just become less useful in product. In some cases, they actively work against you.
The Technical Mindset Trap
One commenter describes the first few years as “trying to build flatpack with the wrong size allen keys.” Their toolkit of “clear, clean, code-based comparisons, raw numbers, data” proved “absolutely useless in convincing senior stakeholders to do the right thing.”
This is the disconnect that kills many SWE-to-PM transitions. Engineers are trained to optimize for technical correctness and elegant architecture. Senior stakeholders? They’re optimizing for commercial outcomes, P&L impact, and not getting fired.
The same commenter describes their breakthrough realization: “My job is not to share with them the data but to tell the story that data shows.” They stopped saying “this moves all ordering logic to a table” and started saying “this gives you commercial and supplier levers.”
That’s a fundamentally different skill set, and one that most engineering career paths don’t prepare you for. The complexity inherent in building and managing software systems doesn’t translate to the complexity of managing stakeholder expectations and organizational politics.
The Role Has Changed, Whether You’re Ready or Not
The PM role that engineers are transitioning into today isn’t the one that existed even five years ago. One thread commenter lays it out:
“The Product Manager role has dramatically changed where the stakes are very high and expectations for the role are honestly too much for one person. Gone are the days where you could be the Product Manager for the email send button. The role now requires being the main POC for all things related to not just product ideation, but also stakeholder alignment, executive debriefs, customer retention and growth, marketing narrative, process management, infrastructure roadmap, legal compliance…”
They add, almost as an aside: “I’m pretty sure I forgot something else which I’ll be blamed for eventually.”
Craig Unsworth’s analysis of the evolving PM role suggests this isn’t just anecdotal. He argues that “AI has compressed the lower-value, repeatable parts of the role” and that the differentiators are shifting from producing artifacts to exercising judgment. The PMs who thrive aren’t those who write better PRDs, it’s those who know “which customer request should be declined.”
For engineers making the leap, this means the bar isn’t just “learn business stuff.” It’s “develop commercial judgment that rivals people who’ve spent their entire careers in business roles.”
The Decision Fatigue Is Real
One of the most revealing comments in the thread: “I miss being assigned a problem, getting paid a bunch, and not having to make a million and one decisions.”
This flips the common assumption that engineers want more autonomy. Many don’t, they want clear problems and the space to solve them well. The PM role is an endless stream of decisions, many of them made with insufficient data, conflicting stakeholder input, and consequences that aren’t visible until much later.
A former finance professional who pivoted to PM notes their career progression is “the exact opposite of having to make less decisions over time.” In finance, you build judgment and eventually make fewer, bigger calls. In product, the scope just keeps expanding.
For engineers who found comfort in the deterministic nature of code, this ambiguity can be genuinely destabilizing. The PM role is essentially handling uncertainty and state in distributed systems, except the systems are humans and the state is organizational politics.
The Translation Skill Nobody Tells You About
The most positive take in the thread comes from someone who figured out the translation problem:
“SWEs experience and knowledge can hold you back as a PM. But imo it’s a strength, as long as you learn how to translate your knowledge into a format your stakeholders can understand.”
This is the difference between engineers who thrive in product and those who crash. The ones who succeed treat stakeholder communication as seriously as they treated debugging. They recognize that “nobody is paying for your perfectly refactored function. They are paying for the seconds it takes off a support call.”
One commenter describes the shift: “It’s a really hard shift to go from being the expert/smartest person in the room, to being the one that makes everybody else feel smart.”
That’s a profound ego adjustment for people who’ve built their identity around technical mastery.
Should You Make the Jump? The Honest Criteria
Based on the collective experience in that thread, and the broader patterns in career research, here’s what actually predicts success in the SWE-to-PM transition:
You should probably make the move if:
- You’re energized by ambiguity and cross-functional politics rather than drained by it
- You can derive satisfaction from enabling others’ success rather than shipping code yourself
- You’ve already been acting as a tech lead and finding the “people work” more interesting than the “tech work”
- You’re comfortable making decisions with incomplete information and being wrong publicly
You should probably stay in engineering if:
- You find deep satisfaction in solving well-defined technical problems
- The idea of stakeholder therapy and ego management sounds like torture
- You want recognition for the work you do (PM recognition is famously invisible)
- You’re looking for an “easier” role with less stress (it’s not, it’s different stress)
As Ryan Murphy advises: “Be a tech lead first. One of the hardest roles in tech, no formal authority, and none of the skills that got you there will help.”
If you can handle tech lead and want more, PM might be the right move. If tech lead already feels like too much people management, running from engineering won’t solve your problems.
Worth It, But Only If You Know Why You’re Going
The engineers who thrive in product aren’t escaping engineering, they’re moving toward something specific. They want to own business outcomes rather than technical implementations. They want to influence strategy rather than just execute it.
The engineers who regret the move are usually running away: from office politics, from being undervalued, from the tedium of legacy code. Product management doesn’t solve those problems, it trades them for a different set that’s often harder.
The engineering culture that values deep technical execution (product-led engineering and deep technical execution) doesn’t prepare you for a world where your success depends on convincing people who don’t understand what you do. That’s not a bug in the PM role, it’s the entire job.
One commentator captures the sobering reality: “Ya easier days are largely over. Insane pressure now on PMs with no better pay.”
For engineers considering the transition, the message from the trenches is clear: don’t romanticize either side. Engineering has its own grind. Product has its own exhaustion. The difference is which flavor of pressure you can sustain without burning out.
The people who make the switch work aren’t the ones who found a perfect role, they’re the ones who learned to play a different game entirely. As one successful convert puts it: “Once I made that transition I was MUCH happier as a PM than as an SWE. But it does require a change of mindset.”
The question isn’t whether PM is better than engineering. It’s whether you’re willing to become a different kind of professional, one whose value comes from judgment, translation, and political navigation rather than code.
That’s a career change, not a promotion. And it deserves that much thought.
