So you’ve got a degree in computer science. Should you become a software engineer or product manager?
I can’t tell you the answer, but I can tell you about my experiences as each.
Engineers and product managers work together every day to achieve the same goals, but the two roles have different responsibilities involving different mindsets.
Fundamentally, product managers are responsible for the “what” and “why” while engineers are responsible for the “how” and the “when”.
After a few years in each role, I’ve observed three key differences in mindset:
- How I spend my time
- How I measure my impact
- How I think about solutions
If you’re trying to decide between engineering and PM, see which mindsets resonate with you. While I can’t speak for all engineers and PMs, I hope my experiences help by providing insight about how each role feels.
How I spend my time
As an engineer, I split my time between a handful of activities: coding, code reviews, engineering planning, and occasional meetings.
Someone else lays out the priorities for me. Each day, it’s a matter of picking up where I left off and continuing to execute.
As a PM, I’m juggling 20 different tasks: user research, analysis, design, stakeholder management, strategy, competitor research, QA, spec writing, sprint planning, email/Slack threads…and the list goes on.
Rigorous prioritization is critical to my job. Each day, I need to figure out what the most important things to do are. No one tells me what to focus on.
👩🏻💻 The upside of being an engineer: Less ambiguity that I’m doing the right thing. Most of my days include long stretches of time that are conducive to deep work. While it’s almost part of the PM’s job description to always be context-switching, people often fight to protect the engineer’s coveted maker’s time.
👩🏻💼 The upside of being a PM: I’ve become better at time management and prioritization, which turn out to be pretty useful skills in life. (Not to mention I‘ve developed all the other skills above!) It feels empowering to be in complete control of my time, and how I spend it can feel like a puzzle in itself.
How I measure my impact
Engineers and PMs work towards the same goal: moving the company’s KPIs. But feedback loops happen on different time frames for each role, affecting how I measure my individual impact.
Engineering work has tight feedback loops: I build something. If it works to spec and the tests pass, I am successful. On the other hand, feedback loops for product development tend to be long. To make sure we’re building the right things, I must create tight feedback loops before we start building: through product reviews, user testing, user calls, surveys, and analytics.
As an engineer, most of my work on a given day is quantifiable: lines of code written, pull requests opened, story points completed, builds deployed. Of course, quantity does not equal quality, but these metrics are often a close enough proxy for measurable productivity.
As a PM, day-to-day productivity is less tangible. My work is measured through business metrics, which can take months to surface impact. At the end of a given day, I could have done a lot — persuaded the exec team we should pursue an initiative, chatted with a user to understand her behavior, discussed tradeoffs to reduce scope…but have no numbers to prove I was successful.
👩🏻💻 The upside of being an engineer: Instant gratification from tighter feedback loops. I have a stronger sense of whether I’ve succeeded at my job at the end of each day, and I can visualize my productivity over time through burn down charts.
👩🏻💼 The upside of being a PM: I own the metrics by which I’m measured. By driving the direction and developing a strategy for my team, I have a bigger scope of impact than I do as an engineer. Although the impact is less direct (and so engineers usually get the credit for it!), it’s extra rewarding when the pieces comes together and the numbers move — even if it takes a long time.
How I think about solutions
As engineers, we’re trained to solve problems: how to design, develop, and scale solutions.
As a PM, it’s important for me not to jump into solution mode, but rather to start with the WHY? Why is the user doing this a certain way, what is their job to be done, what is painful or frustrating about their current world? Once I understand the problem, then I delve into possible solutions.
In brainstorming solutions, my engineering brain thinks in terms of what’s practical and feasible given technical constraints.
My PM brain, however, needs to think broader — what is the vision for the product not only one month out, but 3–6 months, 6–12 months, 5–10 years from now? What will the press release look like?
To create a long-term vision, I need to stretch the boundaries and rethink what’s possible. By painting a picture of a brighter future, I get my team excited about what we’re working towards. From there, we can scale it back into near-term milestones that are feasible.
Once we’ve defined the solution, as an engineer I actually get to build it. I figure out how a new piece fits into the bigger system, and craft code that brings ideas to life. I turn static mocks and specs into something that works.
👩🏻💻The upside of being an engineer: I’ve become a seasoned systems thinker — breaking down problems into components and developing solutions that fit into a greater whole. I turn concepts into reality.
👩🏻💼 The upside of being a PM: I’ve become a seasoned storyteller (bonus side effect: I’m more fun at parties!) Appealing to emotions helps me persuade people both inside and outside of work.
Which path will you take?
Engineering and product management are each rewarding in their own ways. As an engineer, I enjoy heads-down time, instant gratification, and bringing products to life. As a product manager, I’ve developed a diverse skillset that I use in my regular life, and I feel like I can make a bigger impact on the company. In both roles, I’ve learned a ton.
Which path will you take? For folks with a CS degree, engineering is the more common path. As most companies have 5–20 engineers per PM, the demand is still greater for engineers, but product management is a fast-growing field.
If you’re an engineer thinking about switching to PM (like I did), I encourage you (like any good PM) to get clear on the WHY first — and make sure the PM role addresses those reasons. If you decide PM is the role for you, awesome! Your engineering experience will come in handy. There is plenty of great advice out there for how to get started.
I wish you the best of luck on your career adventures!
