Over the past decade of advising, managing and mentoring PMs, the most common piece of advice I’ve given is simple – don’t change teams, yet.

I’ve found that sticking power is one of the things most directly impactful on my success and believe the sweet spot for PM roles is about 4-6 years in an area. I see many PMs want to change teams after 1.5-2 years though, which I believe is too early. I think you can gain a lot by spending another few years in an area.

Why is that? Let’s explore how staying in an area can help build your PM muscles.

Reps Take Time

A product rep generally takes 12-24 months, so if you don’t stick around a while, you won’t get to do a full one.

What is a rep? The cycle of identifying a problem, learning about it, coming up with some hypotheses of how you can add value, iterating on a product prototype, iterating on the go to market and then once there is product-market-fit, figuring out how to scale.

There are some places you can go faster, but many that are even slower. I’ve found B2B and platform work to be slower, but also more impactful.

In my experience, a PM learns the most about a domain in the first 3-6 months of a project, but learns the most about the craft of product management in the back half of a rep.

The reason is simple, the back half is where you get to look at the data from the results. That is when you find out which of your hypotheses were true, how good your research process was and what you need to change to be better next time.

Too many PMs feel the domain learning slow down and think it is time to move on to another project. I think that does them a huge disservice. You don’t want to end up a PM that has domain expertise in 10 things but is little craft expertise.

You Might Only Solve Low Hanging Fruit

Some problems are easier to solve than others and if you stay on teams a short time you might only solve the easy ones. This robs you of the chance to grow your skills.

It isn’t bad to solve the low hanging fruit problems first. Prioritizing that certainly makes sense on a project. But great PMs can also solve harder problems and if you move on too quickly, you might never have a chance to even try those problems.

You Don’t Get to Learn About The True Cost of Your Decisions

There is an old saying in software engineering that “code is written once but read many times” which emphasizes the importance of spending time to write code well and add comments to make sure future readers aren’t wasting time interpreting your messy code.

In product I think the parallel is a product decision is made once but paid for many times. If you make a product decision and leave the team before customers are using the product for a long time, you won’t get to see how the product decisions you made impact the maintenance cost of the software. How confusing is that for customers? How much maintenance work is there for the future dev team? How many pagers does it set off? How many support tickets are raised?

Good products last a long time and good product managers make decisions that let the software last for a long time without growing exponentially in cost.

By moving on too fast, you’ll miss getting a chance to learn about that stage of the process and you’ll miss out on tuning that decision engine.

You Can Hide By Blaming The PM That Came Before You

There is an old joke that the first thing every electrician does when they look at some wiring is blame the last electrician for doing a bunch of silly things. They then proceed to do some silly things and the process repeats.

I’ve found PM to be similar.

There is always a temptation to blame shortcomings in a product on things that predate you. Sometimes those are true things, but other times you’re just making poor excuses for having failed to notice something or invest in it earlier.

When you’re the PM that built the current thing, you can’t hide behind that excuse anymore. Product failures that come up can only be blamed on your, which forces you to think about what decisions you previously made that caused you to end up in this situation and whether you could have done anything differently.

Sometimes the learning is that you made a poor decision. Sometimes it is that you weren’t curious enough and didn’t validate all of your assumption. Sometimes it is that you didn’t listen to someone that warned you about this failure risk.

Either way, reflecting on that is one of the juiciest learning experiences you can have as a PM. Even better, you get to those learnings quickly because you don’t have to spend any time ramping up on the domain. This is a critical benefit of doing a second rep on the same problem.

You Can Get Too Much Credit That Belongs to the PM That Came Before You

The flip side of the above is that some PMs benefit greatly from good decisions that predate them.

You are usually not the first PM to look at a problem. Sometimes you’re joining a growing team where you’re taking over in flight work from your manager or backfilling a role a previous PM covered. Either way, there was something in place – a strategy, a plan, a PRD, maybe even most of a product.

I’ve seen a lot of PMs join projects that were already in motion and simply hold the ship steady and then take credit for it.

To be clear holding the ship steady isn’t bad – it is certainly better than crashing the ship – but you miss out on some of the important parts of PM when that is all you do.

I have known PMs that expertly hopped from one success to another a few times before they actually hit something where they had to struggle themselves and that reality was then harsh medicine.

Doing a second rep in an area forces you to struggle because you’ve burned through all of the existing good decisions. The situation has progressed and so it is unlikely a previous PMs decisions will keep working. That means you have to reconsider the strategy, make decisions about where to expand, etc. This is the important work that helps you grow as a PM.

So How Long Should You Stay on a Product?

In my mind the perfect PM tenures is about 4-6 years in one area with at least two major chapters.

When I’m hiring, I look for people that have stuck around that long in an area and succeeded – gotten promos, launched things to GA, hit their revenue numbers, etc. That tells me I’m looking at a PM with grit, who has learned some things fully and who didn’t just get to take credit from the PM before them.

As an example I’ll offer my time at Google. This was on the shorter end of what is ideal and I really could have stayed longer (and I nearly did, but alas Databricks made a very compelling offer).

You can see a continual focus (cloud contracting) with increased scope over time (pricing and subscriptions were added later) and two promotions (notoriously hard to get at Google).

Why Not Longer?

This article has been all about how most PMs don’t stay long enough in an area, but I’ve found some PMs are more naturally inclined to stay too long.

This probably deserves its own full blog post, but in short, it is too easy to get comfortable and add value simply for your knowledge if you stay too long. That atrophies your ability to do a full product management rep.

Periodically diving into the unknown is important if you want to be able to do it again, so I would strongly caution against staying in one area for more than 6 years unless there were other things that were changing; scale, taking on management responsibilities, major technology disruption, etc.

Conclusion

PM reps take time and if you want to grow to be a great PM it is important that you stick around long enough to complete multiple reps. Working on the same problem area again forces you to solve more than the low hanging fruit, to learn the true cost of your decisions and to have your success tied to your decisions, not that of the PM before you.

Leaving a team and working on something new is exciting, but I believe there is a lot of upside to resisting the temptation to leave and instead doubling down on an area you’re already ramped up on.