Growth Product Org Charts: From the First Growth Squad to a Scaled Team

With org charts based on teams I've managed.

This post is brought to you by Syncly: Surface product and operations insights from support tickets, calls, surveys, and reviews that NPS and CSAT don't tell. Learn how fast-growing companies use Syncly (YC W23) to instantly categorize thousands of pieces of feedback and reveal hidden negative signals to prevent churn, here.

---

“How should we structure our Growth team?”

I hear this question a lot, and there are actually three answers: (1) How to organize the first Growth team, (2) When to start scaling, and (2) How a scaled Growth team should look.

I’ve already written about when to start a growth team and centralized vs. decentralized growth team structures, so I won’t cover that in this post.

How to structure your first Growth team

The first type of Growth team is straightforward: it’s purely an experimentation team, and that’s it. Instead of owning specific surfaces (you don’t want them getting bogged down with latency or fixing bugs or metrics), they examine the entire customer journey and focus on underperforming areas. They identify a target metric and experiment relentlessly to move it in the right direction. This approach is like having a ‘Growth team as firefighters’ approach, often making them one of the highest-leverage groups in your organization. They don’t own any specific surfaces, operate independently, and typically remain small and nimble.

This kind of initial Growth Product team includes:

• A Growth PM + A Data Scientist. This is the core pairing. The PM wears a lot of hats at this stage… but Data comes before Growth, so Data has to be there. Or, at the very least, you need self-serve tools that will allow the PM to pull and analyze their own data. 

• 1-2 Engineers. To start, but a Growth PM can handle up to 7 engineers.

• 1/2 a Designer. Doing your own designs in Miro, Figma, or Canva is a prerequisite for the first Growth PM. Design resources are brought in for more complex problems or on a consultative basis.

• Access to Marketing Support: This really depends on the surface the team is touching. The team will always benefit from having an assist from: 

  • Product Marketing - If the team needs to update content pieces, for example, a PMM can provide editorial perspective and the necessary context on what needs to be created. 

  • Lifecycle - The PM will generally have to do their own emails, but the Lifecycle team can advise on best practices and current programs.

  • Performance - Acquisition-focused Growth teams, especially, who are working on TOFU (Top Of Funnel) activities will need involvement from this group, especially if they’re working on retargeting, etc.

With this kind of lean crew (and some borrowed consulting resources from other internal subject matter experts) you can get a lot done.

Why not build out the growth team further from the start? Because you need to prove ROI first, and this is the minimal viable resourcing needed to get started.

But let’s compare it to an org chart of a scaled Growth team.

How to structure a scaled Growth team

Here we have ‘head of growth’ with multiple ‘squads’ rolling up to them.

Squad Objectives

In this structure, you have a squad for every lever in your Growth model: acquisition, activation, monetization, retention, AND major growth loops (viral, content, etc).

Here, Growth starts needing to own surfaces. But it’s essential that you be very careful in picking the surfaces that Growth will own. Usual suspects are:

• Home/landing pages (for conversion rate optimization)

• Specific channels, such as SEO or SEM (that are highly performance-based)

• Onboarding quiz (for segmentation and personalization)

• In-app Dashboard (empty-state dashboard at the minimum, to get activation going)

• Pricing/checkout/order confirm pages (for conversion rate optimization)

• In-app messaging (to work on activation, monetization, and engagement)

• Email (to work on monetization, activation, and engagement)

• Experimentation platform (as it is a core process across the entire Growth team)

The rest are owned by Core Product or Marketing with an explicit agreement that Growth can experiment and optimize them.

But once you start owning surfaces, you need to deal with maintaining them… so you’ll also need a Growth Infrastructure team. They take on tooling like in-app messaging, data platforms, the experimentation platform, as well as any KTLO (Keeping The Lights On) work for owned surfaces (migrations, anyone?).

Helpful read: How to build growth engineering teams that win!

Squad Structure

The key elements will look familiar to what we saw in the ‘first Growth team,’ above: The Growth PM (the metric owner), an attached Data Analyst, an attached Designer, and an Engineering lead, who is responsible for managing the related engineering resources.

At this level, you’ll also likely have dedicated marketing resources. Because of the increased complexity and sophistication, you’ll need a dotted line dedicated PMM, although I’ve never had 1:1 with Growth PM:Product Marketing—each PMM is always supporting 2 or more squads. Lifecycle resources may be fully embedded within the squad, so you have Lifecycle for activation, Lifecycle for monetization, etc.

Growth Marketing?

One important note: This structure assumes Growth sits in Product and it is very different if you put Growth in marketing… which makes it a Growth Marketing team. There are a number of benefits from this approach, but I often have to warn companies:

Do not expect product work out of a Growth Marketing team! 

If you’re working on how to manage traffic from a specific channel or looking at SEO impact, sure, go with Growth Marketing. But… if you need the team to impact the rest of the user journey in product, they may run into trouble. Ultimately, marketing can own acquisition/retargeting channels, the marketing site, emails, maybe in-app messaging. And this can lead to some incremental improvements. But you almost always need Product, Engineering, and Design to create a real step-function change within in-product experiences. 

So, I’m not trying to rain on Growth Marketing: It’s just important to realize that the scope of impact will be limited, without the ability to address Product changes.

When should you switch to a scaled Growth team?

So, how do you know when you’re ready to start scaling your Growth team? I look at two main things:

1. Positive ROI for the Growth team.

Because Growth operates with an experimental process, you should be able to know the exact amount of incremental value they bring to the table. You also know the cost (the salaries for your Growth team members + tooling costs), which makes it easy to create a mini-P&L for this group.

Hypothetical example

Above shows a $2.4M delta between the cost and the incremental revenue, you have Product-Market Fit for your Growth team! That’s when they’re bringing in more than they cost. 

At that point, it becomes easy for the PM to request additional resources: ‘I brought in $5m. My team costs $2.6m. I want to reinvest $1m of the ‘profits’ into 2 more engineers ($500k/each), which would allow us to accelerate impact to $5m to $8m by letting us do these incremental initiatives.’ Talk about a slam dunk case for finance :)

2. Clear traction with experiments improving a specific metric.

Because a big shift for scaled Growth teams is metrics ownership, it’s important that the team has already gained initial experimentation and was able to show traction with a given metric. If you’re going to switch from a floating Experimentation Team to a permanent team that will own Activation (for example), your team needs to have already gotten wins in the activation.

Which metrics should you start on? I usually see the following progression:

• Start with Activation (often working on adjacent users): it is an issue 90% of the time causing low monetization or retention. (Check out my previous post on this topic: I bet you are doing product activation all wrong.)

• Then, go to Monetization: because newly activated customers aren’t monetizing

• Then go back up to Acquisition: to bring more users that now can be activated and monetized

• And finish with Retention: to address now degrading product-market fit with increased top of the funnel that will naturally bring more occasional use cases, price-sensitive users, and lower intent use cases.

Side note: Why is retention last? Isn’t retention the most important one!? Why not start there?

There are actually several reasons why:

1. A Growth team implies Product Market Fit (PMF) and PMF is determined based on the retention. If your company has expanded to the point where they need a scaled Growth team, they already have Product-Market Fit. As I’ve said before, if you don’t have PMF and retention… you shouldn’t have any Growth hires, much less a scaled Growth team.

2. Retention doesn’t usually start slipping until later. The thing that starts to erode retention is … activating a bunch of adjacent users. Looking at Adjacent User Theory, this is a natural progression: You’re expanding to related use cases, but you haven’t figured out the complete loop for them, yet. So, your adjacent users aren’t monetizing. And they aren’t retaining—they don’t stick around like your core users. Opening up your TOFU (top of the funnel) messes up your BOFU (bottom of the funnel).

3. Retention is the Core team focus. Also, Growth teams don’t focus on Retention as their first priority because it is the Core team’s job! Core teams’ primary metric is often Weekly Active Users (WAU) or Paid WAU, which is fundamentally a retention signal. Growth is all about optimizing flows and if Growth is the only team focused on Retention, it usually leads to much bigger issues.

4. And… activation boosts retention. Surprise! Activation rates are usually a leading predictor of retention. If you activate a user properly, they should stay. So, having your Growth team focus on Activation makes everything better, anyway.

Conclusion

Now you know how to set up a Growth team at two different stages—and when to switch between those stages!

This is certainly not the only way to structure these kinds of teams. But I’ve seen it work really well across so many companies, so I’m confident that if you try it, you’ll at least be starting in the right direction.

Additional helpful reads:

• My favorite definitions of Growth

• Growth teams must learn to play well with others… or else.

• There’s a whole lot of ugly out there when it comes to growth teams

• Improve Growth Mindset in your company with a weekly Experiment Review Meeting

• Growth at Dropbox

---

Edited with the help of Jonathan Yagel—have you checked out his awesome Substack?

---