Don’t be the Glue

Written by Adrienne* and Alexis

The common rhetoric is that product managers should act as the glue between engineering, design, and sales. This mindset was a trap. When I* first started as a product manager at Tesla, I was so set on being the glue -- being the conduit of all information and communication, shuffling mocks and comments between engineering and design -- that I found myself working many hours while not getting a lot done. While I felt important -- without me, the team would not be able to operate -- my aspiration to be the team’s glue actually made me the biggest bottleneck for my team and took away time that I could spend doing things that product managers are best positioned to do -- to look at the forest.

Most of my days were spent communicating. I asked myself: How can I communicate, and what can I communicate so I can save time in future? That way, I’ll have time to do things only a PM can do, such as strategy. That’s when I started thinking about team infrastructure, and creating pathways to reduce my time being the sheer connector.

3 ways to lay down infrastructure so you can move past being the glue

1. Weekly Updates

I think of weekly updates as ready-made information links I can send to anyone who asks. I ask myself: what are the things most people who are not intimately familiar with my team will ping me to ask about in the next week (or the cadence of the updates) related to an update?

2. Metrics

When most people think of metrics, they typically think of a metrics dashboard on a website, but it can also be surprisingly helpful to collect metrics by hand. For example, if your team is constantly fighting fires, you could track the number of fires per month. Over time, you’ll see patterns in the fires you are fighting, allowing you to design ways to systematically attack them. For example, you might notice that you’re frequently finding out about bugs through customer reports, and these are creating fires that your team is constantly rushing to fix. You would then draw patterns to identify a gap in your logging strategy, and then augment your logging strategy to reduce the number of interruptions, and instead catch these early on in your bug triage.

3. Documentation

Another focus was documentation so I could spend less time answering questions and redirect them to the documentation. For example, I used to receive a lot of inbound from customer support specialists, the marketing team, and engineers and spent a lot of my day sorting and triaging them. I soon realized that because there was no clearly defined path for how to report an issue, others did not have confidence that the issue would get resolved and feared their Jira ticket would get lost in a black hole. Once I documented the path for how our team received and resolved issues, I had many hours free that used to be spent individually responding to each stakeholder.

While these may all seem obvious in hindsight, it can be easy to become the glue and stay the glue — feeling squeezed for the time and energy necessary to take your team and product to the next level.

Bad PM vs. Good PM vs. Great PM

Being the glue is not the end goal

It’s easy to believe that being the glue is the goal of a product manager, but being the glue is only table stakes. As a product manager progresses in their career, what they spend time on shifts. You may start with 80% execution and 20% strategy, but you have to quickly get to a place where this number is flipped, and you are spending 20% on execution and 80% on strategy.

The only way to flip this number is to spend less time being the glue, and more time focusing on ways to make customers happier, save the business money, or drive sales.