How to Structure Your Growth Team: 2 Models That Work
I've built growth teams twice as a Head of Growth.
Once very successfully. Once much less so. And since then I've coached 90+ growth leaders through the exact questions I'll cover here.
So I've seen both models up close, and I have strong opinions on them.
If you're a Director, VP, or Head of Growth trying to figure out how to structure your team, or trying to make the case for a different setup than what you have right now, this is for you.
What a growth team actually needs to function
Before getting into the 2 models, it helps to understand what you're structuring around. A growth team is cross-functional by nature. To run it well, you need coverage across 5 jobs.
(And real quick: you don't need 5 people. Smaller companies run these jobs with generalists. Larger ones specialize. But the jobs exist regardless.)
01
Growth PM
Owns the roadmap, sets priorities, keeps the team focused on outcomes, not just activity.
02
Engineering
Non-negotiable. You can't run a real growth program without someone who can ship changes to the product and site.
03
Design
Growth moves fast and tests a lot. You need design support that can keep up, not a queue you're waiting in.
04
Data & BI
Makes sure you're tracking the right things and interpreting results correctly. Keeps you focused on what actually matters.
05
Growth Marketing
Owns the levers outside the product: acquisition channels, lifecycle emails, onboarding flows.
Here's what makes growth structurally different from product or marketing:
Product owns their engineers. Marketing owns their marketers. Growth depends on almost all of these functions - but in most companies, growth owns none of them outright.
You're dependent on resources that technically belong to someone else.
That's the core tension. And it's exactly why the structure question matters so much.
Model 1: The independent growth team
This is what I had at Wistia. And it started lean: me as the PM, 2 engineers, part of a designer, part of a data analyst. Not a huge team. But they were mine.
Over time, as we showed results, it scaled. We eventually had 2 squads: an activation team with 2 dedicated engineers, a PM, and a designer — and an acquisition team with a marketer, a front-end dev, and a shared portion of that same designer.
What that gave us, more than anything else, was the ability to iterate. And iteration is the whole game in growth.
You almost never do something once and nail it. The operating system is built around shipping, learning, and shipping again. Dedicated resources are what make that possible.
When you don't have them, something subtle but damaging happens.
You stop taking risks. You only work on high-confidence bets, because you can't afford to ship something that doesn't work when you're only getting a handful of shots per quarter.
Think about it this way.
Some of the best growth wins are moon shots - projects with maybe a 1-in-10 chance of working, but if they do, you get a 10x return. You'd never take on one of those with 3 at-bats a quarter.
You need volume to find the winners. Dedicated resources give you that volume.
"When you scope things down to protect your one shot, you get more modest returns. The shared model shows up directly in your outcomes."
The tradeoffs
The independent model is harder to get.
It requires real buy-in from leadership. It can create friction with product and engineering orgs who feel like you're pulling resources from the core roadmap. You have to earn it, and you have to make the case.
But it's worth fighting for. More on that in a minute.
Model 2: Shared cross-functional resources
This is where a lot of growth leaders end up, especially early on.
The structure looks like this:
You have an independent growth strategy, but you're borrowing resources from other teams to execute it. You have a growth roadmap, but the engineers who build it report to product. The designer who supports you has 4 other stakeholders.
On paper, it sounds workable. You have all the resources you should need.
But in practice, it's really hard to operate well.
At Postscript, the main initiative I ran under this model was a referral program. The program itself was solid. But I never got to iterate on the thing that actually drives referral performance: the offer. What does someone get in exchange for referring someone? That's the variable. That's what you have to test to find a winner.
I basically got one shot.
Getting the engineer back meant waiting for core product work to wrap up their current sprint, then making the case again, then scoping everything out so no time was wasted. T
he whole thing had to be perfectly defined before I could get a single rep at bat.
That referral program ended up being okay. I genuinely believe it could have been a lot more. The hidden cost of the shared model isn't just that things move slower - it's that you scope everything down to protect yourself against wasting your one shot.
Side-by-side: what each model actually looks like:
How to choose - and how to make the case
If you're in the shared model right now and want to change it, the argument I always bring to this conversation comes down to 2 things: speed and outcomes.
Speed is the obvious one - dedicated resources move faster because they don't have competing priorities.
But outcomes is the more powerful argument, and it's the one that tends to move leadership.
The pitch that actually works with leadership
Think about the area of your growth model that's most underperforming right now.
With dedicated engineering and design, you can actually move the needle on it - run real experiments, iterate on what's not working, make meaningful product changes in short cycles.
Without those resources, you're a marketer scrapping things together on your own.
You can do some things, but your ceiling is a lot lower. And because your ceiling is lower, you stop reaching for the big wins.
The case to bring to leadership isn't "I’m busy and need headcount."
It's: “here's the area of the growth model we most need to move, here's what moving it requires, and here's what we're leaving on the table by not having the resources to do it right now.”
My actual recommendation
Push toward the independent model, even if you can't get there on day one.
If you're in the shared model right now, operate like an independent team as much as you can: shared rituals, shared KPIs, a sense of team identity even with borrowed people. Use your wins to build the case.
That's how you earn dedicated resources: you show leadership what you can do with borrowed ones, and then you show them what you could do with your own.
Quick summary
The independent team: dedicated resources, faster iteration, bigger swings. Harder to get, but worth fighting for.
The shared resource model: easier politically, lower barrier to get started. But you'll feel the constraints, and they show up in your outcomes.
If you're trying to make the case for a different setup, bring the speed and outcomes argument. That's what's actually on the table in that conversation.
Want help figuring out your team structure?
This is the kind of thing I work through with growth leaders every week. If you're a Director, VP, or Head of Growth trying to make the case for the setup you need, let's talk.