Exploring what makes a TPM thrive

This topic comes up in every interview I’ve conducted for the TPM position. So, I’ve put some thought into everything that a TPM does. The items I’m going to discuss are not qualities specific to a company, team, or variation on the TPM role but are transitive from one position to the next.

Driving to get things done

First and foremost, for a TPM to thrive, they need to focus on pushing forwards and getting things done. It sounds a bit cliché as though you are reading it from a job description, but it is resoundingly true. Our innate drive to solve roadblocks, build the plan, mitigate risk, and drive towards deadlines are key to a project’s success. We don’t want to lose momentum because the second we do, we risk losing all progress and having to start over. This may be because, during the time the project is blocked, the individuals working on it may move on or lose context as priorities change, necessitating more time to ramp back up. It is in our best interests to resolve issues quickly because keeping engagement, focus, and motivation facilitates an immediate and more dedicated response.

This is a trait that isn’t always present in adjacent roles to the TPM, such as the development manager and the product manager. I believe this is because the primary function of those roles is different from the TPM role. For instance, a development manager’s main focus is their people, and a product manager’s focus is their product. For the TPM, our focus is the project or program – this is what our drive and perspective hone in on. A blocker in a project blocks our main purpose, so it is extremely important to us. This same blocker may be overshadowed by a performance review or by the bigger picture of the product roadmap in the other roles.

Driving towards clarity

The second trait that makes us thrive is when we take that drive, and we drive towards clarity. This trend to clarify can come at any phase or stage of a project or program. It’s easiest to see during the requirements and project planning phases, as clarifying is a main attribute of the planning phase – clarifying requirements, clarifying scope, clarifying the communication strategies, important stakeholders, and so on.

However, driving towards clarity doesn’t stop there. Every roadblock we encounter requires us to add clarity. First, we ask about the problem, the people or systems involved, any proposed solutions, and paths to escalation. Then, we take all of this data and define the problem and solution. We define the problem to make clear that our solution is fixing the right thing. Think of it as asserting your acceptance criteria for a development task.

One way in which we drive clarity plays off of the last critical trait to make a TPM thrive, the communication bridge. We’ll talk a lot about communication throughout this book, but this is a special form of communication that takes our technical background into account.

Communication bridges

Since we have a technical background, not only can we talk with our developers, but we can also understand them! This is critical for our ability to understand the tasks it will take to complete a project and to push back on estimates or provide feedback. This skill also allows us to explain the work of our developers to other stakeholders. We can take highly technical information and transform it into language that a VP of marketing will easily understand.

This ability to translate from technical to non-technical works in reverse as well. In fact, we rely heavily on this early on in a project during requirement analysis. We take business requirements and translate them into functional specifications for our development team. We understand the business and their needs, and if required, we understand their knowledge domain. For instance, if our business team are accountants, then we have to understand accounting – what they do, what pain points they have, and what jargon they use. Knowing the domain isn’t always required to land a job, but the ability to learn the domain on-the-job is key to being a successful TPM.

By understanding our business and their needs, and our development team, we effectively bridge the communication gap between business and technology. From a career growth perspective, this soft skill is by far the most important skill to perfect. Due to this, it is also the skill that shows up most in the growth category for career progression. To improve this skill, ensure you practice active listening by staying engaged with the speaker, affirming your understanding through body language, and following up with questions. This is a skill that I am still perfecting myself. I grew up in an environment where it was common to interrupt or talk over others during particularly engaging conversations. Though this can be fine among friends when talking about trivial matters, this is very disruptive in a work environment – especially given that at work, we are often trying to solve a problem. When you interrupt, you aren’t taking in what the other person is saying. Instead, you are looking for a space in the conversation to insert your own thoughts and looking for this opportunity prevents us from fully taking in what the other person is saying. Active listening will ensure that you truly understand the point of view of the other person. Often, this information can build on your understanding of their problem. Follow-up questions can fill in the gaps in your understanding to paint a more complete picture of the situation. Over time, you’ll understand your business teams and their domains, which, in turn, helps you become a more effective communicator. The better you understand the pains of your business team, the better you can relay that to your development team in your functional specifications and conversations about scope. The more they understand, the better the outcome of the software and the more successful the project will be.

We now understand what makes a TPM thrive at their job, as well as the fundamentals to accomplish that job. Next, let’s compare the roles and responsibilities of a TPM to other roles that are often found adjacent to it.