Broadly speaking, the responsibilities of a tech PM are in-line with a non-tech PM. As a PM, in general, your responsibility is to define the “what” and “why” of a problem statement, and work alongside your internal stakeholders to define the “how” and “when” of the solution.
The difference between the two roles lies in the execution and stakeholder management. While you’re not required to read or write code as a tech PM, you’re expected to define the details of technical feature specifications, navigate tradeoff decisions on engineering choices and unblock engineering teams by defining clear acceptance criterias.
To do this well, you need to have a clear understanding of the fundamentals of the engineering system design and technical architecture of the product. This applies not just to non-tech PMs transitioning to tech, but also to the tech PMs transitioning from one field to another.
For example, when I transitioned from cloud computing to machine learning (ML) as tech PM at AWS, I had to invest significant time and effort into understanding the key concepts and techniques involved in ML and natural language processing.
From my experience, here is an effective framework that will smoothen your transition into a new role as a tech PM:
Shadowing is often used as a technique to onboard new hires to a specific role in an organization. In my experience, shadowing has worked as an effective way to learn and acquire new skills that are more complex in nature, such as API design and ML development. Shadowing involves attending meetings where you can observe engineering discussions, trade off conversations, spring planning, feature breakdown and prioritization discussions. Shadowing should be non-obstructive i.e. you shouldn’t slow down the progress of the team. You should take rigorous notes and follow up with teams on your questions, preferably asynchronously.
Good engineering teams are disciplined about maintaining a detailed repository of internal documentation for engineering designs and technical architecture of the product. This documentation acts as a great resource for PMs to learn about the fundamentals of engineering concepts and the PMs must take full advantage of it. In addition to the technical documentation, PMs should also ask for access to all the relevant product requirement documents and feature definitions from the previous launches, when available.
The self-learning approach is a great way for PMs to accelerate their skill-set expansion and career growth. When I transitioned to ML as tech PM, I benefited a lot from the ML course collection by Andrew Ng on Coursera. I highly suggest finding targeted and self-paced courses that are aligned with your learning goals and are within your budget. Coursera and Udacity are my personal favorites when it comes to MOOC platforms, but there are a lot of open online courses available on a diverse range of technical topics. I’ve listed some of the most popular tech courses in the appendix below.
In summary, great tech PMs excel at defining the details of technical feature specifications, navigating tradeoff decisions on engineering choices and unblocking engineering teams by defining clear acceptance criterias.
The journey of transitioning to tech PM can be smoothened by following the best practices of i) shadowing your engineering teams and observing their discussions in a non-obstructive way, ii) diving deep into the engineering and technical documentation and asking questions asynchronous, and iii) self-learning approach via self-faced and targeted courses that are aligned with your learning goals.