Updated: Feb 6, 2021
If you are looking to find a new TPM opportunity, you have probably looked at many TPM job descriptions posted on LinkedIn and other similar sites. Often they list out a set of responsibilities expected from the role.The core responsibilities in every TPM job description fall under the following categories.
Program planning and tracking
Communication and execution
Collaboration and alignment
Today, I want to dive into what these TPM responsibilities actually encompass. My goal is to help aspiring or existing TPMs get better insight into the actual job requirements standout during resume reviews and interviews. As a TPM, it is important to be detail oriented to ensure smooth execution and delivery of a program. Similarly, focusing on the details beyond the literal phrases in a job description will help you understand what the team is looking for in a TPM.
When you see a broad statement like “Develop project schedules based on product requirements, technical challenges, and business needs”, think about all the actions a TPM needs to take before they get to finalizing a project schedule or delivering on a goal. A TPM’s role is not just about creating a project schedule and beautiful Gantt charts with every project dependency and milestone laid out. An experienced TPM knows that a project tracker is the outcome of all the hard work that goes on behind the scenes. It’s merely a communication tool rather than the core of their work.
Let’s look at a subset of responsibilities listed in an actual TPM job description and work through what ground-level actions each of them requires. For this post, I will focus on program management aspect of TPM job requirements.
Develop project schedules based on product requirements, technical challenges, and business needs.
In order to develop a realistic schedule, a TPM has to understand the problem space, business objectives and how the proposed solution intends to meet those objectives. A TPM should be able to take a complex and ambiguous problem and break it down into manageable pieces. (example: Let’s take Google Maps as a program example from my previous post. The business objective may say “Launch Google Maps”. As a TPM, you will need to understand the Maps domain and provide context. Is this a brand new functionality, or are you launching in a new locale or country?)
Once TPM identifies key stakeholders (like product, engineering, testing etc), they will drive discussions with multiple teams to define the program objective and list out potential projects that will be part of the program (example: new technology introduction, build prototype, re-architect system, scale to multiple countries) .
The TPM will outline initial scope of work and align on the optimal solution that can be delivered within required time parameters. This requires the TPM to have domain expertise and understand the technical details so that the TPM can correlate the technical impact of product requirements on engineering teams. Oftentimes, TPM will need to negotiate between the two teams to reduce critical paths so that the program can be delivered on time from an engineering perspective and also provides a valuable customer experience. During this requirements understanding phase, a TPM should aim to bring clarity on the requirements with all stakeholders and think about areas like testing and release requirements. (example: if launching Maps to a new country, does the scope involve providing basic maps and driving directions, do we also launch traffic information or integrate local listings; is mapping and calibration a dependency for the traffic team, do we need to understand country specific privacy/legal regulations and so on…)
The TPM needs to have the right level of technical/product knowhow to contribute effectively to design discussions, suggest alternate paths, propose scalable future-proof solutions, understand inter-team dependencies, sequencing of work and time estimations to complete the work. (example: will our architecture support x million more users if we add a new country, can we launch the next country faster without refactoring code)
The TPM will then produce a work breakdown structure outlining dependencies, constraints and estimates. A TPM may need to go through multiple iterations of above activities in the initial phase of the program to arrive at a realistic program plan and schedule that is acceptable to all stakeholders including program sponsors and leadership.
As you can see, a good plan ensures that you have a good foundation to execute your program. But this phase is especially important because it gives the TPM an opportunity to showcase technical and product thought leadership. Your goal during planning should be to simplify the path forward for your team.
In the next part, we will look at responsibilities around program communication and execution. Stay tuned...