What Does A Technical Program Manager (TPM) Do? A Practical Guide

Disclosure: This post might contain affiliate links. If you click through and make a purchase, I’ll earn a commission, at no additional cost to you. Read my full disclosure here.

In the past, I’ve written a basic overview of the Technical Program Manager position, as well as an interview preparation guide for Technical Program Managers. In this post, I provide an in-depth explanation of the core tasks for a TPM. My goal is to analyze all the main deliverables that a TPM needs to create, in order to run a successful program. I will try to emulate a real-world scenario, in order to make this post more concrete and to talk specifically about the value that the TPM provides to the project team.

Scenario: A TPM is assigned to work on a new project

At this point we assume that the following have taken place:

1. A Product Manager has written an initial spec (also known as the “Product Requirements Document” (PRD) or “Functional Spec”) that describes the business value of the tool, as well as the main use cases
2. This initial spec has been reviewed by the leadership team (E.g. the Directors of Product Management and the Directors of Engineering)
3. The appropriate resources have been assigned. This includes backend engineers, frontend engineers, UX Designers, tech writers, etc
4. It is possible that the Technical Lead (TL) or a Software Architect might have created an engineering design document that shows the technical design of this tool

---

1. Deep dive into the Product Requirements Document (PRD) and the Design Document

As I wrote above, the TPM is not responsible for the PRD (which is owned by the Product Manager) or the Design Document (which is owned by the Technical Lead). However, the TPM should internalize both documents and provide feedback for them. Understanding both documents in depth is critical, as it helps the TPM add value both on the business and on the technical side of the project.

By going through the PRD, the TPM should understand the business value of the project, e.g.:

• What is the business goal for this project?
• What is the competitive landscape?
• Who will use it?
• What are the main use cases?

Going through the design document, is one way, where a TPM shows their Technical Depth. Understanding the technical stack, thinking about potential shortcomings, identifying areas of improvement and asking questions about any area that is not full fledged out are some of the main technical contributions for a TPM.

Deliverables

1. Contributions in the PRD and the Design doc

---

2. Identify dependencies and corresponding stakeholders

After understanding the PRD and the engineering team, the TPM will need to create a list of teams that need to be involved as part of this project. There might be backend teams, frontend (UI) teams, mobile (Android/iOS), teams, etc. Each team might have their own timelines and priorities. Also, some teams might have their own TPMs.

In addition to the teams that this project depends on, the TPM also needs to create a list of teams that depend on this project. These might be partner teams, other teams that build on top on the product, etc.

In general, all projects that have an assigned team, will also have a large number of teams that need to be coordinated. There is no point in having a TPM, if there is only 1 team that is working in this project.

Deliverables

1. Matrix with dependencies and partners:
   • In its simplest form, this could be a sheet that looks as follows:

Project	Team	Contact(s)	Dependency / Receiver	Description	Status
Dashboards tool	Database	Paul (PM), John (TL)	Dependency	The database team needs to implement features A, B, C for us to store our data securely	On track

---

3. Create the high-level project plan and keep it up-to-date

The most important contribution for a TPM in a project is to create a reliable project plan. The goal is to understand the timelines for the launch (e.g. ETAs for each component, milestones, launch date, etc).

It is up to the TPM to define the granularity level for the project plan. My recommendation is to keep the tasks high-level, i.e. they could span multiple weeks or even months. You don’t have to keep track of every small task that the engineering team will implement in this high-level project plan. It’s more important to know that e.g. the frontend engineers will finish the UI within 2 months, so that you can schedule additional testing before the launch.

In order to create the project plan, the TPM works with all the engineers, in order to split the work into tasks, cost them (e.g. how many days of work), map the dependencies, add buffers and create the timeline. Three important things to note:

1. Each team might have different timelines and priorities, so it’ll be up to the TPM to handle all these requirements.
2. The TPM’s technical skillset plays an important role in evaluating the costs that are presented by the SWEs. In the end, the TPM is responsible for the overall plan

Finally, keep in mind that this the initial project plan, also known as a the baseline. It is possible that things might change in the future, e.g. a SWE might leave the team, a new high priority project might be assigned to a team, etc. The TPM should have a way to update the project according to any important changes.

At the same time, if there are are no big changes, then the initial timeline should be reliable enough that it doesn’t lead to major deadline slips. From example, it definitely does not seem like a good idea to slip the launch dates by one quarter, just a month before launch.

Deliverables

1. The project plan might be created in a variety of tools, e.g.
   • A document
   • A sheet (Excel or Google Sheets)
   • Microsoft Project
   • Jira
2. The important part is to capture the information that is required as input for the tool that will be used. The information is shown in the following matrix:

Task	Owner	Start Date	End Date	Dependency	Status
Create the UI	John	January 15th	March 15th	APIs from the backend team	On Track

---

4. Get commitments/sign-offs from all involved teams

After creating the project plan, the next step is to have written commitments (aka sign-offs) from all involved teams. This means that a representative from each team (e.g. the Engineering Manager or the Technical Lead) needs to sign-off that they agree on the timelines that you have provided in the project plan. This will be really important in the future, in case team priorities change, engineers leave the team or the leadership changes.

In order to get all the sign-offs, you might have to work with other TPMs. The end goal is to have some type of document that describes the commitment. Depending on the company, these commitments might have different titles, e.g. “Goals”, “Objectives Key Results (OKRs)”, etc. It is also important to note that it’s important to clarify the dependencies between the different deliverables, e.g. 1 team might commit to deliver its component  in April, so that team 2 commits to deliver its component in June.

Deliverables

1. All commitments/OKRs/goals are added into a tool, where they are publicly visible (Sharepoint, Excel, database, Jira, etc)
2. For each feature that requires cross-team work, get commitments from all teams involved. Typically the Engineering Manager has to sign-off in that document that they are aware of the dependency and they commit to it

---

5. Monitor the project execution and track risks

After having completed all the above steps, the project goes into the Execution phase. Each engineering team is working on delivering the corresponding tasks. However, it is possible (especially on a large-scale project with multiple teams involved) that each team uses a different development model, e.g. Kanban, scrum, etc. One team in a project might be doing sprints and the other might be doing waterfall. It’s up to the TPM to make sure that the progress for the project is according to the project plan.

There are multiple ways for the TPM to have a more in-depth tracking for the project, however typically the first step is to calculate a more fine-grained plan, e.g. doing something similar to the following:

1. The Engineer, who owns each high-level task from the project plan, splits the task into multiple fine-grained tasks
2. The duration for each task is estimated. There are multiple ways to do this, e.g.
   • The owner assigns the costs
   • A Subject Matter Expert (i.e. somebody with more in-depth knowledge in the area assigns the costs)
   • The team estimates the cost for each task as a group
3. The maximum duration of each task depends on the exact methodology, however it would typically not be more than 2 weeks (10 days)
4. The TPM’s task is to understand if the cost makes sense (e.g. are they including E2E testing, time for the design, etc)
5. The team can add a specific buffer to the tasks, in order to account for unpredictable delays. Typically this might be 30%-50% of the initial estimation, i.e. a task that was initially calculated as 5 (unbuffered) days might be written down as a 8 (buffered) days

I’d like to note here that the team doesn’t have to do this for all tasks in the projects. For example, if the team is using 3-week Sprints, then they only need to do this fine-grained costing for the tasks that will be completed within the next 3 weeks.

Regardless of how the team decides to assign, split and cost the tasks, the TPM is responsible to keep track of the progress compared to the project plan. There are multiple ways to do this, e.g.

1. Participate in the team meetings (typically weekly/bi-weekly) or even the team standups (3-5 days/week) to have more concrete information about the progress (e.g. if there is any big blocker on an important item or if there is a new dependency, any risks, etc)
2. Ask the task owners to provide a periodic (e.g. bi-weekly) update for their tasks

In addition, as part of all the above discussions, the TPM should keep track of all risks that might cause any future change to the project plan. It important to be aware of these risks, in order to act on them proactively and to communicate them in advice. It is very different for all stakeholders to be aware that a high-probability risk might cause a 3-month delay to the project than to suddenly get the news of the delay without any previous warning

After gathering the required information, the TPM will have to decide if everything is going according to plan or whether they need to adjust the project plan. If anything changes, then they will need to update all stakeholders accordingly (see next section).

Deliverables

1. The actual way to track a project varies, depending on the development methodology, e.g.
   • Scrum sprints
   • Kanban boards
   • Direct updates to the project plan
2. Risk log: This is a list of the current risks that might cause any future changes to the project execution, as well as the corresponding mitigation plan and status. The risk log could look like this:

Risk title	Impact	Likelihood	Description	Mitigation plan	Owner
Delivery date of dependency X is uncertain	High	Medium	Library X is a critical dependency. It’s release might be delayed for reasons A, B, C	Evaluating implementing the functionality within our own stack (ETA: XXX)	John

---

6. Communicate with all stakeholders

Communication is key for a great TPM. In most cases, the TPM is the only person, who can provide a holistic view of the project (including all dependencies, customers, metrics, etc). That’s why it is highly critical for a TPM to communicate status.

Since there are multiple stakeholders, who need different levels of details for the project (e.g. a Director would need a very high-level view, whereas a Product Manager might need a more detailed one), the TPM needs to establish multiple communication mechanisms. In fact, I will go to the extent and say that there is no way to over-communicate status.

In the “Deliverables” section below, I have a list of potential ways to communicate status. Some of them are periodic (e.g. a bi-weekly status update email), whereas some others might be more ad hoc (e.g. a meeting with another team). However, the important part is to remember that whenever there is any change (or upcoming change) to the project plan, then everybody needs to know as soon as possible.

Deliverables

1. Status report: Weekly or bi-weekly
   • The report should become progressively more detailed. The idea is that senior leadership can get the high-level view by reading only the top sections (e.g. a couple of paragraphs), whereas somebody who wants to know the nitty gritty details about the project can read the whole report)
   • The top section should be a high-level summary, e.g.
     • A TL;DR, highlights, lowlights, what changed since the last report
   • Mid sections should include:
     • List of all projects with high-level status (On track, At Risk, Off Track) and some high-level description
     • Risks
   • Lower sections should be more detailed, e.g.
     • One section for each project showing the status for each workstream in the project
   • Add any relevant documents (e.g. links to project plans, PRDs, design documents) as resources at the bottom of the status report
2. Business Review: Monthly/Quarterly presentation to key stakeholders
3. Team meetings: Weekly
4. Meetings with key dependencies: Bi-weekly
5. Meetings with non-engineering teams (support, documentation, marketing, etc): Bi-weekly (if needed)

---

7. Coordinate non-engineering teams

A very important (but often neglected) part of each product is the work that is being completed by the non-engineering teams, e.g.

1. Marketing
2. Support
3. Legal
4. Documentation
5. UX Design

In order for each team to be successful, they all need to be aware of the project timelines. Also, they provide deliverables that should be tracked as part of the project plan. In fact, their input directly affects the project plan. For example, if the documentation is not ready on time, then the launch date would have to be delayed, even if the implementation is complete.

Deliverables

1. Periodic meetings with the non-engineering teams that are part o the launch (e.g. marketing, support, legal, documentation)
2. Update the project plan to include the deliverables that are provided by each team
3. Verify that all non-engineering teams are included in the communication for the project (e.g. they receive the status report)

---

8. Manage the launch process

As the launch date is getting closer, it is important for the TPM to manage all the processes that are required to formally enable the launch. Depending on the company, these processes might be more formal (e.g. the TPM might need to get physical sign-offs from a specific set of people) or less format (e.g. the TPM might just send an email to all parties that they are about to launch).

Regardless of the actual format of the launch approval process, it is important to make sure that all parties are aware that this project is about to launch. You don’t want to go into situations, where somebody raises a red flag for the project after it has already launched.

Deliverables

1. Bug bash is always a good idea before the launch, in order to flush out any final bugs and to allow any interested party to try the product before launch (i.e. a sneak preview)
2. Signoff from all teams (engineering, support, marketing, etc)
3. Might need launch approvals from VP or Director before going live
4. Some companies have formal processes, others are more informal

---

9. Handle post-launch items

After the product is launched (and the celebrations are compete 🙂 ), it’s time for the TPM to handle the post-launch items. This includes everything needed to make sure that the project is well-received by your target customers, including their feedback. The goal is to make sure that the next version of your product is even better and more successful.

Deliverables

1. Monitor all feedback channels (e.g. calls to the support team, any way to provide feedback in the project website, App Store, forums… any way that people can provide feedback for the app)
2. Work with the PM to prioritize the incoming feedback and stack rank them against all other features that are being planned for v2
3. Maintain backlog with a list of prioritized features that will be implemented in the next release. The format o the backlog could look similar to the following:

Stack Rank	Project	Feature	Lifecycle	ETA	Documents	Estimates
1	Dashboards	Resize dashboards	Not started	October 2021	PRD, Design doc (links)	Backend: 2 months Frontend: 1 month

---

10. Portfolio Management

It is important to note here that TPMs work on multiple projects at the same time. Each project in a different phase, e.g. one might be starting, multiple in progress, some might be at risk, etc. Also, each project will have a different set of engineering teams, dependencies, etc.

I’ve covered how to handle one project, but I wanted to quickly touch on the fact that the complexity of each TPM’s work gets multiplied we add more projects. There will be lots of incoming questions about details related to each project from all sorts of stakeholders. At the same time, as the number of projects increases, it won’t be possible for the TPM to monitor all projects in the same level of detail. That’s why it is important for all TPMs to proactively expect these questions and manage the portfolio efficiently.

One way to handle this complexity is to create a single repository (e.g. a portfolio website) that provides answers to the most common questions that a TPM will be asked, e.g.:

1. OKRs and status for each project (red, yellow, green) with some commentary
2. Roadmap with upcoming launches
3. Previous launches
4. Risks
5. Dependencies for all projects (including key stakeholders from each team)

---

Question: How do the deliverables and job expectations change, as the TPM becomes more experienced?

In this blog post, I’ve covered the main tasks of a TPM. However, as the TPM becomes more experienced and goes up the hierarchy, there is a different set of expectations. In most cases, the skillset that helped a TPM excel in one level, might not be very helpful in the next level. For example, junior TPMs might love to be more hands-on with a project and technical. However, as a Principal TPM it is more important to manage a large number of projects, so it’s important to not get lost within the details of a specific project.

Another aspect that changes is the expected impact. A junior TPM is expected to impact a project. However, a Principal TPM is expected to impact multiple orgs. I’ve tried to create a quick summary of these expectations in the matrix below.

Experience Level	Company Title	Expectations
Entry-level	L3 (Google, Facebook), L4 (Amazon), L59-L60 (Microsoft)	Needs supervision. Executes established processes
Intermediate	L4 (Google, Facebook), L5 (Amazon), L61-L62 (Microsoft)	Independent. Creates and manages reliable project plan for 1-2 projects
Senior	L5 (Google, Facebook), L6 (Amazon), L63-L64 (Microsoft)	Multiple projects and teams. Mentors junior TPMs.
Principal / Staff	L6 (Google, Facebook), L7 (Amazon), L65-L67 (Microsoft)	Initiates projects across multiple orgs
Partner / Senior Principal	L7 (Google, Facebook), L8 (Amazon), L68+ (Microsoft)	Initiates projects that impact the whole company

---

Summary: TPM deliverables for this project

In this section, I wanted to provide a quick summary of all the deliverables for a TPM.

1. TPMs own:
   1. Project plans
   2. List of OKRs/goals with their risk and commentary
   3. List of upcoming and previous launches
   4. Long-term roadmap for the team
   5. Risk log for each project
   6. Status reports
   7. Backlog (together with the PM)
2. TPMs provide input to:
   1. Product Requirement Documents (owned by the Product Manager)
   2. Design docs (owner by the Technical Lead)
   3. Monthly/Quarterly Business Review slides (owner by the Product Manager)