How to transition from an engineer to a PM

A significant number of PMs come from a strong engineering background. The expertise in building products often leads the curiosity to explore the other side - why and what to build. At least, that's how it started for me. Inspired by a recent conversation with the PM community, I reflect on my journey from engineering to PM and share the experience with aspiring Product Managers. The content below is by no means step-by-step guidance. Instead, utilize it as a thought framework to evaluate your decision at each transition phase.

San Juan Island, WA

Understand why you want to be a product manager

What motivates you toward this new role? Suppose it's based on extrinsic motivators like the promise of a better work-life balance, a shinier title, or the opportunity of presenting a strategy to the leadership. In that case, it won't be enough. Remember that the transition is typically a lateral move, if not a step-down. When I transitioned in 2014, I became an IC PM instead of becoming the director of engineering. And it was not an easy decision (needles to say, I don't regret it a bit). 

So, the journey won't last long if you are motivated by what you will get. Instead, start with what you can offer. Understand who you are, what you like to do, and how you can serve better in the new role vs. your current one. This clarity is essential to prevent remorse later down the road. Here are some soft indicators that can validate your compatibility for a PM role:

• you love the problem space more than the solution

• you empathize with a specific community, persona, or demographic and explore ways to solve those

• you deeply care for the people around you

• you like to listen, process, and ask more

• you thrive in ambiguity

• diverse, even conflicting insights, excite you instead of overwhelming you

• you are curious about the products you use, where they shine, where they fail, and how what can improve them 

• you get a kick when your long-held premises are disrupted by new ones

If you answered yes to several of the questions above, then you might be headed in the right direction. I was in a startup when the desire for a PM role kindled me. Speaking to customers was easy and routine, even as an engineer. That got me curious. While architecting the new data access service, I enjoyed building a long-term roadmap, articulating why we needed it and how it would impact our customers. I also made a transition plan to help other services adopt this new pattern. I also enjoyed reading more about product strategy and tech strategy. The hints were obvious, so I started exploring more.

Avail your trusted circle

Once you are convinced that this is the role for you, you will need allies to give feedback and help you explore this opportunity further. Start with your manager/skip level. Transparency from the get-go will preserve the trust regardless of whether you pursue the new role or stay back in your dev role. Explain why you are exploring this role. Work with her to ensure you will deliver your existing commitments.

And most importantly, ask for ways how she can help you. This help could mean creating space between projects, introducing you to a PM, or connecting you with mentors outside the company. A conversation with your manager also grounds you in reality. Maybe the company doesn't need a new PM for the foreseeable future. Or, she's not supportive of this transition for whatever reason. In this case, you can pivot your strategy. Depending on the size and culture of the org, you can also start this exploration by leveraging your network within the company. Or, you can switch to a different team, org, or company based on your situation. You can also explore a part-time PM gig outside your current company. 

At one point, my manager, the then CTO of the startup, asked if I would be interested in a technical Product Manager role, which made it easy. He was my biggest ally during my transition.

Get your feet wet

Now that you have some clarity to explore this role further and have support from your network, seek opportunities to get your feet wet. The best way to do that is to explore options in your existing org. Here, you have already established trust with the team and the decision-makers. Plus, it's easier to test the waters while continuing your current job. Here are some ideas. 

Shadow a PM

Ask a fellow PM if he's interested in coaching you and if you can shadow him during meetings. It's essential to choose the right shadow PM. Confirm if this PM is good at what he does, likes his job, and manages a product/feature, not just a project. Otherwise, you will leave disillusioned or with a different perception of the role. If possible, shadow multiple PMs. This option is applicable if you have a functioning PM org. If that's not the case, seek opportunities outside your org or find an external mentor who can commit to meeting periodically to coach and mentor and walk you through real-world PM scenarios. 

PM your code

As a dev, you own a technical domain. Depending on your seniority, this could be a service, an API, a UX module, or an entire vertical of the tech stack. How would you drive it if you were the PM of this area? Who are the customers, what problem does this tech domain solve for them, and how does this help the business? And, how will you measure the success? Can you propose a prioritized list of features that will evolve your technical area?

If you can answer these questions, you have built a product strategy for your technical domain. Review this with the PM closest to that area and seek feedback. Run it by your peers, mentors, manager, or skip-level and see if the proposal resonates with them. Would they fund resources to build the features you proposed? If not, understand the reason, refine and re-share the proposal. This exercise will expose you to an essential facet of a PM role without leaving your day job. 

During my transition, I started PMing the feature I was building. A startup culture of trust and curiosity helped a lot in this case. Multitasking as a PM and a dev turned out harder than I had thought - almost like playing ping-pong with myself. But it was my only way; I learned a lot from this experience. 

Seek a pilot project

Now that you have a fair understanding of the role, apply the learning. Try to lead a minor feature, ideally from spec to launch. Seek a PM partner where you can find synergies. For example, a PM who's spread thin will be happy to take your help. Or, if a PM is trying to grow into a Group, PM can benefit from coaching you. Having synergies will make finding projects within your company and a sustained pilot easier. 

Volunteer to be a PM

If your org doesn't support you to test drive, there are plenty of opportunities outside. Volunteer for an org that needs some product love. It doesn't have to be a technical product. You have a product opportunity if you can articulate who the customer is and the problems they face that can be solved through the org's mission.

For example, I launched an online music competition for a non-profit music organization at the start of the pandemic. I started with a one-pager outlining how an online competition offered music students a platform to take their musical practice to the next level. I submitted a proposal to the board and articulated how it was aligned with the organization's mission. After having everyone onboard, I rallied the board members to deliver a successful competition for 200+ participants across North America. This event is now an integral part (a new product) of the org and a driver for increasing the memberships. 

Reassess the role-compatibility 

Along the process, journal your experiences, calling out what aspects you liked and didn't like—skills that came naturally to you vs. those where you struggled. For example, you enjoyed speaking to the customer, but you worked to compile the learnings in a digestible way. You were good at leading meetings but felt overwhelmed when people challenged your proposal. Track these details to help assess your long-term drive and compatibility for this role. 

Formalize the learning

By now, your heart has spoken. Becoming PM is your next career move. It's clear based on all the things you have done so far. 

If that's the case, it's time to notch up. You got a raw, first-hand experience of what it takes to be a PM. Now formalize this learning. This is where you learn frameworks and tools to apply the knowledge at scale. Familiarizing these concepts will also boost your confidence and earn the trust of your stakeholders, peer PMs, and customers. 

If you are a book person, a simple Google on "top books for product managers" will deliver a meaningful result-set. Look for curated lists like this to jump-start your reading. For audio-visual learners, YouTube has everything you need. 

I am not a big fan of certificates, but they offer certain benefits. A live course ensures dedicated time. Workshop-style courses allow you to apply your learning in real time and learn to collaborate with others. 

Smartly utilize the engineering mindset.

As an engineer, your strength is understanding the tech stack, the codebase, and developer jargon. It's easier to earn their trust. You can even compensate the team by offering technical solutions when needed. You can drive intelligent conversations during the planning and estimation process.

At the same time, watch for the pitfalls. First, you will need to let go of control. You will be tempted to solve a problem. Sometimes, you would micromanage an engineer without even realizing it. And this could be a major turn-off for your team.

When you are a hammer, the world is a nail to you. So, watch out for the solution trap. No matter how compelling a particular technology or a feature may seem, always validate by challenging your assumptions early on and incorporating copious feedback.

Set your first official role for the success

Now that you earned the trust of the decision-makers, spread the word about your desire and ability to transition to a PM role. If there are possibilities within your org, build a transition plan with your manager. I had worked out a 6-month plan where I gradually phased my responsibility as a dev as I onboarded full-time into product management. Also, seek opportunities outside. Ensure your first PM role offers you a chance to showcase impact, not deliver features. Envision your future resume. What would you like it to say? You grew the number of engaged users by 20%. Or you reduced the cost of operations to enable the engineers to work on other areas. Whatever it is, strive for clear outcomes and then work backward to build a plan toward it.

In closing, if you are a developer or an engineer curious about being a PM, you are in a great place. Start with a soul-search on why you want to be a PM. If you sense positive early indicators, move on by tapping into your network and driving a pilot project. Mid-way through the journey, formalize the learning and turn the nob to a full-time PM, ideally within the same company. Once you have a few product outcomes, you can explore the wild for more significant and broader roles. Lastly, use your engineering superpowers smartly by being mindful of the common pitfalls.