Introduction
In this series, my aim is to help early to mid-career technical product managers (or those looking to become TPMs) uplevel their skills and master the Technical Product Management role. By the end of this series, you should:
- Understand the differences between Product Management “Flavors” and the subcategories within Technical Product Management.
- Understand the skills and experience needed to master technical product management.
- Have a reference guide to come back to for all of your Technical Product Management concerns.
With that out of the way, let’s dive in!
Types of PMs
There are a few fairly distinct groupings of Product Managers. Some Product Managers (PMs) are more core customer-focused, growth-focused, or technical-focused.
Core Customer PMs
By far the most common type of PM. They generally work on delivering new features that are UI or customer-facing.
Growth PMs
They tend to run more experiments, trying to optimize for conversion rates. Some examples include:
- finding ways to improve in-app CTAs to in turn increase upgrade ARR
- improving onboarding experiences and in turn activation rates
Technical PMs
They tend to be more closely involved with Engineering and focus on delivering customer value or enabling customer experiences via complex technical investments. Some things they may work on include:
-
Programmatic ways to interact with applications like APIs and SDKs
-
Building systems that enable improved customer experience (IE: at Zapier, my team spent a lot of time designing native capabilities that would increase the scale of certain features like the number of Looping iterations in an automation OR the number of records that can be processed at once)
Commonly, technical PMs will have some sort of industry experience or training in a specific technology that makes them a great fit for the role. For example, an ML Engineer may transition into Product Management to lead up a foundational ML Team at an organization.
Platform PMs
This usually is a technical PM that is working within the context of a platform. While platform PMs do not have to necessarily be “technical”, it usually increases the likelihood of success in the role. For the purposes of this guide, I’ll classify Platform PMs as a subcategory of technical PMs. To complicate things further, there are many different types of platform PMs, each with specific focuses and a mix of internal and external customers:
- Core Platform: Building blocks of a system delivered via API
- Internal customers: other teams building experiences from APIs or building blocks your team provides
- External customers: end-users integrating functionality into their applications OR the direct delivery of capabilities/functionality to users (note: this may not be presented via the UI but affects the customers’ experience)
- Identity Platform: Authorization and Authentication (including Roles and Permissions)
- Internal customers: rely on services to authorize and authenticate users in your app
- External customers: use features to manage their users’ access to their data
- Developer Platform: driving a developer enabled strategy to accelerate a growth loop for the platform (IE: allow developers to build apps to enable new functionality for end-users)
- Internal customers: teams leverage interfaces to surface apps to end-users
- External customers: 3rd party developers build apps with your tooling
- Developers’ customers: Leverage the functionality in developers apps. You should understand their pain points and how you can improve their experience through changes to the developers’ experience.
- Internal Tools: builds tools for developers (or others) within the organization to increase productivity.
- Internal customers: developers or other teams like support
- External customers: less of a direct connection, but end-users of your internal customers. IE: if you build support tooling, the end-users receiving support via your tooling would be your external customers.
While we just spent a lot of time defining types of PMs, some PMs are generalists and can do all of these things fairly well but are not experts in a specific discipline. The type of PMs an organization needs also heavily depends on the nature of the Product and/or stage of the company. For instance, a more complex, technical product is going to require more technical PMs. A larger company may have all of these types of specialists while a smaller company may only have generalists.
What does “technical” mean?
Before we get further into the role of a technical PM, it’s best to define what “technical” means in this context. A lot of junior PMs ask me “How technical do I need to be to succeed in my role?”, and my answer usually is, it depends. For our purposes, technical can be defined as: having enough context to deeply understand the implementation of your product area to enable you to 1) find the levers you can pull to improve the product for customers and 2) be able to clearly articulate the what you’re building and why you’re building it for less technical stakeholders.
This means you don’t necessarily need a Computer Science degree, but it certainly helps. However, if you’ve been technically inclined most of your life and have experience writing code, understanding complex systems, and deeply understanding the technology you’re working with, that is more important than a CS degree.
In the next chapter, we’ll discuss a Technical PMs strengths in more detail and how a technical PM can sharpen their toolset to have a broader impact on the organization.
... Next chapter coming soon :)
This article was written with the help of PMs from Zapier, Stripe, Square (Block), and Formstack. Thank you for your contributions!