7 key differences between a Software Engineer and a Product Manager
TLDR; You can also watch this article in video form here: https://www.youtube.com/watch?v=h3XZea2-Ofk&t=1s
Being a computer science major can be confusing these days. There are SO many career options to choose from, and only a few years of internship opportunities to try them out.
After I graduated college, my biggest struggle was deciding between iOS development and product management. I spent a few years flip-flopping between the two, before finally deciding and committing to one; product management! Below, I’ll discuss the 7 key differences I’ve noticed in my day-to-day. If you’re still struggling to make the decision, I hope that this article makes it a little bit easier (:
P.S.: I have a Computer Science degree from Grinnell College, and I spent a total of 2.5 years as an iOS Developer and 2 years as a Product Manager.
1. Area of Influence
Let’s start off with the area of influence.
A software engineer is concerned with HOW things get built. They arethe ultimate decision-maker in terms of software architecture, tech stack, and implementation details. In terms of the company as a whole, a software engineer also contributes to technical excellence for the whole engineering organization.
On the other hand, the product manager is concerned with WHAT we build and WHY we’re building it. They’ll own the team’s future initiatives and roadmap. In the grand scheme of things, they contribute to the company’s overall strategy and help bring the initiatives of other teams to life if they need product support.
2. Nature of Work
Moving on to the actual nature of your work.
As a software engineer, your work has a pretty narrow scope. You’ll have lots of clarity for most of the things you’ll work for, and ultimately you’re the one who’s responsible for the product. The nature of your work is almost purely in execution.
Your responsibility is to write, debug and ship quality code, design solutions for technical problems, improve engineering velocity and keep a stable, scalable, and performant product. The biggest chunk of your work is focused on managing code.
That means writing code, writing tests, and deploying software. You’ll do a lot of pair programming, create pull requests, doing code reviews for your teammates, and writing documentation to maintain a healthy codebase. Once you progress in your careers you’ll also be in charge of designing broader software architecture and mentor junior engineers.
As a product manager, your scope is very, very broad and you have very little clarity on what you should be doing. In fact, it’s your job to provide clarity for others! You’re ultimately accountable for the product, so if something goes wrong… it’s your fault ;) You have two modus operandi: strategy and execution!
Strategy means you try to identify opportunities between business and customer needs and prioritize initiatives and tactics to address them. You need to have a really good sense of the competitive landscape and constantly analyze your market. You also spend a lot of time seeking knowledge, feedback, and buy-in from relevant stakeholders to ultimately sell your vision for the product’s future.
The second part also focuses on execution. As a PM, you create and set a roadmap, write product specs and requirement docs. You might build mockups and provide lots of design feedback. You’ll write and prioritize user stories, and work with engineering to get them to build while navigating trade-offs. You’ll manage the launch processes, use data to measure the success of your features, and then iterate in response to user feedback. Most importantly you’ll motivate your team and make sure to remove any blockers they’re facing to keep the momentum going. Instead of managing code… you manage relationships, with your teams, your users, and your internal and external stakeholders.
3. People Interactions
A big part of any job is interacting with other people.
As a software engineer, you interact with a much smaller number of people than a product manager. So if you’re an introvert, software engineering might be the way to go. In a typical week, a software engineer will spend most of their people time with other software engineers. Next up are designers, QA analysts, and product managers, and last up are data analysts or scientists. That’s not to say a software engineer can’t or won’t ever interact with anyone else, but the chances of that happening regularly are slim.
As a product manager, in any given week, you’ll definitely interact with all the same roles as a software engineer; software engineers, designers, other product managers, QA analysts, and data analysts, BUT…
You’ll also interact with marketing, and content or copywriters, sales, finance, compliance, user research, customer service, and more depending on what industry you work in. You’ll also spend a lot of time interacting with external stakeholders, which will most likely be account managers for 3rd party software. Most importantly though, you will spend a LOT of time interacting with your users. As a PM, one of your core responsibilities is growing and maintaining relationships with everyone related to the company, whether it’s inside or outside. So, if you’re an introvert, beware, because it can get pretty exhausting.
4. Domain Knowledge
As far as your domain knowledge goes, a software engineer can be described as a specialist.
You will know all the ins and outs of your engineering stack and alternative options. You’ll develop expertise in programming languages and technical concepts, and you’ll make sure to adopt the best practice and processes for engineering teams. The great thing about being a software engineer is that your domain knowledge is industry agnostic. If you currently work in EdTech, you can easily pick up your bags and move to a different industry, like healthcare, because the skills you have to know are broadly the same. Your day-to-day won’t change much, only the context of your work.
As a product manager, on the other hand, you’re a very broad generalist. You kind of need to be a Jack (or Jill) of all trades. Your domain of knowledge is equally split between hard and soft skills.
First, understanding basic programming and large-scale software systems. Programming is not really necessary, but it’s SUPER useful, so I highly recommend at least taking a few courses. Next is low-fi design and prototyping that goes along with user research and interviewing, and data analysis and manipulation. You’ll work with specialists who are much better than you in all of these domains, but you need to know enough to discuss and make decisions in each of these fields competently.
The other 50% are your soft skills, like collaboration, communication, presentation, conflict management, and relationship building. One thing that’s not great about being a product manager, is that the longer you work in a certain role or industry, the more of an industry expert you become, which makes it difficult to make a move to a different industry in the future. For example, if I spend 5 years working in fintech, but I really want to work in EdTech… my 5 years in fintech won’t serve me well. Unless I go to a company that somehow combines both (:
5. Evaluation
The 5th key difference is related to evaluation.
As a software engineer, you have a very clear-cut and binary definition of success. Either your code works, or it doesn’t. Either you solve a bug, or you don’t. You’ll always know if your code has 100% test coverage or not and it’s easy to tell how much of your codebase you’ve converted to Swift VS Objc-C, for example. Your sense of accomplishment is very frequent and you’ll constantly receive affirmation that you’re doing a good job (or not).
As a software engineer, you’re an individual contributor, and that means that your success is also evaluated as an individual. You get constant feedback from your product via analytics frameworks in terms of adoption rate and stability, and also your colleagues through code reviews. And the feedback that you get is generally very tangible and actionable. When you read through your code reviews you’ll know exactly what to fix, and your debugger will tell you exactly where there’s a bug in your code. It’s black and white.
As a product manager, though, you don’t have clear success metrics. Sure, you can measure how your features and experiments are performing, but that’s only a small fraction of your job. Everything else, like relationships, alignment, and whether you’ve made the right (or at least good) choice are difficult to measure. Your sense of accomplishment is infrequent and delayed, based on product launches and company quarters.
Your success is not based on you as an individual, but rather on the success of your team and your product. Is your team motivated, are they working together well, have you made things clear for them, what’s their velocity, and have you unblocked them… As a product manager, you get very irregular feedback on your actual day-to-day.
You get a lot of feedback and opinions on the product itself from everyone involved, but very little is tangible feedback on YOUR work. The feedback you do get is very intangible like:
- Why didn’t you make this feature more prominent?
- Have you looked into this issue yet? Why not?
- When will my requests get prioritized?
Often there are MANY different ways to act on this feedback and you have to apply a bit of your gut feeling and data analysis to decide on your course of action, but you’re never 100% sure that anything you do is actually correct. Your life is never black and white, but rather a spectrum of 50 shades of grey.
6. Time Horizons
Another key difference are your time horizons.
As a software engineer, you normally work in 2 or 3-week sprints, sprinkled with a very structured timeline of agile processes and ceremonies like groomings, plannings, retrospectives, and post mortems. When a sprint begins you have a set amount of work to get done and once you get all that done, you’ve finished a chunk of your work. This makes it very easy to plan how to structure your work and when to do it.
As a PM, though, you’re always oscillating between what’s happening NOW, what’s happening NEXT, and what’s going to happen in the FUTURE. You tag along in all of the agile processes and you probably coordinate and lead the sessions, but otherwise, your timeline is very unstructured. New work keeps coming your way and you can hardly plan a few days in advance, let alone a few weeks.
7. Flexibility
Finally, the last key difference is flexibility.
As a software engineer your job is to get a set amount of work done in an allotted time frame, but WHEN you do that work and WHERE you do it from doesn’t really matter. Since most of your work will be asynchronous from the rest of the team you can be very flexible to decide when doing focused deep work suits you, and when you want to do more admin-related tasks. Of course, you’ll still be collaborating with coworkers and have to come to regularly scheduled meetings, but generally, you have much more freedom with your time. It’s easy to work on a different schedule than your coworkers, and even in a different time zone — within reason, of course.
While a product manager’s role sounds a lot more flexible, the overall environment in which you work is less so. Because you work across many different disciplines and collaborate with basically the entire company, you need to make sure that your work syncs up with other people. I’m overexaggerating a bit, but it can definitely feel like you’re a slave to your calendar and Slack sometimes and you have to be very strict with setting boundaries to carve out some time for deep and focused work. And while COVID has made it possible for a lot of us to work from home, generally, a product manager has to be present at the office most of the time. The main reason for this is having “facetime” with your coworkers which goes hand in hand with building and maintaining relationships because much of what you can accomplish will depend on how much social capital you’ve built.
Alright, you’ve made it to the end! Obviously, everyone’s experiences are different, so the above are purely based on my own experiences and reflections.
Now, I’d love to hear from you! What has your experience been with the roles? Do you agree or disagree with what I wrote? Comment down below, I’d love to get a conversation going (:
