Why Product Managers should influence the team’s growth

Jagan
7 min readMar 3, 2021
Brandon Chu’s -” The First Principles of Product Management

A couple of days back, I was on the clubhouse app(ID: jramesh) listening to some of my favorite PMs on this very topic, but in a different direction, and couldn’t find an opportunity to contribute among the legends on the stage! So here I am :).

In this piece of writing, I will explain why if you are a Product Manager, you should influence improvements and changes. I have worked with teams ranging from 2 to 53 wonderful people in the past, and here is what I learned.

Here is our agenda,

  1. Why Product Managers?
  2. Some Examples
  3. Inspire to Influence

Why Product Managers?

One of the advantages of being a Product Manager is that you have to be all over the place. On Monday, you may have a conversation with the Product Marketing Managers to discuss how you want to position your Beta release. On Tuesday, you may have a conversation with your engineering organization grooming backlogs. On Wednesday, you may have a call supporting the Sales organization jumping on a customer call to educate on why we did what we did. And sometimes apologizing for the recent downtime too, we call it the elephant dancing. On Thursday you may be involved in a conversation with other Product teams to discuss the impact on their roadmap due to the sudden priority changes. And on Friday, you will be involved in one of the “Lunch and Learn” or “Friday Funday” or “Weekly one-liners”.

If you don’t believe in what I just said, take a look at a Product Managers calendar, and if you are a Product Manager, color-code your calendar invites to reflect certain departments. It will show you how diverse your week looks like. Constantly context switching and pulled into unexpected conversations. To me, this is FUN! Because I don’t like to do just one thing, just like you probably. Sometimes, context switching does help in productivity and brings in a whole new perspective to a problem. Don’t get me wrong, I do spend my Sunday evenings coming up with 3 to 5 things to accomplish that week, and those are mostly the work that involves creativity, so I tend to spend an hour in the evenings to accomplish, after a peaceful meditation. And so far, it has been working great.

Coming back to the topic on Why Product Managers? Well, as you may have found out, Product Managers get cross-functional aggressively. You may have to learn how the Marketing team is using Monday.com, and how the Sales team structures a call that is more engaging and value-adding to customers. You may also work with other PMs in the team jumping on their Grooming call and seeing how they manage their processes internally.

This allows us to look at other teams and how they are doing things. It doesn’t have to be only about “Process” improvements, as PMs, we are sort of the CEOs of the product, and we have to think about solving problems at any given level. By bringing the secret of other team’s success to your Engineering organization or by sharing the presentation deck from Sales Teams to Professional Services, or even by learning how the backlog is structured before the grooming call. You don’t have to be a PM to bring in change, but you as a PM have much more advantages and visibility within the organization than many others in the company.

Some examples

In 2018, when I graduated from College with my Masters, I was interning at Genesys as a PM Intern, managing SMS-based CX and Campaign management tools. I had no background in Product, but when I learned about it, I knew it’s exactly what I wanted to do. Anyways, right after my Graduation, I was given a call by a hiring manager within Genesys asking if I am open to joining their team. I loved the work culture there, and there was a lot more to learn from all the PMs. When I joined the new team within a month, each PMs were siloed. Working in that team for a few weeks, I missed the clarity of what we are doing as a team to make better decisions. I proposed we all add a small agenda in our weekly meeting to talk up to 3 things that they would like to share. And it was completely voluntary. But, it did help everyone to learn what challenges other PMs are facing and brainstorm ideas to solve that problem. A small change that I decided to influence from my experience in working with other teams within the same company.

In 2019, when I took over a couple of new products, I started working with 3 other engineering teams and my calendars started filling up with more tactical meetings. Working with them for a few weeks, I start tracking the amount of time each of the unproductive meetings we had because of burndown. Engineers don’t like to be in meetings, let alone unproductive meetings. As a PM, I was able to bring in the process that we follow in a different team and how it helped us with this problem in the past, we were able to get back more than 2 hours a week off of the meetings, yet never lost the visibility we needed. An excel did the trick, at least for that time.

In 2020, we also found out that such a large Engineering team has no visibility on how we are doing as a Product. Similar to how the CEO would give a presentation on how the company has succeeded in a quarterly All-hands, as a PM I decide to share similar knowledge on how we are doing as a Product to my engineering teams. And talk about the short-term and long-term vision for the product. This allowed Engineering teams to propose new ideas and many of those ideas have improved our decisions within the Product team. Some of those ideas were shared with other product teams and helped me influence changes cross-functionally.

Inspire to Influence

It is hard, but the outcome of these changes can be rewarding. Here are some of my tips on how to influence changes. And how to evaluate if it’s worth it.

First of all, we must understand what worked for others, may not work for us. So the first thing we should do is set expectations. What the next steps are on attaining those success metrics, and the next steps will be if we fail. Everyone likes a change that will make things easier, but the reluctance comes from the unknown. Setting expectations that, if we fail to achieve what we would like to achieve from the change in a given time, we will reconvene on if we want to continue or not. This feedback loop improves the confidence in teams that we listen to everyone’s opinion. Bringing back the example of the Agile process, it may take 3 to 4 Sprints to understand the velocity, for Friday Fundays, it may take 2 Fridays for people to show up.

Second of all, you have to put in 200% if you want your team to give 100+%. Anytime I propose an idea, I make sure I do the groundwork, prepare content on what research I did, and why I think that idea will help us. For instance, when it comes to the Agile process, you may talk with other engineering leaders to understand what your Engineering leader can follow to get to where you want to be as a team. Is it better for them to take over the retrospective portion of the call? You can do this research on your own by reaching out to people. It’s taking that one extra step that shows that you are taking ownership of it. Inspire to influence!

Third of all, set short terms goals. Setting short-term achievable goals can motivate your team to accept the change. If you don’t know what your goal is, conduct a quick survey on what they think the outcomes are from that change in the last few days/weeks and make your decision. There might be a lot of work involved in proposing an idea, only to understand that the outcomes that you expected didn't happen and you had wasted your time and your team’s time on such a change. That brings me to the failure part of this process.

Finally, understand that it’s okay to fail. As PMs, we are trying to solve problems, and many times the solution that you came up with was not the solution for the problem. But, trying is very important. Learning from it is even more important. You may have found something new while pursuing this idea that may have helped a different problem. And, it’s never too late to stop something that’s not working. Just like how we EOL (end-of-life) a product, we could end of life a change and rollback to the previous version as a team. The key is to do the right thing in the right way at the right time to be on the right side. I don’t follow politics much if you are wondering.

Conclusion

If you are a Product Manager, working with cross-functional teams can help you grow the visibility in the organization, their practices, and what you can learn from other’s failures. In my humble opinion, Product Managers are a lot like the CEO of the Product, and we have to be open to find problems and fix them at any given level. I hope this helps, my DMs are open, and would love to connect! Twitter: @jagannramesh.

What changes have you brought into your team? And did it help?

--

--

Jagan

Senior Product Manager at ZoomInfo, Founder @ Magos AI