Well, for starters - curious me would ask you what do you mean by “succeed”? As that means something different for everyone! To focus my answer, I am going to go ahead and assume that you mean you want to have a good reputation and consistent access to exciting job opportunities within your company. Or in other words, be labeled a "high performer".

I’ve seen that the path to achieving this definition of success is fairly similar across many strategic roles, and comprises 3 parts. You should be able to:

1. Influence & communicate effectively
2. Innovate to improve upon business metrics
3. Execute high quality work

Now, looking at this list - the technical aspect of a PM role becomes relevant largely in point three. I’m highlighting this, as simply stating that having a technical background only affects 1/3 of your “recipe for success” should allow you to breathe a little bit easier!

This is still an important third of success, of course, so let’s take a moment to think about how a non-technical PM can mitigate any fallout from not understanding code as well as a technical PM. I was a non-technical PM, and I felt understanding code would have impacted me in 2 main areas. It would have allowed me to:

• more easily give ideas to my team what to do from a solution-ing perspective
• better speak to complexity of potential solutions to stakeholders (before consulting the dev team)

On the first point, I actually felt this became a strength of mine. Developers, of course, do not need to be (overly) told what to do! They are often the most creative and innovative team members, in fact. So instead of giving solutions, I got really good at drawing that creativity & innovation out of the developers. I read up on how to facilitate collaborative sessions & asking curious questions (going so far as to take a 100+ hour coach training!). Being non-technical allowed the separation of roles to stay incredibly true, and for me to become a member of the team that not only achieved great results, but coached the engineers, researchers and designers I partnered with.

On the second point, I felt I really needed to ramp up here when I first became a PM. Because knowing how complex things were to build would affect quality, delivering to deadlines and communications to stakeholders. This is where I chose to invest in becoming more “technical”. I had our senior engineers walk me through the technical architecture of our stack, and asked “simple” questions to the developers regularly. I didn’t want to know exactly how things were built, but I did want to know the quirks of the tech stack. Where bugs popped up often. Where the team felt tech debt was rampant. Where we had robust flexibility and could easily slot new features in. I made sure my understanding was accurate, so I could easily translate this in business meetings. This again was a strength of mine in the end. Technical PM’s would not have taken the time to do this, most likely! I became the ultra prepared, super informed, and nimbly agile PM in senior leadership meetings.

Being a technical PM might feel easier (and less intimidating) at the start, but ultimately anyone who sets their mind to it can and will succeed in Product! So in summary, to set yourself up for success as a non-technical PM, I would recommend gaining the skills required to effectively coach your Product team and alongside gaining a thorough understanding of the quirks of your tech stack.

‍