HOW TECHNICAL IS A TPM?

09 Jul 2021

Question:

As a TPM, how technical should I be?

Replace the “T”

I get asked this question a lot by newer TPMs, often coming from an engineering role. TPMs are really just PMs with strong technical backgrounds that build products for technical folks. But, at the end of the day we are PMs. This allows us to pivot the question:

As a PM, how well do I have to know my product’s domain?

At this point, it just kinda seems obvious, doesn’t it? You have to know it really really well. TPMs often are engineers first, so it’s difficult for us to think of ourselves now as product managers first, especially when we were just building software in the domain we now manage products within. However, the complexity in this problem is rooted in that as an engineer, technical == writing code. But, as a PM being technical == understanding the technical domain well enough to make better economic trade-offs for the benefit of the product. Specifically, what are type of technical competencies?

The best TPMs are deeply technical, often seen as SMEs – subject matter experts – within their technical domain. They were often experienced engineers first. Here are common behaviors:

• Staying aware of the “cutting edge”/developing technologies and approaches. Am I aware of how technology is changinging in my domain? How would that benefit the users? Am I overdelegating the understanding of capabilities offered by the technology to my engineering team?
• Knowing the design/architecture well enough to determine general technical cost-benefit analysis of product changes. If my technical lead were out, would I be able to have rational design discussions with our engineers?
• Dogfooding their product for their own work/breakable toys. Am I staying as technical as the users? Or is their world changing in a way that makes understanding mechanical sympathy more problemattic? Am I able to empathize sufficiently?
• Extra Credit: Enganging the broader community via speaking or writing.

Example

• Highly technical (co-creator of GraphQL) and demonstrates using the tool. He leads by showing it working.
• Worked closely with product teams to define pain points they had, leading to GraphQL. Identifying customer segments, pain points, prioritizing, then executing on that prioritization. It’s unclear if that would’ve been possible without closely working with the technical product teams.
• Able to tie the pain point use cases from users to the larger concepts GraphQL uses or solves (eg: why static type systems were included, why declarative styles are good – all to solve the pain of predictability and efficiency)
• Showed deep knowledge of other related concepts, like what a graph actually is and how it relates to GraphQL

I won’t get all of it, there is much more. But, I think this is a great example of a TPM.