How technical does a Product Manager need to be?
I see this question come up a lot in the product management community, particularly from PMs who have moved from “non technical” roles like sales or marketing into web teams, and even my own PM colleagues who I’ve worked with over the years. There is some great literature out there on what is a technical PM and how to get to “technical enough”, which I avidly sought out in the early days of my transition into a technical PM role. However, theory aside, in this post I want to share my own personal journey and the measures of success I used to gauge how I was doing.
When transitioning into a technical role, there can be a whole range of expectations you feel you need to live up to: for me it came in the form of feedback from engineers, requests for explanations around how systems work from non-Web based stakeholders, and my internal “chimp” that told me I should be doing x,y and z. This led to a sometimes overwhelming feeling of “imposter syndrome” — I was in this role but I didn’t really know what I was doing!
My approach to mitigate this was to seek some objectivity by asking a few trusted people what their expectations of me were. Their answers provided helpful guides on what level of understanding I needed to get to, but didn’t provide concrete direction in tackling the problem of how to become technical enough.
So early on I thought a measure of success would be I can code. I mean, that’s what “technical” means — right? I invested personal development time in learning different programming languages and solving simple problems posed by the free courses on Codecademy and Udacity (I built my own website and solved maths problems in Python) but I realised that to get really good at those skills would require many hours of practice. I came to realise that as a PM the value of my contribution to the team’s goals is not in the realms of actually building the product but in shaping its development against a strategy.
What these courses did give me though, was a foundation upon which to base further learning and support me immediately as a technical PM:
A basic vocabulary of technical terms and their definitions — beyond just what I could pick up through discussing the pertinent issues with the team;
Practical experience in using the building blocks of programming, such as if/else statements, functions, loops and variables;
Knowledge of how to approach decomposing coding problems — referred to as “programmatical thinking” or “debugging”;
The theory of how computers and the internet works (e.g. client-server differences and interactions, how computers communicate over the internet via protocols);
Perhaps most important of all, it helped me to develop an empathy for how engineers work every day, which enabled me to build stronger relationships with my team.
Once I had a broad, basic understanding of computer science, I could start to narrow down into specific domain knowledge that would support me better in my role. I identified what was important to know about by understanding the context that we were operating in. A platform product typically comprises APIs, micro-services and data-driven architecture — which is still pretty broad! I recognised I had to pick one area to start with, and as it seemed fundamental I chose APIs: from online research to reading about the theory of good API design, this learning helped me to develop a good first “point of reference” — what is an API (“what does API even stand for?!”) and what characteristics different types may have.
Which brings me to the first actual measure of success: having knowledge of key technical concepts in my domain.
I started to use my newly acquired language in day to day conversation with engineers, who were only too happy to answer my “dumb” questions to help consolidate my knowledge further. As a result of this, I naturally progressed to learn about microservices — what they are and what they do, which gave me another point of reference. From this I developed an understanding of their relationship to one another — the dots started to connect and my knowledge around system architecture expanded.
A way to test my knowledge and confidence in this area was to present or teach it back to others — and I had several opportunities to do so. I ran a session with my fellow PMs on our new architectural approach using microservices, followed by another on “tech for non techies”, which involved lots of drawing network diagrams on a whiteboard!
The second measure of success I realised was to become data literate. That’s a critical skill for any PM, but for technical products, I determined this wasn’t about interpreting web metrics in tools such as Google Analytics or reviewing split test performance, but about understanding system performance and how this can be measured through a variety of tools.
Around the same time as I transitioned into technical PM, the company I worked for started experimenting with SumoLogic as a tool to log requests and responses sent via our APIs, and set up alerting and dashboards to manage performance. SumoLogic has its own query language, and I learnt enough to self serve some basic queries (the coding practice came in handy here!) Again, the knowledge was consolidated by demoing to the other PMs the use cases where this tool could be applied, which was a springboard for a more thorough discussion around the tools we use to monitor system performance as an organisation (we also had Grafana, Pingdom and Zabbix — and each had its place).
What this enabled me to do was 1) provide a higher level of service to our internal customers — making performance data visible is highly valued in organisations — and 2) evaluate how big a problem is to decide on its relative priority for fixing. Working a lot with third parties, the data I could query on integration performance allowed me to proactively initiate conversations where I saw issues arising — sometimes we knew something was wrong before the supplier did!
The third measure of success is the one I personally struggled with the most: be an active participant in tech discussions, mainly as I felt without some basic technical knowledge I did not know what questions to ask, and I lacked confidence to even try. To remedy this I sat in on every technical meeting happening (I still do!), and consumed as much knowledge as I could from the discussion. I asked questions where I was unsure (possibly at the expense of being a nuisance — but my team bore it well), and I definitely took more than I gave in terms of contribution of knowledge on the solution.
To get better in this area I worked closely with my lead engineer and the Technology Director to improve my understanding of the overall vision for the architecture and integrations capability — that was what we were aiming for in the longer term, so it was a key point of reference. I encouraged the use of diagrams to teach me concepts — I have notebooks filled with boxes linked by arrows! We had regular catch ups to run through what we had been working on, what was coming up and linking it back to the overall tech strategy. It was this “little but often” approach that helped build up my knowledge.
At some point the balance started to switch — the tell tale signs were:
Talking with confidence about technical issues — such as [a] not double checking myself after I used a technical word [b] articulating technical implementations to third party tech teams and [c] explaining how our systems work to new engineers;
Challenging proposed technical solutions, particularly where I felt there was a disconnect between the problem and the solution, or the solution and the wider tech strategy;
Asking the “right” questions to help the team determine the optimum solution and build consensus around this with technical stakeholders;
Feeling confident to make strategic product decisions, and that these were endorsed by the team and the Technology Director.
By no means is this journey “done”. I started on the technical PM track more than six years ago and I am still learning new things every day, but having the points of reference in place means I am finding it easier to “slot” new information in and understand the relationship and context. My advice to those making the transition is to keep asking questions, keep open minded and keep learning.
