Making the Leap from Being a Developer to a Product Manager

Problem

After spending some time as a Developer, there came a moment in my career where I realized that I wanted to be a PM. I wanted to look at the big picture, and to have an eagle’s eye view on the end-to-end journey of the customer - identifying problems and finding solutions. How do you measure success? This realization was probably the pivotal point.

I think that everybody - Developer, PM, it doesn’t matter - should have a customer mindset. At the time, I felt like I was missing some sense of that bigger picture. I wanted to take ownership of the roadmap, to have some say in the features to include in a product, to really think about why we should be building something, and to be validated by the needs of the customer, through interactions or experiments, whatever it would take.

I was a Developer for nearly three and a half years before becoming a PM really occurred to me. You’re trained to think like a Developer from day one; you’re looking at code every single day, the reviews, the architectural standpoint, things like that.

Product Management six years ago was nothing like it is now. I did not have the resources that professionals making the switch are able to train themselves with today. I wanted to do one of two things: to get into a lead role that involved decision-making, or to get into a PM role, operating from the viewpoint of the customer as opposed to the technical standpoint that I was used to.

Actions taken

I did not necessarily want to be handed something to work on, thinking about things strictly from an algorithmic standpoint. This was the opposite side of the coin that I was used to - trying to come up with the feature, not thinking about how exactly the problem would be solved from a technical standpoint. Making this connection was really the “Aha!” moment.

Pivoting to being a PM involved a very different mindset; I had to broaden myself. Suddenly, I had to be thinking about what the competition was doing, to develop an external view. I need to consider the global maxima and apply this insight to local problems.

While still at Intel, I began to take on a PM role gradually - there was no carved-out path to follow, per se. Thankfully, my manager was very supportive. He was able to give me some visibility as to the processes that were happening on his side of things, allowing me to join him when making customer visits and giving me a chance to talk with the customers directly. I saw first-hand what being a PM entailed. It was very exciting. I realized that this was what I actually wanted to do. I was able to prepare myself for the transition.

I also sought the advice of my other mentors, at Microsoft and elsewhere, as well as peer PMs. I learned the differences between this new type of role and the ones that I had experience in previously. For the first few months, I was still looking at code, and one of my managers had to tell me to step away because it was not a part of my job anymore.

Lessons learned

• Through this network, I was able to gain an understanding of the different tools and methodologies that I would need to implement as a Product Manager - becoming more agile in my approach, where, before, I was much more used to working in a waterfall-style relationship. All of that was new back then for me.
• I also needed to familiarize myself with the new types of stakeholders that I was going to be involved with. When working as a Developer, it’s you, your technical lead or manager, and the algorithm that you want to apply to the task at hand. You gain their approval or they direct you elsewhere. This type of relationship is easy because it involves very few people. As a PM, I found myself in conversation with designers, marketing, Engineers, user researchers, all of these people who are involved in making the final decision. Being cognizant of the language that they spoke and understanding what they were talking about, and, at the same time, taking that feedback and coming up with a Product roadmap or a feature plan that translates that understanding into something that we can deliver to our audience, those were a few key things that I was able to take with me.
• As a PM, you really are leading without influence. You need to develop a voice that influences the Developers working on the problem in front of you. I was very new, and not many people were stepping into the role of Product Management at the time. It was very exciting for me. I needed to find a way to be taken seriously by others; I made it my mission to understand the technology and the architecture, the back-end APIs that were being called, all the good stuff.
• My technical background helped me a lot. Connecting the dots on behalf of the users was easy for me because I knew how the code was working. The new lessons came from the front-end - learning how to talk to the designers and learning what a process looks like from the outside. What did the customers want? Building these muscles was integral. Teasing out a problematic pattern in whatever way possible - looking at the customer tickets, for example - shows you what users are trying to do, but are not able to do, for one reason or another. This is the “what”; my goal was to eventually find the “why” by drawing conclusions between the data and the problem to be solved.