Comparison with Other Roles

Product Manager (PM)

Product Management is the role that most people conflate, or they are unsure of the differences with TPMs; both have “manager” in their title, work closely with engineering teams, and seem to be lost in spreadsheets, emails, and meetings. The biggest difference in role expectation is that while TPMs focus on driving execution, Product Managers set the strategy and vision for a given product. Usually, this means you are writing product requirements documents, customer journeys, and strategic roadmaps. Some companies (i.e., Google) require Product Managers to have technical backgrounds, while others (i.e., Facebook) do not.

Given the sometimes ambiguous and overlapping nature of both roles, I want to re-emphasize the importance of having a frank discussion about roles and responsibilities with any PM you work with. It is not clear sometimes. And if there isn’t a line in the sand, then the PM may try to give you work they don’t want to do. The best way to prevent and handle this is to be ready to pushback and say “no” while finding areas where you can add unique value. It is certainly not easy and may be difficult if you’re new to a team, but you should be aware of the risks if this isn’t done early in the relationship.

Program Manager (PgM)

Program Managers or PgMs are very similar to TPMs. The difference between them is that they do not necessarily have the same technical expectations as a TPM. Many Program Managers own operational processes that span multiple teams but do not require technical skills or work on non-technical projects, such as helping with onboarding new individuals to a company.

An often asked question is: How does one transition from Program Management to Technical Program Management, given how similar they are?

The answer to this question is different for everyone, but the best way to do this is to demonstrate consistent technical proficiency, and then work with your management chain to change into a TPM role. There are several ways to do this:

• Working on a technical project with engineers who can support and attest to your technical skills
• Building technical artifacts such as dashboards and scripts
• Contributing to or proposing design solutions for highly technical problems

In addition to demonstrating the right technical skills, you’ll also need the right supportive environment: a company that encourages role changes, a manager who will support you pursuing this change, and stakeholders who will help you reach this goal. This requires a lot of work. And quite frankly, it requires luck too, but don’t be discouraged by the challenge. It will make achieving it that much more fulfilling!

Key similarities

Although I’ve talked above about the differences with Technical Program Management, I want to talk about the similarities. The focus will be on the two most important ones that are critical for all of the above roles. First, each of the above roles is not strictly necessary to get stuff done. You can have a highly effective engineering team that is able to build a great product with market fit and deliver it flawlessly. That’s quite an ideal situation, but the point is that it’s really incumbent on a TPM, PM, and PgM to identify the value they can add to a particular team and deliver on it well.

It’s not always easy to identify such opportunities, and it is why a lot of folks struggle when first starting a TPM role. However, starting small with deliverables such as making sure meeting notes are written down, sending regular updates to stakeholders, or just taking meetings for the team can go a long way in building credibility. Nail the small stuff, and then start grabbing bigger and bigger tasks.

The second biggest similarity is the need for structure and organization. You need to be very organized with how you construct and communicate your work. This is a must for showing that you have done your due diligence and gained the confidence of your team. No matter what you’re creating, whether it’s a product requirements document or just deciding which project tracking tool to use, show that you have thought things through in a meaningful way.

Hopefully, the above is useful in helping you make a decision on the type of role you’re looking for. I find the TPM role to be fairly enjoyable, given the compensation and amount of responsibility. But each person is different. I highly encourage everyone to look at the career ladder for each of these roles to determine which one is best for you. Don’t let external forces determine what is the right career path for you; only you can decide.