From an Software Engineer to a Technical Product Manager
Below is my story of such a move, role comparison and reflection on what went well and what didn’t.
The most popular way of becoming a Technical Product Manager is to upgrade from a Software Engineer role and naturally utilise strong technical background and this is exactly what I did 5 years ago. I wish it was perfect from the day one, but instead it was quite a bumpy road — I have been learning completely new craft, making mistakes and slowly growing my understanding of the role.
And since one can only understand challenges having the right context, I explain the differences (and commonalities) of two roles as they were appearing during my career path. If you are interested only in a bare comparison feel free to just skim through highlighted sections. Enjoy!
Product-aware engineering
Very quickly after finishing my PhD in Computer Science (it was about ocean-atmosphere modelling on supercomputers) I realised I am not a scientist at my heart. Science work requires one to go immensely deep into a single topic and after few years come up with a micro improvement within a very specific field. No doubt, exactly these micro steps drive human evolution, but I always felt better with developing multiple projects at once, connecting them into areas, explaining it to colleagues in a simple language, in other words — with breadth, not depth.
Funny enough, that period taught me that one doesn’t have to love the job to properly do it (which is a bit scary to be honest), but at some point I decided to at least change a field and become a developer in IT company whose product I like or would like to contribute to. So I sent a CV to Google, Booking.com, SpaceX, Uber, Yandex and long story short, Google turned me down, SpaceX doesn’t accept non-US citizens, Uber was hiring a Seniors only so I ended up choosing between the biggest Russian IT-giant Yandex and Booking.com and the latter won.
Looking back at that period, I realise my role was not a canonical scientific development as I had been actually creating my own agenda (what part of the system to improve, what functionality to which client to build) and heavily invested into visualisation and documentation aspects of my “product”. Desire not only to build what my scientific director advised me, but actually come up with new “features” and go extra mile presenting and ensuring various parties understand what I was doing were the first signs of PM-ing.
When a developer tries to be a PM
So I started as a Software Engineer at the big IT company with zero industry experience. After the onboarding period and a year of some growth in the role I realised that I even though I really like the company product (travel), I still have a little opportunity to influence it.
As a developer I was naturally focusing on the in-depth details of few very concrete backend features, without too much of a possibility to change things on the wider scene — just because I had nor time (I was coding) nor overall picture (it was a PM’s job). Surely next engineering careers levels (seniors and principals) had much more breadth in their work, but I wanted not only to solve business problems — I also wanted to define them.
So I started to seek opportunities to step into PM shoes somewhere and see if it fits me. Thanks to the fortune, a few months later I was assigned to a cross-department Machine Learning project with multiple parties involved: business teams were providing feature collection logic, infra folks were building a learn-predict backend and my contribution was to connect them with a real-time prediction adapter.
We were 4 developers in the room when I realised that each one of us has his own disjoint scope and no one oversees the full picture and steps to take towards the launch. So I felt someone has to try and started drawing high-level steps on a whiteboard, align who does what and after a few meetings became a developer with a bit of (clumsy) product addition. My official PM was happy, because he was not technical and all of this system connection didn’t sound interesting to him anyway.
This small project made me confused: from one perspective I was enjoying driving it, from another — not to extent of giving up all my tech knowledge and become a classical pure-business PM. This is how I started to think about a mixed role which didn’t exist in the company back then — about role of a Technical Product Manager.
Without waiting for new fortune gifts, I started to look around and after around 20 coffee chats with various product leaders and an interview I was invited to an experimental position of an Infrastructure PM.
PM is expected to lead
I still remember during my first day in the role one of the developers in my team said: “So Vladimir, you probably know what we should do next?”. It was just teasing, but I suddenly realised that jokes aside now I am expected to know where the team should aim towards. I had no idea actually, as so far I always had been expecting someone (usually PM) to have a plan.
Up until then there always was a long list of stories in the backlog and it looked like as our PM built a very clear high-way into a bright future of our product and all we needed as a tech team was just to work hard to progress along this path. First days of being a PM made me understand that now I am expected to build such a “road” and deal with uncertainty and a real possibility make a wrong turn.
So I was confused again: how would I tell my team where are we going? Luckily I had a great manager. To start with, he recommended finding clients of my product and understanding what they need from us (to this day it is still one of the simplest and most powerful pieces of advice I received during my career). With time I built a solid understanding what my clients need which after some analysis and crunching forms all the horizons of the PM work: from sprint plannings to the long term vision.
Tech PM role is all about breadth: who are your 20–30 clients, what they already want from you or what are their plans so you can “advice” what they “should” want, who are your dependencies, what are the ideas of your own team, of your leadership team, what are the company objectives and then also “Tech PM” addition: how is your product tech health: reliability, monitoring, security, testability and other non-functional requirements doing. As you probably noticed, it is easily a full-time job.
Please note, that here I am talking about single product breadth and for even wider cross-product cross-department breadth there is a Technical Program Manager role (i explain the difference in this article).
Conflict of “what/why” and “how”
Another lesson I learned as a “recent” developer was about crossing the line between What+Why and How.
In well functioning teams PM is in charge of what team does and why it is important (because they keep in their head business directions, client requirements, restrictions of dependencies, context, etc). Of course, great developers can (and should) contribute this part (by proposing features or even shape the vision), but at the very end the PM is accountable for results. In opposite, when it comes to “how-s” of implementation (architecture, framework choice, data flows, stability, etc.), development team should shine.
During the first months in my new role we had few subsequent outages and I felt I should do something about it and drew on the whiteboard a “solution” I thought was a smart way to go. It didn’t come across very well and gave me a great lesson — PM can (and should) prioritise particular work (in this case — reliability), set clear goals (e.g. fallback mechanisms to guarantee SLOs), but how exactly will it be achieved (e.g. by having database replication, traffic analysis and corresponding routing mechanism) is totally up to the development team.
With time I noticed that (surprisingly) it is tempting to immediately jump to proposing solutions rather than to make a step back and define the problem/goals and let the team decide the rest. Even experienced PMs sometimes make this mistake, so recently-a-developer PMs should be especially cautious in similar situations.
Even though the PM should not define the solution, they can still challenge team propositions, because at the end one more brain just makes any idea more solid. But how deep should the PM should dive? This brings me to the last point.
Technicality bonus
Luckily, the transition from an Engineer to the PM role is not only about obstacles, there is actually one “free” addition — an understanding of tech.
Since everything is a service these days, technicality allows a PM to feel the product much deeper, notice and nurture technical insights and challenge the solution at more advanced levels than expected from a classical business person. Obviously it should not come at the cost of a PM craft, but combination of the high-level picture with a bit of tech understanding can go a long way with a product success.
For example, as a tech-y PM one will be able to see that three completely different UI products can be powered with the same service (which saves a lot of work) or that exposing API to the external world involves security and reliability work (so this work should be planned). Moreover, on a team scale Tech PM is much more effective in any development conversations as they don’t need a “translator” in-between. You can find some real industry tech product examples and what Tech PM can do with them in the Udemy course.
As usual, there is a limit to PM’s ability going into details though as no one can properly combine both depth and breadth, so this level should fluctuate to balance business and tech parts depending on a product scope, for example:
- It is be just nice to know a bit about API terms for a PM owning a user experience for a video streaming platform, as they have to probably interact with internal systems a lot
- It will be important to know API specifics for a PM whose product is exposed via API (e.g. Facebook messaging functionality)
- And finally, Tech PM must be an API guru if the product is an API gateway itself (e.g. Uber’s one)
In general, technical skills make PMs much more useful for less “intuitive” products (e.g. Google search, Spotify music streaming, EasyJet booking engine, Amazon service monitoring, Stripe API framework and so on), that’s why there is a whole Technical Product Manager role rapidly gaining popularity.
I personally worked in three different areas (Infrastructure services, Business services and FinTech) and everywhere was able to find a product where utilisation of both technical and business skills was most effective for project success and at the same time — for my own satisfaction.
Summary
It was my story about transition from a pure technical Engineering role to the Tech Product Management space. It started with a shy attempt of PM-ing one part of one project and with time changed depth to breadth, clarity to uncertainty and “how” to “what/why”. Needless to say, so far I am enjoying it a lot and now have the pleasure of leading a mixed team of PMs and Tech PMs.
I hope it was useful. In the next articles I would like to cover Tech PM hiring aspects and walk you through a detailed example of a Tech Product use case. See you soon.
