8 Lessons Learnt Transitioning from an Engineer to a Product Manager
After many years of being a PHP developer, I transitioned into a Product Manager role for the same product that I was engineering on. This was a career change I had desired for a couple of years and I was happy I was given the opportunity.
After being a product manager for more than a year on a large product to manage for a junior product manager to manage alone, there are a few lessons I took away from the experience. So to help out any engineers hoping to make the transition to becoming a product manager, here are some lessons I hope will help when you make the transition.
1. Dealing with so many stakeholders
When I was a developer, I would only be dealing with my product manager, developers or the QA tester. There would be times I would have to liaise with third parties in regards to API, but that was the extent of who I had to deal with.
As a PM, not only did I have to work closely with my team and get the team to work like a well-oiled engine, but all of a sudden I had to deal with so many other people in the company I had never spoken to. This extensive list of people included senior executives, customer support team, legal team, finance team and so on.
Though it was a shock, I loved dealing with all the different stakeholders. I got a better sense of the ecosystem that surrounded the product and how so many people depend on the single product I managed. Trying to juggle the many different needs with a finite amount of time and resources is a constant challenge, but it is a skill worth learning and honing because it helps with the next point.
2. Always remember the bigger picture
When you are starting as a product manager, you will receive a lot of requests from different people and teams. They will ask for help with certain requests or ask whether the team can build a feature that will help them.
It may seem easy to say “YES” to everyone, and work on fulfilling every request. However, the time you spend trying to fix every short-term problem will leave you no time to think of the roadmap and the long-term goals on it. I’ve learned that you can’t fix everything, so pick your battles carefully. Make sure it aligns with the long-term vision for the product, and pick the battles that will your product stands the gain the most out of.
I learned that I can’t help everyone, so I had to work on my prioritisation skills. I had to manage people’s expectations and sometimes convey bad news to them in a digestible manner. The goal being is that everyone leaves the negotiations at least satisfied with the outcomes.
3. Your technical background gives you an edge over non-technical PMs
Having a history of being an engineer, you are well aware of the challenges developers face all the time. You can communicate to stakeholders when a feature would be done with a realistic timeline. The engineers are happier to talk to you as they don’t have to dumb down what they need to say to you.
Another advantage of being an ex-engineer is that you aren’t 100% reliant on your team to gather the information you need to scope out and plan work. Whether it’s querying the database, reading third-party API documents and checking pull requests, there are skills you have learned which you will carry with you as a PM.
Combining your technical knowledge with your continued growth to be a PM, come a few years you’ll be a well-rounded PM, and will bring a lot of value to any company that you join.
4. Making critical decisions
As a developer, you are used to having someone else making the decisions for you on what you are doing next. However as a PM, it was a weird sensation for me to have many people asking me what is next things they need to do or having the make a final decision on issues that impact the product and the team.
It can be an odd feeling, but you’ll learn you have to be aside any doubt, get some confidence, and start making decisions that’ll affect the product, the team or both. Even the smallest decision of what task should someone do will have an incredible impact on the delivery of a feature of the product.
5. Learn to delegate tasks to other team members
One of the strangest feelings I had to learn to get used to was telling other people what to do. As a developer, I would either be working diligently alone on my tasks or helping other people who needed my help.
When I became a product manager, I learned that there were so many things that needed to be done and I couldn’t do all of it by myself. So to prevent me from perpetually working overtime every day, I needed to start delegating work to others and trusting them they could do the job well. Coordinating efforts between many people to achieve a single goal is an art, and the ability to ask others for help in a cordial manner makes the task easier and keeps the work environment happier.
6. Sell Yourself More
My team had finished building a feature that helped the company recover about $2K a week. During my weekly meeting with the high-level executives, I casually mentioned the team deployed said feature and we saved ‘X’ amount of money and then moved on to the next topic. Later on, one of my mentors who was in the meeting criticised me for the way I reported this news.
For a feature that saved the company so much money, I should have boasted about how much money we’re saving or how great the team was in getting this feature done. Not making a big deal about this new release made me come across as not caring enough about the product and I didn’t have my eye on the future but telling the stakeholders what were the next steps were.
People have so many things going on in their lives and are preoccupied with their matters. To cut across the noise and get people’s attention, you need to be an ultra evangelist for your product and give updates to your stakeholders on new developments. Doing this shows you are passionate about the product and that you are on top of the work.
7. Check your ego at the door
Before becoming a PM, I always prided myself on never yelling at any colleagues and always being understanding when someone was speaking to me. This was a skill that proved useful for me as a Product Manager.
Every day, there is always someone who challenges something you have done. For example:
- Questioning why you’ve written a task description a certain way
- Encountering a bug and they think it is your problem to fix
- Suggesting changes to processes that you have implemented
Having a constant stream of complaints and suggestions day in and day out can start to feel like you are being personally attacked, and have an urge to retaliate with a negative attitude. I take a breath and think about where people are coming from. I always try to remember everyone is trying to make things better and I should take their feedback to improve things across the board. The team is more than just me, and that for the team and product to be successful, we need everyone’s input.
The other benefit of listening intently to other people talk is that it’ll help improve people’s attitude and perception of yourself, and they’ll want to keep working with you more in the future. Working for someone who respects your opinions and ideas makes for a happy workplace.
8. Find a good mentor
The path on how I became a Product Manager is something I wouldn’t recommend for people wanting to transition to a Product Manager role.
I got fast-tracked to a Product Manager role after working part-time as an Associate Product Manager for only two months. To give more context on how it was a bad decision this was, I was solely in charge of a product that was the same size as another product in the same company that had three different product managers working on it.
Without the proper experience of working under a senior product manager, I was thrown into the fire and was making so many mistakes, and a few times made the CEO mad. A senior PM would have shown me the ropes on best practices as a PM. The senior PM would have shielded me away from the negatives of being a PM. After a while, they decided the product I was working on was too big for one person, so they decided to hire a senior product manager, and I reverted to my rightful place as an associate product manager.
Though I did learn many lessons running the ship alone, I wholeheartedly recommend learning the ropes from a mentor, asking many questions as possible and plying your trade. Then the day you are ready to enter the PM arena alone, you will be ready.
Hopefully you found this article useful for anyone wanting to be a product manager, and I recommend it. The idea to be one is the first step, and you’ll do a great job.