Product Operations and the TPMs
Being a technical program manager means that sometimes you need to step in and organize the software delivery model, even if this is outside your official job description.
Usually, the product management team's capacity is filled with many low-priority tasks, wasteful activities, and non-optimized processes. This prevents them from focusing on one essential goal - delivering value to consumers.
I will focus now on three activities that we can do together or instead of a product operations team.
A disclaimer:
I want to keep that short to discuss the problem areas and their solutions. If you are interested in the details and want to go deep into the topic, please comment, and we will make this happen together.
I'd like you to build a holistic view of the software delivery system to explain our current delivery model's roles, responsibilities, and gaps.
Problem:
How often do you jump into a program while it is running? How often does your team hire a new person with a crucial role? Yeah, that happens a lot.
Solution:
This task might relate to a Value Stream Mapping exercise for some of you, and you are right. I recommend doing something basic like a diagram that charts your delivery process.
Then, put the responsible parties first and metrics to visualize how you track the value delivery.
This is a great conversation starter to go and build or help build the Value Steam Map. The TPM should encourage the program leads to focus on creating such an artifact. By having it, you could save much trouble later.
Focus on unifying the tools (roadmap, prototyping, user interviews, monitoring, OKRs, etc) and approaches we use between the product and the other parts of the organization.
Problem:
The team uses various tools while delivering the same program. The mismatch could bring problems and delays:
We need more time to understand the goal of the sprint or the delivery.
We lose time and energy by switching context from a tool we know to a tool we need to learn or have with a different UX.
The roadmap view is confusing, so we need to figure out what to expect after we finish the current delivery cycle.
Only some team members can access all the tools for security or administrative reasons.
Different teams have different OKRs, which do not connect at the end, and the quality of the product is harmed.
Solution:
TPM could face the challenge by owning the tech stack of all such products for your program, providing training, and aiming for alignment. In some of my gigs, such activities took half my time.
If this is not feasible, they need to work with the teams responsible for that alignment while considering the operational costs. Could you ask yourselves - what needs to be optimized and how this will help your program? What's the gain?
Working closely with the rest of the organization to ensure that the communication gates are in place, especially with Engineering, Quality, and Release.
Problem:
The product team needs to communicate better with the rest of the organization and within.
Communication between the product manager and the product owner was not happening, so the team delivered results they believed were correct. The output was not aligned with the product strategy at all.
Product leaders communicated the high-level details and needed help to justify why this is included in the roadmap.
The product was not involved in the release process. When asked what we are delivering with this release, they could not confidently respond.
Solution:
Communication is a two-way street. TPMs must ensure that everyone is well understood.
This could involve activities such as:
Organizing sync meetings where you feel there is a gap
Value flow diagram to ensure that everyone understands the value we deliver and how we measure it.
Arrange training and workshops to provide ideas and methods for the team to solve this independently.
Stepping into a new role if needed - for example, release coordinator until all the release process unknowns are provided.
Heavy metal
As usual, I'll share one song that inspires me to improve my work, especially with operations.
This one is called "Communication Breakdown" by Led Zeppelin. What a song title to accompany my post about communication issues! :)
Why keep reading this?
I am a people-centric Technical Program Manager. This newsletter is different because:
It shows real-life examples from my career, which differs from the general TPM profile.
It cuts the general knowledge topic you could discover in blogs and newsletters created by much better TPMs.
It shows the new things I learn almost every week.
It contains inspiration from the Heavy Metal music domain.
It examines topics like Mental Health, insecurity, the creativity lock, and more, which are part of the TPM world, but only a few colleagues are open to discussing this.
I am also reachable on various channels and love helping people. Some of them allowed me to share the problems they had and what I advised them.
Thanks!
Bogo