TL;DR - The product management role is a bit like a lava lamp; things are constantly moving and changing shape. While there are common patterns, from one role to the next, PMs have to change shape to meet the needs of the product and team they are building. No two roles they take on are exactly the same.

As I help people newer to the product, they often start by looking for a checklist of what they should do. And I have seen more articles than I can count advising on the complete list of product management skills required as if every PM role requires the same set of skills. Yes, there are some basics, like communication, curiosity, and data-driven mindsets, but what you need to do as a PM changes from company to company and from role to role.

Fill in the White Spaces

One of my favorite PMs always says product managers need to fill in the white spaces. I love this because when a PM starts a new role, they often need to figure out where and why a team is struggling and fill those missing pieces, or at least better enable the team to fill in those white spaces for themselves.

From White Spaces to Lava Lamps

As I was trying to help a relatively new PM learn how to focus on what their team needed, I found myself using the lava lamp analogy. To fill in the white spaces, a PM must constantly be changing what they do for their teams. By changing shape, they can fill in those white spaces. And as soon as those gaps are filled, they need to take on another shape to tackle the next challenge facing the team.

For example, they may be heads down on execution to help achieve a goal, then maybe they need to work with legal to confirm the safety of the next marketing campaign. When they move to a new team, they might not have legal challenges, but the technical challenges require them to take another form to help the engineering team without over dictating anything.

Lava Lamp examples from my career

• 0 to 1: Built an e-commerce site that was 12% of the business within year one of launch. Sometimes I had to learn new technologies. Other times I was managing designers directly.

• Growth for a Recommendations platform. I was responsible for identifying why users weren’t getting recommendations. Then I had to pivot to selling our product across a matrixed organization.

• Experimentation at Yelp. One minute I was advocating for healthy friction to help the data science team; the next moment I was focused on getting executives to encourage greater risk-taking from product teams.

• Firefighter for Google. I started as the lead for three junior PMs; then I was asked to manage a partner who refused to move on to a new platform. After that was finished, I joined a team where designers and engineers were in constant battle, and I had to get everyone to work together to achieve a common goal.

The above list contains examples where I was constantly shifting what I did to the team’s needs to drive successful changes in the product or to launch new products.