Technically Speaking…
Many have written that being technical in product management is not about knowing how to write code, but about enabling more effective collaboration between engineering and other stakeholder teams. This is true, but it’s a shallow heuristic. Mostly because it’s often communicated with a lesson for PMs to just get out of the way. But it’s not about getting out of the way; it’s about having discernment about when to get out of the way, and perhaps, when to get in the way — trust but verify.
When talking about product leaders, Marty Cagan puts forth that product leaders are specifically people managers. Of course, leadership is a key skill for any product manager, but this delineation provides helpful guidance on what we usually mean when we say someone is a “product leader.”
We can take a similar approach when discussing PMs being technical:
On the one hand, we have PMs supporting the development of technical products. These are usually products leveraged by internal users or by technical external users, such as developers. Think APIs, technical platforms, databases, DevOps, etc. PMs leading product teams that develop such products are Technical Product Managers (TPMs). At the end of the day, though, titles are about career positioning more than the brass tacks of doing the job.
Separately, any PM may have technical skills that equip them to enable more efficient collaboration throughout the product development lifecycle. Here, “technical” indicates a specific branch of knowledge that is best demonstrated through a PM’s communication skills. For example, a technical PM may know the difference between HTML attributes, HTML properties, and CSS classes; targeting each of these in a technical implementation involves different tradeoffs, and a technical PM can drive discussions of these tradeoffs more efficiently than a non-technical PM.
A TPM is not necessarily technical and vice versa. In other words, technical with a capital “T” should indicate the types of products a PM supports, not their level of technical skill. And technical, with a lowercase “t,” is something all PMs could benefit from becoming.
When I was breaking into PM, I was bullish on becoming technical because I could see then, as I do now, where technology is headed: products increasingly require complex technical builds that often leverage both user and business data. AI expectations (though not necessarily AI itself) are driving us toward this complexity even more rapidly. To remain competitive and stay in-market, PMs without technical skills need to develop them yesterday. If you’ve already got some, it’s time to deepen them. The line is only going to keep moving.
Today, there are few technical decisions that are truly separate from product decisions. PMs that understand this (and can convince engineers of this) will be the most successful at driving outcomes, impact, and value. In other words, we need to use our technical skills to build trust with engineers and bring them more into the PM space, not to go deeper into the engineering space (even if you’re like me and love it in there 🤓).