3 Key Watchouts for Software Engineers turned Product Managers.

Photo by Alfred Aloushy on Unsplash

Let’s face it, you’ve probably seen this for a while now, and this is probably the millionth article or blog post related to transitioning from software engineering to product management or a how-to-guide on making that jump. If this is indeed your nth reading on this subject, then you are most likely realizing that there’s no one-size-fits-all answer out there, and the most essential thing you should understand is that it depends on your current circumstance.

Here are three key things to watch out for when making the jump to product management from software engineering:

1. Technical skills may or may not hinder your PM growth.
2. Build with your customers/users in mind.
3. You will have to communicate with people constantly.

Let’s dive into the first one…

1. Technical skills may or may not hinder your PM growth.

Undoubtedly, your technical skills will give you an advantage over other PMs who might not have them. However, from my personal experience, there are some hurdles that come with it, especially behaviors such as:

• You start “solutioning” too quickly without asking why.
  As an engineer, your mindset is wired to fix and solve problems. However, when it comes to product management, sometimes some problems aren’t worth fixing. As a product manager, you must now weigh the cost of fixing something versus the value it will provide. Additionally, your pride as an engineer may hinder you from accepting that a problem is not worth fixing (at the moment or indefinitely).
• You think technology is the answer to everything.
  When I was still a software engineer, I thought tech could solve all of our problems, but the reality is the world has and can still function without technology. As humans, we always find ways to adapt. And sometimes, if not often, the best way to solve a potential problem is to use your soft skills. In my experience, there have been many times when the plan to build something was axed after having a meaningful discussion regarding the value of a certain feature or enhancement. My favorite exercise to run with stakeholders is “The 5 Whys”. “The 5 Whys” originated from the founder of Toyota, Sakichi Toyoda in the 1930s.
• Your answer is always yes.
  This is a mixture of both points above. Because you think technology is the answer to everything and quickly jump to solutions, your default answer to stakeholders is “yes.” I often made this mistake as a first-time software engineer turned product manager. I wanted to be the savior and solve everybody’s problems, and at times, I could, but looking back, I now see how useless some of those efforts were. With my current product manager hat, I felt I could have made better decisions which would, in turn, save further effort, time, and costs.

2. Build with your customers/users in mind.

“You’ve gotta start with the customer experience and work backwards to the technology.” ~ Steve Jobs

Another mindset shift I struggled with at the beginning of my career transition was not building with users/customers in mind. As a techie, my first instinct and desire were to try out the newest technology and discover how I expand on its offerings. However, as a product manager, you constantly need to think about things from the perspective of your customers/users. If you don’t, your product’s value will be worth nothing because no one will want to use it. As Steve Jobs said in the quote above, we must start with the customer experience in mind and work backward to the technology; only then will we provide the utmost value to our users. Think UX 101.

A basic exercise you can do is to look at your everyday experience and find a problem you’d like to solve for yourself or your loved ones. Next, after you’ve identified the problem, list down as many things as you can about what the problem is and why it is an issue. This exercise trains you to shift perspectives and allows you to take your mind off of being a “problem solver” and instead take on the role of “critical thinker”.

3. You will have to communicate with people constantly.

Thirdly, you have to be comfortable with being the point of contact for your product. As a software engineer, you may have gotten used to getting requirements and having the head down time to code/build; however, as a product manager, you’ll find yourself in back-to-back-to-back meetings all day long and realize that the only time you have to tackle admin work might be on evenings or Fridays. Before you step into product management, you must ask yourself if this type of day-to-day activity is something you’d enjoy or at least tolerate.

Conclusion

In conclusion, understanding these key watchouts can help you transition from software engineering to product management more smoothly. Reframing your mindset can also help you locate a more worthwhile career. If you have any questions or queries, please feel free to leave them in the comments below. Wishing you the best with your transition!

P.S. If you’re currently interviewing for Product Manager roles, give this article a read (Top 5 Product Manager Interview Questions and what they mean)!