How to be the first product manager on a team
Co-written by Adrienne* and Alexis
I* was recently in a situation where I was a product manager on a team that has never had one, and I needed to show snippets of what a PM could do. Being the first PM on a team or at a company can be hard -- it’s common for team members to not see the value of having a PM, worry about a rogue PM rocking the boat with no benefit, or for the existing team lead to even feel threatened.
In the absence of other PMs, it can be easy to try and add value by doing what everyone else is doing (don’t, this is a trap). I learned the hard way. I noticed we had a lot of open bugs and features that the engineering team had not started on yet and having majored in Computer Science, I decided to ramp myself up on Golang and started writing code. While I was merging code and closing many Jira tickets, I realized my attempts were having the exact opposite effect -- I ended up inadvertently shoving many risks under the rug. The team grew increasingly stressed as we neared our deadline, and when we shipped the product, we received a lot of negative feedback from customers.
I realized the best way to be a PM on a team that’s never had a PM before isn’t to model what other team members are doing (coding or designing) — rather, the best way to approach situations like these is the exact opposite: to have even more conviction in your role and to double down on that. PMs can provide value by doing things that are easy for PMs but hard for other team members. Specifically, there are two ways:
1. Know about what other teams are working on to increase your team’s scope.
Case Study: Alexis was staffed on an infrastructure platform team focusing on technology for AR capabilities across the company. When Alexis joined, the team was only working with one team and putting all their effort towards optimizing the experience for one customer. Alexis saw that she could immediately add value through bringing more internal customers onto the platform, so she pitched the platform to product managers across the company. Alexis leveraged the strong network she already had built within the company and made a shortlist of the teams that might be interested. Her pitches brought immediate value for her team by increasing its scope and the impact of its work. This is the type of work that comes naturally for PMs, but is harder for engineers and designers who work with a smaller number of people on a regular basis.
Case Study: It doesn’t have to be just finding more customers for the product you’re building, it could also be connecting dots through identifying teams that might have overlap with your team’s area. When Adrienne was launching voice assistant with her team and needed to build a natural language processing (NLP) pipeline, she identified other teams at the company that might need an NLP pipeline and learned the Customer Support team was working on building a similar NLP pipeline for automated chat support responses. She reached out to them to see if they could leverage the existing pieces their team had built. This is a way to create a lot of value by saving the company time and money, and also a way to multiply the effects of the products your team is building.
2. Ensure the team is focusing on the right projects by setting the bar for “good enough to ship.”
Sometimes you might find that the status of things is already good enough and there is no longer a need to continue your efforts towards it. Great product managers identify the point of diminishing returns for the team.
Case Study: Alexis was working on improving the quality of augmented reality (AR) filters and the key quality metric was latency/loading time. The Engineering team was working on driving the number down, but they were removed from the reality of what that means for users. Can users really tell the difference between a few milliseconds? To define the acceptable bar for latency, Alexis analyzed data to figure out the correlation between latency and retention. She learned that when AR filters take more than a certain number of seconds to load, over 70% of people dropped off and never returned to try another filter. Getting the latency to that threshold number of seconds then was critical, because doing so would save the majority of users from churning away from the product -- but going much below that bar was not as meaningful, because engagement returns flattened out.
Defining the “good enough” bar can sound scary because it feels arbitrary, but good product managers provide evidence for exactly why the bar should be set at that level:
Run competitive benchmarking to see how competitor products perform and set a bar just above or below that
Run data analysis to articulate the tradeoff equation for one metric vs. another important metric.
Setting this bar drives focus for your team, because it doesn’t make sense to spend a year trying to drive a metric down if it is already good enough from the customer perspective.