Back to resources

Making the Leap from Being a Developer to a Product Manager

Personal Growth
Career Path

27 May, 2021

Sinduja Ramanujam

Sinduja Ramanujam

Sr Product Manager at Microsoft

Sinduja Ramanujam, Senior Product Manager at Microsoft, shares her experience pivoting 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

A Day in the Life of a Product Lead in FinTech – A Series

31 January

Discover the daily struggles, challenges, and moments of delight encountered when delivering banking products around the world. I will share my story candidly and honestly, without filter as much as I am allowed, and offer insights into my approach while providing retrospectives of the results.

Strategy
Embracing Failures
Cultural Differences
Career Path
Loussaief Fayssal

Loussaief Fayssal

Director of CX at FLF PRODUCT DESIGN

Ten quotes from Adam Grant relevant while dealing with layoff

27 January

Layoffs are tough. Dealing with situation we go through different emotions. First is disbelief, followed by anger, leading to frustration and finally accepting the news. Following quotes seemed relevant to review and again a perspective as we pass through hard times

Career Path
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

I was passed for Promotion. What now ?

26 January

Passing for promotion happens to everyone in their career lifespan. If someone does not had to go through the situation, consider them they are unique and blessed. Managing disappointment and handling situations in professional setting when things don’t pan out, is an important life skill.

Changing A Company
Handling Promotion
Feelings Aside
Feedback
Coaching / Training / Mentorship
Fairness
Career Path
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

15 Tips to improve profile discovery on LI

20 January

Recently, I have read the book ‘Linked’ from Omar Garriott and Jeremy Schifeling on audible. The audio book is 7 hours long. If you dont’ have time or need a brief summary, read on

Hiring
Changing Company
Career Path
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

The art of Happiness

20 January

Happiness is a choice. Our upbringing and the surroundings have made it conditional. The first step is to get over the hump is self-awareness. Self-awareness is a journey by itself. The ability to identify what we can control, and we can’t is important.

Personal Growth
Career Path
Health / Stress / Burn-Out
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan