Jack Ukleja

What is a Technical Product Manager?

5 min read

✅ It is a product manager

First and most importantly, a TPM is a product manager.

To understand how a TPM works you need to understand how a PM works. If you don’t understand the discipline of product management, you cannot understand technical product management.

The most basic responsibility of a PM is the success of a product.

A prerequisite of being able to do that is actually owning a product. Hopefully it goes without saying, but you cannot manage a product if you don’t have a product to manage.

So, if you can’t point to a product that is yours, or you aren’t ultimately responsible for its success, then you aren’t a TPM. It’s as simple as that.

✅ …who manages a technical product

A technical product is one that is “technical” with respect to the business-domain. If your business-domain is payments, then a technical product is any product that has no concept of (or is at least one step removed from) payments.

Technical products generally manifest as the internal tools, services and platforms that are used to support and accelerate the work of other teams, which you have intentionally decided to treat as products.

The customers of a technical product are the internal teams who receive the benefit from using them. The users of a technical product are the employees who actually interact with the technical product, day-to-day.

Your business’ customers are generally unaware of your technical products. In fact, technical products exist entirely outside of your business’ value-stream.

Info

Technical products can also expose interfaces to external users (i.e. from the real customer) which may cast doubt on the ‘technical’ nature of your product. To resolve this, it’s helpful to ask the following questions:

  • Could non-technical product teams have built this interface themselves?
    • If yes, this confirms you are accelerating the work of those teams

⛔ It’s not a product manager who is “technical”

This is the first major misunderstanding. People often interpret TPM as a “technical” product manager. In other words, a product manager with technical skills or understanding.

It’s super important to point out that all product managers need to be “technical” with respect to their product. You simply cannot manage a product effectively if you don’t understand all the ins-and-outs of the domain, your customers’ needs etc. The very idea that product management is even possible without a very advanced understanding of your product, it’s domain and ecosystem is silly.

While product management does include lots of transferrable skills between products, I can assure you that if you move from managing a line of fishing rods 🐟 🎣, to a line of [magnetic resonance imagers](Magnetic resonance imaging - Wikipedia) 🧲 you are going to need to acquire a lot of new technical knowledge to become an equally effective product manager.

And I’m not alone in thinking this: Most Product leaders share the view that all product managers should be technical.

⛔ It’s not a role in the Product org

Here’s the bit that really confuses people: Product management is just a problem-solving approach. Using an approach does not automatically make you part of any given “product organization”. Technical product management is simply using said problem-solving approach for technical products.

Because technical products are generally orthogonal concerns to your business’ actual products, it does not make sense for them to report into or be managed by the traditional product org.

And because many technical products exist to solve problems in the engineering domain the most common place you will find TPMs is within the engineering org. The archetypical example of a technical product in the engineering domain is a developer platform, and to my knowledge this is where TPMs were first gained traction. (N.B. use of TPMs isn’t restricted to engineering - they could fit naturally into finance, accounting, IT… basically any team building internal systems).

As a general rule, a company accumulates many such internal platforms. And the fact that it’s so hard to get them right (yet they are so important to staying competitive) is the precise reason that the product management approach has been adopted outside of the traditional product org.

To learn a bit more about how “product thinking” has caught on as a problem-solving approach to internal platforms check out the following:

Note

Bwha!? Google gave me a different definition!

You aren’t going to believe this, but the vast majority of explanations out there are wrong! And by wrong, I specifically mean: incoherent. Many are written by traditional product managers (or more likely: content marketers), who have fallen into one of two common traps: the belief that product managers don’t need to be technical, or that you need special skills to communicate with engineers. If you read any of them closely you will realise they leave you with more questions than answers. If there is enough demand, I can write a follow up blog post explaining where they go wrong in detail, but a quicker approach is simply to check LinkedIn job openings - the majority will be for internal platforms. The definition of TPM I give in this blog post is the only one you will find that is both simple and coherent.

Graph View