Assuming you have no professional experience in the opposite discipline, moving from PM to Eng is harder than moving from Eng to PM. The main reason is that being a full-time PM doesn’t give much opportunity to learn how to be a successful professional software engineer, even if you have academic training as a software engineer.
However, being a software engineer—especially a senior or lead engineer—provides frequent opportunities to learn and practice skills you’ll need as a PM. Examples:
- You’ll have to write specs or other written artifacts that others will follow. Even if these are technical specs, you’ll still need to communicate clearly, to organize your thoughts logically, etc.
- Lead engineers need to learn how to manage schedules, to identify blockers and bottlenecks, to keep their teams moving at full speed, etc. Most of this work transfers exactly over to the project-management part of PM work, except you’ll have different resources and dependencies (marketing, partners, etc.) in addition to just engineers.
- Obviously, you’ll need to learn how to work with engineers, to win (and lose!) arguments with technically-inclined colleagues, and you’ll learn how to get a team to come to consensus on a technical course of action. As a PM you’ll need to do that to— although with more humility required because you’ve moved to the Dark Side. ;-)
- You’ll need to weigh trade-offs (e.g. resources vs. time vs. quality vs…) and make tough decisions about what to fix and when. Same as a PM, except instead of trade-offs between algorithms you’ll be managing trade-offs between features, between market opportunities, etc.
- As a senior engineer in most companies, you’ll have opportunities to interact with customers and learn to effectively use those interactions to make better decisions. You’ll get practice translating the incremental, often-contradictory things that users ask for into clear direction for your team. You’ll learn to tell the difference between needs and wants, and you’ll start to learn how to gently disappoint customers—who have no idea how software is built—without offending them.
- You might get experience presenting or speaking to large and small audiences. These might be technical presentations, but presenting skills are really similar across topics.
- You’ll learn to use issue tracking tools (e.g. JIRA) that are as important to PMs as they are to engineers.
Another way of saying this is that if you want to be a PM and you’re currently an engineer, you can start doing more and more PM-like things until you’re essentially a PM without the job title. Many software companies take it one step further— there are no people whose job title is “Product Manager” but if you look at what some “engineers” do every day, at other companies they’d be called PMs.
True, there are some PM things that most engineers never do, like writing press releases or running formal customer feedback programs like focus groups or surveys. And you won’t be able to build slide decks like a pro or present to non-technical audiences until you do it a lot. But those are easy skills to learn for folks who have the interest and a PM-like temperament.
But there’s a much longer and more critical list of things that professional software engineers do that PMs never do. And these are things seldom taught in university CS programs— so you generally have to learn on the job. Here’s a few examples:
- Learning the difference between the coding you did in school (small assignments to solve a clearly defined problems) and the coding that professional software engineers do, which is mostly bolting new code into a complicated and cobbled-together-over-years codebase. Analogy: the code you wrote in school is like building a scale-model house. The coding you do at work is like remodeling a bathroom with a screwdriver and a broken hammer.
- Muscle-memory proficiency with code editors, debuggers, and other tools. Your powerpoint keyboard shortcut skills don’t transfer!
- The interpersonal processes that help teams write great code, including code reviews, coding standards, etc. PMs generally work more independently. Other PMs won’t tell you that your bullet points are wrong! ;-)
- Entire parts of the software development process are barely mentioned in school. You’ll need to learn them, e.g. large-scale build systems, test automation, source control systems, profiling to catch performance problems, load generation tools, etc. As a PM you might have two or three core tools, e.g. Figma, Google Slides, and JIRA. As an engineer you might have 10+ tools that are all harder to learn than PM tools, and every 2–3 years they get replaced with a new generation.
- Learning the fanatical attention to detail that’s required to build solid software. PM work is often more forgiving. As an engineer, if you break the build one too many times, then you’re fired!
So… if what you’re really asking is “I’m not sure if I should be a PM or an engineer… what happens if I make the wrong choice” then I’d recommend starting out as an engineer. Having engineering experience will definitely make you a better PM. The reverse is not as true.