So, What is a Technical Program Manager (TPM), Anyway? Part 2: The Four P’s19 min read

This is the second part of a series about defining the Technical Program Manager (TPM) role. See Part 1 here before continuing, as this post will reference concepts outlined there such as “the TPM triangle.” I ended that post on a cliffhanger around how a TPM and other roles work together. Specifically, there are “four P’s” we need to address and reconcile with one another:

1. Program
2. Product
3. Project
4. Portfolio

I will define these words, along with acronyms used for abbreviation as they are used in this article, but if you want them all summarized, see Appendix: Definitions & Acronyms at the bottom of this article. I also apologize in advance for something I do not control: that all of these words begin with the letter ‘p.’ This alliteration can make reading about these things confusing. To help minimize said confusion, I will minimize use of acronyms that aren’t TPM.

I’ll kick us off on a light note: the state of the industry today and the use of these four words is nothing short of a complete mess 🙃. Some companies have both technical program managers and program managers; some don’t. Some don’t have program managers at all, but have one or both of product or project managers. And some think all of those roles are the same, and product managers are just the new name for program managers which was the new name for project managers 😅. While there is history of the discipline’s evolution, the reality is that all of these roles still exist in various forms at different companies. Throw in the “technical” adjective to the above terms, and there are eight separate industry roles that are inconsistently defined that are often the same thing. Spoiler alert: I do not believe there are eight separate roles in this space. Which roles do make sense together, well, that’s what this post is for.

Lastly − if you’re thinking oh; I’ve heard about TPMs, and we definitely need this at our company that currently doesn’t have them, this post is for you as well 😂. As before you can make this claim, you have to be able to explain how the TPM role fits in with your other existing roles!

So, what is a Program? And is it the same thing as a Project?

Given this post is about defining technical program management, we’ll start with defining what a program is. While there are external definitions galore (such as this one), most define a program in relationship to project management. For example, the link above calls a program manager “a super project manager” 🤮. Which begs the question so, what’s a project manager? See? This recursive cycle of definitions isn’t ideal.

While yes, a program is often a collection of projects or perhaps even other programs − sometimes called a “portfolio” − now the definition would be “a program manager manages a portfolio of projects and programs,” making the definition not just recursive and confusing, but cyclical 🙃. Do you see why I apologized in advance about these words? While this definition is accurate, I argue we can do better.

I am surprised that I never see folk start with the formal definition of the word “program:”

a plan or system under which action may be taken toward a goal

Compared to the earlier definition, I argue this is much more clear. We can then compare to the formal definition of the word “project:”

a specific plan or design

While these definitions are similar, they are not identical. The important nuance is that a program is broader than a project. For example, what if a program requires 2+ projects to complete its goal? This is not abnormal, but in fact, common. However, one thing is clear: a program manager must be able to manage projects. Thus, you see how the earlier definition of “a super project manager” starts to make sense.

However, there is a nuance in the tech industry that must be taken into account: some programs never end. Examples include, but are not limited to:

• Reliability
• Efficiency
• Security
• Data Quality
• Culture Improvements, such as Amazon’s Bar Raiser program
• Standardization of something, such as a shared frontend component library

Imagine achieving a goal around reliability − great! Does that mean that we no longer care about reliability? Can our website or service now have outages and it doesn’t matter? Of course not; of course we still care! It is even possible that a goal simply remains in perpetuity, such as achieving five 9s of availability every year. You may achieve it, but to achieve it again, active focus is required to keep up with the changes to a system that may impact this goal.

These programs are all examples of things that will have goals, but when achieved, the programs are not “done” or “complete.” In other words, some programs do not have an expiration date, and the “plan or system…taken toward a goal” may change over time. Given this definition, programs are often very broad and impact many teams, if not the entire company. They may or may not have visible external impact to the customer, but value exists regardless; the examples above are all requirements for a company’s success.

These examples all show what was meant earlier by a program being a portfolio of other projects and programs. Continuing with the reliability example, imagine you manage a reliability program for your company. What does this entail? Well, you probably want to establish a Root Cause Analysis (RCA) program, where you hold folk accountable for reliability issues that occur and ensure that issues are understood and prevented in the future. Right off the bat, your reliability program has a sub-program. You also might need to improve your monitoring to detect outages and understand their customer impact. So you come up with a proposal for a new monitoring system that is accepted and prioritized. Now your reliability program also has a project, or perhaps a portfolio of projects, to build and launch this new monitoring system. This model can expand in scope to be so broad that one program manager manages the reliability program as a whole, but other program managers manage specific aspects of the program. As programs grow, it is common for them to exceed the capacity of a single individual.

So, do you need Program Managers and Project Managers?

Based on the definitions above, no, it is not recommended to have both Project Managers and Program Managers as two separate roles for the same company. A program manager (PgM) must be able to manage projects to achieve their program’s goals, but you do not need two separate roles. While a program manager can be considered a manager of projects, or perhaps project managers, this disambiguation adds unneeded complexity and ambiguity. Nearly all companies have different levels for their roles to enable promotions which can impact a title. For example, Associate TPM → TPM → Senior TPM → Staff/Principal TPM → Senior Staff/Principal TPM, etc. With this, you don’t need to change the role title, but the level. And by consolidating on the role program manager over project manager (PjM), you are prioritizing flexibility and the growth of the role − you will never need to introduce the project manager role.

What about the Technical aspect? Do you need Program Managers and Technical Program Managers?

I mentioned that I was a technical program manager (TPM), not just a program manager (PgM), and I like to think that this adjective is self-explanatory.¹ I touch on this disambiguation in part 1 of this post series, but I will go into more detail here.

In summary, TPMs have an engineering background. Given this background, it is expected that TPMs can strongly participate in engineering design decisions as needed. While TPMs don’t code, they are expected to be involved in technical design, and it is likely that this will be tested in their interview loops. This background is not expected for non-technical program managers if a company disambiguates between the two.

Take the example above about running a reliability program − how would a non-technical program manager run an RCA program of technical system failures? They wouldn’t have the necessary background to audit for quality or to understand where two issues are the same or not. When designing and prioritizing the new monitoring system, how would they know if it will scale and be able to handle future use cases? It must be designed with these in mind, again requiring a technical background.

We then are left with the question: should companies have both program manager and technical program manager roles? The answer is: it depends. Microsoft famously just had program managers, where the “technical” component was implied. When I worked at Facebook, they only had technical program managers, where the “technical” component was explicit. But at both Amazon and Zillow, program managers (PgMs) and technical program managers (TPMs) exist as distinct roles. For example, if the portfolios you are managing are in operations, or design, or marketing − any non-technical portfolio − does it make sense to assign a technical program manager? Probably not, and you would likely struggle to fill that role, as technically qualified individuals aren’t going to be interested in abandoning that skillset. Therefore, as to whether or not a company should have this disambiguation depends on the nature of the company and the role.

Therefore, if both roles exist, TPMs are more involved in execution of technical projects and programs, and PgMs are involved in, well, non-technical projects and programs. Depending on the overall goal(s) of the program, this means that TPMs and PgMs may need to work together to achieve the goal(s). For example, when Zillow was transitioning to a brokerage, there were implications across the entire company, from the tech stack, to contractual changes with partners, to operational changes with employees, to frontend changes to the customer experience. For this portfolio of projects, PgMs and TPMs worked together to accomplish this shared goal − along with Product Managers (PdMs).

So, what is a Product? And how is it different than a Program?

Warning: This is where things start to get tricky. Like above, let us start with the formal definition of the word “product:”

something (such as a service) that is marketed or sold as a commodity

Unlike a program, a product is guaranteed to be a tangible thing. While a product likely has a portfolio of projects to deliver it, the outcome and approach is different. When it ships, it is visible in some way to your customers (which can be internal to your company, such as a developer tool). It has a delivery date, and after it launches, there may not be a v2 or continuation of it.

While many programs never end, they also do not exist without at least one product. You need a product to be reliable, efficient, secure, and have accurate data (to leverage the program examples above). Products are tangible artifacts; zillow.com is a product, or perhaps more accurately, a portfolio of products. Products have launch dates, products have customers, and products have features. While components of a program may have these things, the program itself is not tangible in the same way.

But go reread the definition of a program − what if the program’s goal requires it to launch a product? In the reliability program example, you mentioned creating a new monitoring system − isn’t that a product? I warned this is where it gets tricky − bear with me!

So, what’s the difference between a Product Manager and a Program Manager? Does a company or team need both?

While there is a difference between a product and a program, the reality is both are things that need to be managed in very similar ways. For example, completing program goals and launching a product both require managing portfolios of projects from start to finish. Another example is that both require the ability to determine prioritization of projects, including those that don’t fall within the direct domain of the program or product manager. For example, you need to be able to weigh your own priorities vs others’ to know when to expect certain work to be completed, impacting your overall project completion.

At the end of the day, launching a product requires “a plan or system under which action may be taken toward a goal;” the goal in this case is launching said product, likely to achieve some customer benefit or company value. In other words, based on definitions alone, product managers are just a particular type of program managers; they are program managers whose goals require them to launch and manage products.

I must now interject, as I expect the statement above to be controversial. Why? Because the sad reality is there is a lot of ego in the software industry, and some product managers view program managers as “lesser.” This is in spite of the historical fact if they’re old enough, they probably used to be called program managers.² Since then, the industry has (re)introduced program managers and technical program managers into the mix, meaning we now have product managers who used to be program managers confused about program management 🙃. But I do not wish to discuss ego, or any company specifically − they’ve all made a messy situation in their own way, and I don’t know of a single employer that is an exception to this statement. Given this is a current hot button issue across the industry, I wish to share my perspective on this.

Getting back on track − does this mean we don’t need program managers if we have product managers? Or the other way around? It’s still confusing to pick just one, as not all program goals are to launch a product. We have established that program management may involve product management, and that product management must involve program management, etymologically speaking. In other words, we have this:

So, do you need both roles? Similar to how it didn’t disambiguate between TPM and PgM, Microsoft also didn’t disambiguate between program and product manager. They are clearly a successful company, which proves the answer to needing both is “no.”

But what about the differences between managing a product and a program? This is where things get more interesting, as even Microsoft now has both roles, and I argue the reason for this is implied beyond the etymology of the words product or program, as evidenced by the differences in the job descriptions of the two roles at Microsoft. And don’t forget about the “technical” adjective! Yes, we’ll get to that as well.

Insert: The 5 W’s and One H Language (and Why I Hate It)

It is at this point that nearly all resources I could find about differences between program and product managers, such as those in Appendix: Good External Resources about Role Differentiation, leverage the five W’s and one H language. If you have ever read about this topic, you may have been wondering why I waited so long to mention them. Nearly all say the same thing: product managers typically focus on Why, What, and Where. Meanwhile, TPMs/PgMs typically focus on How, Who, and When. While this sounds nice and clean, the reality is these overlap, like a Venn diagram, as they impact one another. The ideal What might delay a project by multiple months because the How is complicated, which isn’t worth the cost compared to an alternative option. Thus, while a TPM/PgM and product manager working together have distinct areas of ownership, they also must be in high-touch with one another to communicate these areas of cross-over impact.

Lets also put this into reality – imagine a product manager telling an engineering leader that they tell them what to do. That’s not going to land well, is it 😅? The ScarletInk has a great post sharing how this behavior made him, a strong engineering leader, feel. Let’s just say it didn’t lead to a strong relationship or collaboration between the product manager and him! Escaping the Build Trap: How Effective Product Management Creates Real Value sums it up well: “at the end of the day, it’s the team, collectively, that really owns the product − the what.”

The 5 W’s and one H sometimes gets boiled down to “product managers focus on strategy, while TPMs/PgMs focus on execution.” However, I argue that this statement confuses a comparison of level or seniority with a comparison in role. In other words, it’s comparing a senior+ product manager to an associate program manager; it is too simplistic given the example above of how execution can impact a strategy. Regardless of one’s role, as one advances in their career, they move from a more execution-focused contributor to a more strategic contributor.

A more nuanced statement would be that product managers focus on business strategy while TPMs focus on technical strategy.³ While technical strategy should work backwards from business strategy, it also informs feasibility. For example, realizing the feasibility (or cost) of something may significantly impact the business strategy! A great example explaining the link between the two can be found in this stratechery article about Shopify vs Amazon. Both are platforms that enable ecommerce fulfillment, but their business models are vary different, and their tech stacks vary for this reason as well.

However, if we continue with this model − product managers focusing on business strategy − I argue they are no longer doing, well, product management. To stick with the Amazon vs Shopify example, the business strategy to integrate directly with customers vs thousands of third party merchants informs the product, but isn’t the product itself. For example, it doesn’t define the product experience at all. Now, given TPMs are the ones focusing on the technical strategy, they would actually be the ones defining the product to match the business strategy. Thus, while business strategy is an important role − don’t call it product management.

Another way I hear this represented is that TPMs focus on breadth, while product managers focus on depth.⁴ A product manager may care about their individual product or feature area, but a TPM is likely looking at how such work fits into the broader portfolio of projects and programs they manage. However, this doesn’t make sense, as things like strategy (of any kind), market analysis, competitive analysis, etc are all inherently broad activities. For example, before prioritizing a product or feature, one should see if it already exists first! Perhaps it doesn’t make sense to build it, but to instead reuse an existing internal system, leverage an existing open source technology, or pay a third party for the product/feature. Separating these exercises into two separate roles all but guarantees that duplication and waste will occur.

So, is this language worth using? I argue it is not. Remember, product managers are just a particular type of program manager! The reality is to deliver a product, a product manager has to focus on execution as well. And this is where the “technical” adjective starts to carry weight.

Back to (Technical) Product vs (Technical) Program…

So we are still trying to answer the question do you need both roles? We’ve established that a manager of either a product or program needs to do similar things, and a product is just a more defined program type. But trying to just look at product vs program typically results in an ouroboros of an argument. To break this cycle, I want to introduce the “technical” adjective into play. And the reason is due to something we haven’t talked about yet: typical job requirements for a role.

Product managers typically have a Master of Business Administration (MBA); technical program managers typically have a Computer Science (CS) degree; and non-technical program managers (if disambiguation exists) typically have neither. If we take a pessimistic view, we invented these different terms to explain different backgrounds rather than for legitimate business purposes. We then invented phrases like the 5 W’s and one H to explain the differences, and we did so poorly. However, the reality is none of these backgrounds are mutually exclusive; from double majors, to dual degrees, to major-minor combinations, to real experience in multiple disciplines (which is common in startups and smaller companies), it is foolish to try and pin these backgrounds into strict boxes. Additionally, if you work backwards from what a company truly needs, it needs these hybrid backgrounds.

Product managers at software companies own technical products. How can you own a product you don’t understand? Conversely, technical program managers exist to meet the needs of the business. How can they prioritize their program if they don’t understand some amount of business value and strategy? Rather than trying to explain program vs project vs product and then the technical variants of the three, let me now say what I believe should exist and how they make sense together:

1. Technical (Product | Program) Manager
2. (If Needed) (Product | Program) Manager
3. (If Needed) Business Strategist

If you’re not familiar with regex notation, (Product | Program) means pick one; however, don’t have both. But yes, we’ve gone from 8 potential roles to three 🤯. Going forward, when I use the TPM acronym, it means this one role, as no, I do not believe there is a difference in the roles (and yes, I hate the PM-T acronym for Product Manager-Technical to try and falsely disambiguate).

The TPM has both a business and technical background, while the program manager lacks a technical background and may or may not be required, depending on the role. Allow me to explain with the same example from part 1 of this post series: what should our engineers build? And how will we have confidence in this answer? I argue this cannot be answered without clear understanding of competitors (business background), a market analysis (business background), an understanding of how much effort it will take to build something (technical background), and if we are architecting for scale and expansion (technical background). This is true regardless of whether you are a frontend or backend TPM. Imagine you are a TPM for a backend data team. You still have a product (a data pipeline, or data warehouse, or large-scale production database with multiple clients, etc) for your customers (who happen to be internal developers). You must still do market research to build what your customers want, just internal market research. And while I wish this weren’t true, competitive analysis is also still required, as yes, some companies are that large (and/or have poor documentation, communication, and knowledge sharing). In summary, to manage a technical product or program, you must have both business and technical expertise. I know that I mentioned formal education before, but I did not mean any of those as requirements. In fact, many of the best product managers, engineers, and managers I’ve ever worked with did not have formal education.

But what about folk with just a business background − would they still fit? That depends on the company’s needs. Perhaps they’d be a program manager, or perhaps another role. Per the earlier discussion about business strategy, this role can be incredibly valuable; just don’t call it a product manager.

So, you’d be OK changing your title to Technical Product Manager then? Yes − to explain, I will go back to the TPM Triangle.

Revisiting the TPM Triangle

If you’re observant, you’ll notice that one of the TPM archetypes in the TPM triangle from the first part of this post is the “Technical Product Manager:”

Thus, my recommendation shouldn’t surprise anyone; really all I’m explaining here is that with this, you don’t need both TPMs and non-technical product managers at technical companies.

Ratios

So, do you need the same number of TPMs, program managers, and business strategists? No; this will vary based on your company’s needs, but it is an anti-goal to strive for a 1:1:1 ratio. In this model, having a ratio of one TPM per engineering team can make sense (although less can also be valuable, more only makes sense in rare situations). Program managers would likely be in some ratio with non-engineering teams. And business strategists would exist sparingly as-needed − you don’t need multiple competing company strategies! However, for things like mergers & acquisitions, keeping up with the competitive market landscape, etc a single organization of these folk can make sense.

Additionally, with this structure, TPMs don’t require to be what I call a TPMO (Technical Program Management Office). As in, they can simply report to existing engineering managers, minimizing the cost and overhead of the function, and maintaining single-threaded ownership of the engineering manager who can choose to tweak their ratio of TPM:engineer as needed. I will dig into the pros and cons of this organizational model vs the centralized TPMO model in the future, but avoiding a requirement of a specialized TPM manager⁵ role is valuable.

Conclusion

With this post and the one before it, we have laid the foundation of what a TPM is and how it is different from existing roles. With all of this context now established, I can now finally dig into TPM details in a third (and hopefully final) post in this series. Such details include things like a formal job description, key facets of the role, a career progression summary, and a leveling guide. Stay tuned for part 3!

---

Appendix: Definitions & Acronyms

1. Program − a plan or system under which action may be taken toward a goal
   • Program Manager (PgM)
   • Technical Program Manager (TPM, but should be TPgM). Given this lack of adoption, I continue to use the TPM acronym (for now, at least 😅).
2. Project − a specific plan or design
   • Project Manager (PjM). For more details on PjMs, see this Project Management Institute (PMI) article.
3. Portfolio − a selection of…work…compiled over a period of time and used for assessing performance or progress
4. Product − something (such as a service) that is marketed or sold as a commodity
   • Product Manager (PdM)
   • Product Manager − Technical (PM-T), but should be Technical Product Manager (TPdM)

Not all companies have adopted these acronyms yet, but they are becoming more popular. Note that I avoid the PM acronym as it is ambiguously used to mean any of these roles; its use should be deprecated. However, if you ever see me use the PM acronym outside of this post, I am specifically referring to Product Manager.

Appendix: Good External Resources About Role Differentiation

All of these references influenced my writing and deserve to be cited here. However, they are often in conflict with one another (yet I still argue they are recommended reading together). Thus, the opinions in this post are not a perfect match to any one of these, but you will see areas of agreement and conflict with this post if you read any of these. Some of these are referenced directly in the text above; some are not.

1. PM: Product vs Project Manager
2. Evolution of the Product Manager
3. Product vs Design vs Tech: A Partnership, not a Battlefield
4. Differentiate between TPM and PM
5. The Difference Between Product, Program, and Project Management
6. The History and Evolution of Product Management
7. 6 PM Stereotypes to Avoid

---

Footnotes

1. If one needs to disambiguate between technical program managers and program managers, I often call the latter “non-technical program managers” to be clear in conversation.
2. Not even just at Microsoft. Zillow, for example, used to only have program managers, before changing them all overnight to the product manager title years ago. This isn’t that surprising given Rich Barton‘s and Lloyd Frink‘s history at Microsoft, where they were − guess what − program managers.
3. The definition of “strategy” is its own post (for the future) 😁. Update: said future post now exists.
4. I admit, I used to say this as well. I no longer do, however.
5. Otherwise known as technical program manager managers 🤣, or “group managers.”