Having almost the same abbreviation, these roles are completely different. Below there is a short comparison and recipe for effective collaboration.
There is a lot of confusion when it comes to the responsibilities of two “TPM”s — Technical Product Manager and Technical Program Manager and the fact that both roles are relatively new on the market doesn’t make understanding easier. At the same time, a well functioning mix of TPMs could enable your organization to deliver projects of enormous complexity. There is one important condition though: both TPM types should concentrate on their (orthogonal) scopes, which are defined by focus areas, team structure, tech skills, and day-to-day work.
Focus areas
Tech Product Manager (let’s use “Tech PM” abbreviation) is still a Product Manager, so responsible for what and why of a solution being built.
Even though the “Tech” prefix makes Tech PM more suitable for technological topics (think Google search, Spotify music streaming, Facebook ads engine), it doesn't replace the foundational product base (article “What is Technical Product Management?” sheds some light at the difference between a classical PM and a Tech PM).
Tech Program Manager (from now on — “Tech PgM”) does not directly influence product development, instead, he/she takes care of who and when of a large-scale program (usually consisting of multiple projects). In other words, Tech PgM defines who are those N teams participating in the project, what are their timelines, and how do these plans match together in a program roadmap.
It is worth mentioning that Tech PgM role is relatively new and quickly growing due to the complexity (partial thanks to SOA) of modern technological platforms. For example, if one plans to migrate a large product to the cloud, it might touch many different departments and it needs few Program Managers driving programs or maybe even portfolios (set of programs).
Teams and stakeholders
Tech PM operates in a classical development team: few engineers (some of them back-end, some — front-end), a designer/copywriter (if the product is customer-facing), and the team lead managing them. Such a group of people is enough to build almost any relatively simple and isolated application. Leading the dev team, PM together with few other teams at the same time belongs to a product team of the org unit, led by Group Product Manager, responsible for a vision of the area (e.g. Ads, Messaging, Payments).
{$te}
In the same way as PMs, multiple Tech PgMs form a Program team reporting to the Program lead, who is responsible for a set of programs (e.g. client integrations, migration, complex cross-org feature development) or a portfolio.
Technical skills
The whole point (and the main superpower) of a Tech PM is to bridge product and tech. These skills should be enough for Tech PM to go deep with one product and reach a level of features, API contracts, architecture choices, at the same time keeping in mind all the connections their product has with the surroundings, mid/long term vision, and day-to-day development. For example, if a PM drives such critical things as Uber Search engine or Elastic data processing solutions, he/she has to be technical and hands-on.
Tech PgMs, on the opposite, have so many teams/products on their plate, that it is literally impossible to get to details level and it is not their superpower — instead, they operate in breadth. Then, Tech PgM should be technical enough to understand the scope and connect the dots (e.g. Messaging, Search, Payments), but no near-engineering knowledge is required. Of course, it is appreciated and some Tech PgMs can go really deep — there is usually just not enough time for this.
Day-to-day work
Life of Tech PM is all about Product creation and every day is filled with classical activities: standup, team brainstorming, planning, stakeholder catch-ups, and silent thinking (hopefully :) ). Main artifact of PM work: product and its features, main metrics — customer satisfaction.
For Tech PgM, the main goal is to drive the product to the completeness and everyday activities contribute to it: stakeholder alignments (team A, B, and C met to discuss a new feature and agreed on the way forward), resolving blockers (team A delays the new feature and Tech PgM should find a way to unblock team B dependent on this feature), escalations (team B is going to start a big fuss about delaying project X and some urgent meeting needed immediately), etc.
Main artifacts of the Tech PgM are project plans (requirements, dependencies, main stakeholders, escalation paths, Gantt charts — with the level of Project Management magic PMs can only be jealous about) and weekly/monthly/ quarterly updates. Main metric: project completeness and stakeholder happiness along the way.
How Tech PM and TPM play together
In the correct organizational setup, they form two exactly orthogonal forces: Tech PMs are responsible for depth per area and Tech PgM helps to drive things across. If they work well, then a combination of 1 strong Tech PgM and 5–20 Tech PMs can deliver things of tremendous complexity.
When there is friction between Tech PM and TPM
If Tech PgM starts to act as a middle layer between clients/their requirements and a product team, Tech PM might rightfully perceive it as inference in the well-working stakeholder communication process. Tech PgMs should not forget that they are the drivers of the whole program train, but they can only influence (but never define) how each car evolves during the ride.
At the same time, when Tech PMs start to go above their product and act as a high-level project connector, Tech PgM might rightfully remind about breadth and depth to ensure that the train does not diverge from the planned destination due to too many cooks in the kitchen with no one taking care of the individual cars.
What’s next
I hope now you can see the difference between Tech PM and Tech PgM roles and how they play together to cover both the depth and breadth of complex technical projects.
In the next article, we’ll continue to define the Technical Product Manager role (now through comparison with a Software engineer) and how a role transition from the former to the latter happened in my case.
If you already want to become a Tech PM, check out the game-like simulator of PM job I created — great way to practice theoretical skills on real industry examples.