How to Build a Growth Team
by Andrew Chen · read the original
Why shipping more features doesn't grow your product, and how to build a team that applies the scientific method to your KPIs instead. Drawn from Uber's growth org and interviews with Slack, Dropbox, Airbnb, and Facebook.
- 1
The Product Death Cycle
Flat growth is usually not a feature problem. It's an ownership problem: the highest-leverage growth work belongs to nobody.
- 2
Growth Is the Scientific Method Applied to KPIs
Growth is a repeatable process (data → hypothesis → experiment → iterate), not a bag of tricks. And it's a team sport, not a lone hacker.
- 3
Who's on a Growth Team
Staff the team from the problem backward. The KPI you're attacking determines the skill mix, not an org-chart template.
- 4
Where the Team Sits
There's no universally correct structure. Pick KPIs first, then choose the org shape that lets you execute against them.
- 5
Growth vs. Marketing vs. Product
Product creates value; growth connects that value to more users. Decide explicitly how much surface area the growth team owns.
- 6
Prioritizing Experiments: Effort, Success Rate, Upside
Upside = Reach × Impact. A small win on a huge surface beats a huge win on a tiny surface, almost every time.
- 7
The Concentric Circles of Reach
Your roadmap probably over-serves the people already using your product. The biggest reach, and the biggest upside, is in the outer circles.
- 8
Is Your Company Ready? Culture and Antibodies
Growth teams fail organizationally before they fail technically. Secure buy-in, dedicated headcount, and permission to experiment, or don't bother.