Succeeding as a New Product Manager

Problem

It’s no surprise that remote work has gained immense popularity over the last year, and so team challenges have also increased. Struggles do remain when it comes to connecting and communicating with people while motivating them to work towards our goal. A lot was going on already, and on top of that, I’ve switched teams. Besides, living on a different coast and working for a widely dispersed company is challenging on another level. We did not have an office in Los Angeles (where I’m based) and I joined a team in New York. I never met anyone in person from my team, and being an engineering team, they have never had a PM before; so, I’m their first PM.

It has been an exciting transition for the team itself. They have always been self-sufficient, but no one has ever done road mapping and planning, for which I had to pick the pieces. Many of them in the team had leaned in to do the product work, and I have been trying to balance taking all of their opinions and things that they have been very passionate about. In tune, they have also been thinking about what to do in the near future, showing super enthusiasm. The challenge was: how could I balance a super enthusiastic team with way much to be done instead of what should be done.

The careful balance of their opinions was really important because they have been working in the team for a while but didn’t have a PM. So, as their new PM, I had to take all of their priorities into consideration and understand that I was asked to join the team for a reason. I fell into the triangle of balancing team desires in terms of road mapping with company priorities.

Actions taken

For me, the core thing, especially joining remotely, related to this problem, as I was fortunate enough that the team was relatively small. There were around 7 engineers on the team, which was very small for the large company that it is. What I did immediately after joining the team was make sure that I was not just someone on Slack and that if I was going to make changes, they should first know who I was.

In that regard, I got to know everyone first through quick 1:1s 一 not to talk about work, but to get acquainted with every member in the team, which included talking about what they were doing outside of work. Being a PM is first about building relationships because a lot of the job depends on that. I did not want to intrude as a “new person” who came in to make changes. Instead, I wanted first to become a person they actually liked and match their energy.

One of the first reasons I switched teams was to kick heavily with the company priorities in the following year. Therefore, I had a bucket list of things that the senior leaders wanted and a bucket of things that the team thought was important from the previous year as they’ve been working on it. And then, I also had a list of things that I thought were going to be necessary.

Being able to make the team feel that they are included was equally important. My primary goal was to provide an ideal strategy for the team, while the second priority was to make sure that I don’t end up making enemies in my team. Without making it a “hostile” takeover, I got the team together to do a virtual brainstorming session.

First, their information was valuable, but at the same time, I also wanted them to be a part of the overall strategy. Of course, I did not want them to feel that it was me telling them to do or the leadership telling us what to do. I provided a readout to the team that helped them keep a record.

Last but not least, I was overly communicative. As a new person on the team, this was something significant. I communicated every update and progress on the strategy, and in return, they told me how awesome it was to feel included with the product team and work collaboratively. However, in terms of building a new strategy, I found that I would always ping them even if it felt uncomfortable to me. Whenever I added something in the Google doc, I would go ahead and ask them to check it out.

The overarching thing of all these started by communicating with everyone in the team, particularly 1:1s. For instance, if I noticed an engineer replying to Slack messages at a bullet speed, I would share with them using the medium.

Lessons learned

• If you feel that you are annoying someone with team updates, you probably are not. In reality, no one is getting enough updates remotely. In essence, understand the communication styles so that nobody feels “annoyed.”
• Conduct some brainstorming or information gathering sessions with the team. This will make the team members feel that you are doing some tangible work towards the strategies.
• Be comfortable with sharing things early on. I have learned it the hard way because we had lost the whole concept of being close to someone in an office, and everything felt a lot more formal. It became a net positive on both sides to share drafts early and often to gather feedback from the team and make them feel included.