If you are an engineer, then don’t become a Product Manager unless…
I moved from engineering to product and benefitted hugely from many online and offline resources about how to become a PM. However, after spending some time thinking about and experiencing the two roles, I noticed a few key differences between them that aren’t usually discussed as much. This article summarizes the most significant ones that I’ve noticed and that have helped me align myself better with the PM role.
“Product Manager” is a very generic title and every company does it differently. You might also find PMs in the same company doing very different things, so the following thoughts are purely based on my experience, so your mileage may vary! While I love the PM role, I don’t think that it’s a great career choice for every engineer, so at the risk of generalizing, I’ll just say that if you are an engineer, then don’t become a PM unless:
1. You are or want to be a generalist beyond the technical realm
In the technical world, being a generalist might mean going from a frontend SWE to a backend SWE or being great at system design while also killing it at ML. These are great technical skills, but PMs often deal with problems that aren’t technical by a long shot. As a PM, you will take multiple meetings any given day, where some meetings may appeal to your technical side but others may involve legal risks associated with your product or a sales pitch targeting a niche customer segment and so on. As you grow, you will also need to deal with things that might be way out of your usual comfort zone e.g. getting buy-ins from VP level stakeholders. You will need to be okay with doing whatever it takes to help your product and team succeed.
2. You don’t mind, perhaps even love ambiguity
You will almost always have an amazing engineering team and they will be great at solving technical problems. But it is your job define what the problem is in the first place. You need to have a deep understanding of the (hopefully, real-world) problem is that your eng team is solving, even if you don’t necessarily know how to solve it. For emerging or new products, it’s critical for you to be the source of clarity for questions like who the potential users are, which problems you need to solve for them first, how you can quickly demonstrate the value of the product, what your roadmap might look like, and so on. In my past life as an engineer, I always dealt with the ambiguity around which approach to take to solve a technical problem, but as a PM the scope of ambiguity expands far and wide.
3. You love to focus on the why and what, more than the how
As an engineer, I was always focused on how to solve a problem and I found that limiting. As a PM, you will need to define the product vision and strategy based on the broader company level objectives. Without having a deep understanding of why, you cannot get to what. The singular value that you’ll add to your team is by defining a product that addresses a real world problem and helps your business achieve it’s objectives. So for tech products, having the technical know-how is certainly a plus, but getting a grip on why and what will have an outsized impact on your career.
4. You are happy dealing with people
PMs deal with a LOT of people. Perhaps the most illuminating aspect about PMing for me was that your personality traits play a significant role in your day-to-day work. As an engineer, I never really cared about my communication. It was decent enough for a non-native English speaker and what essentially mattered was my code and the clear outcome of that code. Now what matters are the people-oriented skills — asking the right questions, figuring out user intention from actions, and influencing people without having any authority over them. Any leadership role will entail some mix of these people oriented skills, but a PM’s success truly relies on them. Since not everyone is great at these skills from the get go, the main point I want to emphasize is that you should be open to learning and developing them.
5. You are ready for some (maybe a lot of) firefighting
Few talk about this when describing a PM role, but only in an ideal world would a PM only focus on product-related work. In the real world, things happen and there are fires to put out, even more so for an emerging product. You should not lose clarity of thought when things seem to be going out of control or when external conditions cause dramatic pivots to your team or product. People will look to you as you do the firefighting and you will need to do things that you never signed up for in order to get your product out of a jam. Because you manage the product. One of the best pieces of advice I’ve received is that “ if the product fails, the PM is on the hook, but if it succeeds, the team did a great job”.
In summary, if you think you want to be a generalist who loves to deal with ambiguity, who loves to crisply define the why and the what of the product, who loves dealing with people, and who doesn’t mind taking one for the team, then well… you might turn out to be a decent PM after all.
