Depending on the product, the term “technical product manager” might signify a wide range of tasks. Sometimes the product is an API, other times it’s a mobile SDK, sometimes it’s a JS library for web development, sometimes it’s an ML component in a larger product, and other times it’s platforms and tools for developers (like logging and monitoring tools, cloud infrastructure products from AWS/Google/Azure, etc.).
Many of those ought to be PM’d most likely by someone with firsthand personal experience that informs their intuition about how to cater to the particular clients/users of the product. For instance, since I’ve never used a tool like that to analyze application logs, I would not feel instantly at ease PM’ing the Splunk web UI. I could certainly catch up, but before I felt ready to function in that setting as a PM, I would need to gain some fresh experience.
As an example of what I mean by “gain some new experience,” I spent six months of evenings and weekends learning to program while maintaining a set of platform APIs for the cart and checkout in an e-commerce stack. To be clear, you don’t want me to write any code for you because I’m bad at programming. The ability to make sound “UX” decisions (on behalf of the engineers who required to use my APIs) and to have fruitful interactions with both my own engineering team and the engineers who used my product, however, improved dramatically.
I believe the following to be a decent minimum standard for most technical roles, and each of these is very beneficial in virtually any PM role as well:
HTTP (since pretty much every software is using it in some way for something) (because pretty much all software is using it in some capacity for something)
REST APIs (for instance, the ability to read API documentation to determine whether or how you could use an API to implement a particular feature in your product, or even manage an API as a product)
It can be really helpful to cut through ambiguity and make sure we’re all talking about the same thing by using data structures and dot notation (for example, being able to communicate with engineers like “If item.price.current price > 299.99, display the special return policy message” — way clearer for everyone than just saying “If the price…”).
Grasp of common design patterns, managing tradeoffs, etc. in large systems and web and native mobile applications. Although I don’t believe that product should be the driving force behind these choices, being able to easily communicate with engineering partners is really useful.
Knowing how to read and draw sequence diagrams well is quite beneficial; basic block diagrams are easier to understand but are still useful.
On all of the aforementioned, having at least some programming knowledge in the front-end and back-end is quite beneficial.
The most crucial factor, in my opinion, is a desire to embrace complexity rather than avoid it. You must be willing to participate in conversations you don’t fully understand, do your own research on the subject, seek the advice of intelligent people, etc., because nobody ever fully knows everything.
I look for two minimum requirements in the competency category when hiring a PM for a technical product (the other category is character, but that is not the topic here):
Some programming experience is required because certain technical concepts can’t be learned from reading blogs, watching YouTube videos, or talking to coworkers. Programming knowledge serves as a foundation for the CS concepts required to go extensively into certain technological issues.
Because it’s probably a fantasy to discover someone who already knows everything, they’ll ever need to know to be a good PM on a given product, you should have a natural interest and thirst for learning new things.
Although having more than those two is definitely preferable, with those two as a starting point, the rest of what is required should be quite simple to learn on the job.