Having worked as a Technical Product Manager (TPM) from 2017 to 2024 I can tell you first hand that the TPM is one of the most misunderstood roles ever created. I moved into the role after many years as an unfulfilled software engineer - why? Because I saw so many disastrous software projects in the area of internal tooling (e.g. build systems, cloud platforms) that I thought to myself “There must be a better way?“.
When I first came across the platform-as-product philosophy championed by people like Thoughtworks around 2017 it immediately resonated. Finally an approach that could help our industry avoid so many project failures. Taking ideas from product management and applying them to internal platforms made a lot of sense to me: these were complex products, with users and stakeholders with differing needs, lots of constraints, and no “right answer” to most decisions.
These internal platforms needed leaders who understood the platform-as-product mindset and, given that no roles existed that quite embodied what was needed, a new one was born: The Technical Product Manager.
I excitedly jumped at the chance of becoming one, spending the following years of my career deeply immersed in product management ideas, and trying to apply them to internal platforms.
Yet what followed was disaster after disaster. A full post-mortem will have to wait, but after many years of reflection I believe one of the major contributors to my failure in to fulfil this role is
I took me most of that time to realise why the role was so misunderstood and thus so difficult to successfully fulfil.
Why? There is much to say on the topic, but I would argue much of the confusion can be traced back to the name itself: Technical Product Manager
TPM first came to prominence during the rise of the platform-as-product philosophy championed by people like Thoughtworks around 2017 to 2019.
While you might expect Thought Works and other software consultancies to be experts at naming in this case they weren’t. From the perspective of the software people, taking ideas from Product Management and applying them to internal platforms made a lot of sense: these were complex products, with users and stakeholders with differing needs, lots of constraints, and no “right answer” to most decisions. They needed a mindset that could iterate and experiment to discover the right solutions for these internal customers.
But the role needed a distinct title to differentiate it from the actual product managers who already existed with companies, working on the revenue generating products. Something to make it clear these new product managers would work on other “stuff” i.e. the tools used by internal users and developers.
I’m sure companies experimented with a lot of titles but the one that ended up sticking was ‘technical’ product manager. I mean, why not? They work on “technical” stuff. Stuff those existing PMs don’t need to know about. Stuff that goes on behind the scenes. The technical stuff.
The only problem is: fast forward many years and its become abundantly clear that the word technical is much much too ambiguous. If you search for TPM roles on LinkedIn you will find a complete circus of roles that often have very little to do with each other, and many unrelated to platforms.
Sure some will be for platforms and internal tools, but just as many will be people looking for a “technical” PM i.e. one who understands technology. Because er, they have a software product with an API and after years of hiring PMs who graduated from business school without the foggiest idea what an API was, they realised they needed someone who did. Someone “technical”. You see where this is going?
Then another company, who never go the memo on vertically aligned teams, decided that there was too much work for one PM when it came to talking to developers. Besides, all those pesky developer kept on asking and arguing about too many “technical” things. Things their existing PM didn’t understand, or simply didn’t have the time to deal with. So, I know! Let’s create another role who can help the PM out dealing with all those developers. And let’s call it a TPM, cause they need to be technically minded. And thus your horizontally organisation expands, and productivity crashes and burns in a sea of handovers. But I digress.
So what should TPM have been called all those years back to avoid all this confusion?
You might think the answer is Platform Product Manager (PPM). Not a bad. Better than TPM. But guess what? Nobody understands what a platform is either!!
The simplest and most accurate job title would have been Tool Product Managers (TPM). Because everybody understands what a tool is. If your business bakes bread, then bread is your product. The ovens that bake your bread is a tool. If, for some crazy reason, you decide that the market doesn’t supply ovens that are good enough for your bakery you might want to hire yourself a Product Manager to design you a new one. And that would be a Tool Product Manager.
Hopefully the bread and oven analogy is clear to everyone from the age of 5 and upwards. People have a good grasp of what tools are and ,within a business, having clarity on what is your product and what is simply a tool that helps make your product is absolutely vital.
Yes tools are “technicalities” with respect to products i.e. they are behind the scenes. This meaning of the work technical is correct, but unfortunately it’s not widely understood and is highly ambiguous.
So in summary: stop using the Technical Product Manager job title. IF1 you genuinely want to hire someone to product manage your internal tools, call them a Tool Product Managers (extra benefit: you can keep the acronym). Part of me wants to suggest you just drop the “Product” part and simply call them Tool Managers but I fear that expectation of product management skillset might then get lost…
Footnotes
-
This is a very big IF. More to come on this topic, but IMO very few companies are doing anything novel enough to require a dedicated TPM for their software engineering tools. Arguably the bigger opportunity for tool PMs are on with the internal business process tooling such as onboarding. ↩