What do first time growth product managers get wrong, and how do you recommend avoiding those traps?

This is a tricky question. Lots of program managers struggle with prioritization and impact analysis. They also struggle to get alignment on the prioritization across among the stakeholders. Some of the best program managers are good at understanding customer cohorts, their behavior on the application, and what they like & dislike. Not understanding customer behavior leads to bad (or gut-based) product decisions. Almost always, it comes down to first principles. Good product managers invest time learning the customer.

Avoid artificial growth! A good growth PM or a good PM, in general, will only look for sustainable growth opportunities. There was this one time at Yahoo when a bad growth PM said to me, "let's grow video consumption by auto-playing every video on every page." This is a horrible idea because you will grow video consumption at the expense of user satisfaction, and time spent. Doing these types of trade-offs is NOT "growing," it's "trading". A good growth PM would say "hmm let's find real opportunities where videos are not present but should be." 

The number one thing first time growth PMs get wrong is only focusing on wins and not involving their team. When creating a Growth squad, your number one enemy isn't not making the number bigger, it's xfn attrition. Designers and engineers who are new to Growth have historically been rewarded for releasing new features. When joining a Growth team, you have to be able to prepare them to launch something and then delete it. This is very new behavior and goes against what they are used to doing. 

So what do you do? You have to redefine how they value themselves. Essentially get them to unlearn what they've been used to for the last 10+ years. It's no simple task. But one of the greatest ways I've seen this get driven is by involving your xfn partners (who are interested) in the strategy of what your team will build. In that you are trying to move the number, but really, you're trying to answer questions that will inform the strategy. By involving your xfn partners there, they will feel rewarded when we answer a question and you help proliferate that insight across the company. You want your team to feel a sense of pride not just by moving the number, but by how you all affect the strategy as a whole. Even if that means you didn't make any permanent changes to the product.

The key mistake new PMs make is focusing on delivering over impact. 

It is inevitable that PMs hit a point where the backlog runs dry. The instinct in this moment is to panic to get something ready for dev, push forward the first idea that jumps to mind. The problem is this reduces the level of rigor, making it likely the work will not have sufficient reach or impact to matter. It also increases execution risk, increasing the likelihood specs are incomplete and engineering has to work with partial requirements, like building without design, that result in rework. In the panic to get this new feature out the door, the PM likely won't have time to build a proper backlog and be in the same spot a sprint later.

Instead, the PM needs to take the painful step of admitting fault and chart a sustainable path forward. They can follow my process in a different question for building a roadmap. Knowing that process will take time, the key is being clear with engineering and product leadership on the process and rough timeline, so that the team can be best utilized while the backlog is being built. This also creates an opportunity for individual engineers to see the backlog building process from scratch, giving them higher confidence and motivation when the work is dev ready.

I should call out that it is not just new PMs who make this mistake. I've made it myself many times in my career, so I know it is much more easily said than done.

The biggest mistake I see is PM thinking they should just apply frameworks, and that they "know" what to do, without having the legitimacy they need.

Product management, in which I see growth PM as a sub-category, is an art, not a science. And like every art it takes time to craft and master it.

Product management is a late rewarding career, you will see the impact you are making after 10-15-20 years. It happens by working with other people, by creating relationships. Without relationships and trust from others you don't go anywhere as a PM.

Expecting glory right off the gate. The thrill of launching a first test is huge. The disappointment from reality vs. expectations might be huger. Any number of things may go wrong in the beginning. Something may be off with the test setup (dang, that missed attribute), the test might fail gloriously (think big red stat sig negative), the test may be a disappointing win (whoaaa….wait, that’s it? I was hoping 10X impact…), or something totally out of one’s control derails the test (sorry, data outage mid-way through the test, need to run it again).

First time (and not first time) growth PMs must instead focus on the bigger picture. Really understand your customers, the product, the market landscape. Be curious. Understand the opportunities (user pain points, drop off points in the experience, greenfield areas), the underlying growth loops, chart your unique learning agenda and then the roadmap needed in place to tap into all of these. Drive the roadmap diligently, bring back learnings effectively. With this, you will build your credibility -  a currency much needed to then drive collective creativity and audacious ideas within your org.