@andrewchen

Get the newsletter · Featured · Recent

How to build a growth team – lessons from Uber, Hubspot, and others (50 slides)

Dear readers,

Building a new growth team is hard. You have to figure out the macro organizational issues – how it fits in with marketing, product, and other functions – as well as the micro, like how to measure the success of these teams. It’s a tricky topic and something that a lot of teams are thinking about right now.

A few months ago, I spoke on lessons learned from various organizational structures for the growth teams at Uber, organized as 5 broad topics:

  1. Why create a growth team?
  2. What’s the difference between a “growth hacker” and a growth team?
  3. What’s the difference between growth and marketing/product/whatever?
  4. Where should growth teams focus?
  5. I’m starting or joining a growth team! What should I expect?

To answer these questions, Brian Balfour and I worked on a deck, based on materials from Reforge. (Check them out for more practical reference materials on this topic)

The deck is presented below! Hope you enjoy the materials, and feel free to reach out or follow me for realtime updates at @andrewchen on Twitter.

Thanks,
Andrew

📥 Get this deck as a PDF, plus new updates and essays in the future by subscribing to my newsletter.

The Deck

Above: Today, I’m going to present a few key topics that you need to figure out as you build a growth team for your company. First, why you might want to create one in the first place. Then, the differences in skillsets for both individual practitioners versus the org – and versus existing functions like Product and Marketing. And finally, where teams should focus and how to make an impact in the early days.

The ideas within these topics are drawn from several places – interviews and discussion with the folks who lead growth teams at places like Slack, Dropbox, Hubspot, Pinterest, and others, but also my own personal experiences at Uber.

Above: Many of you may remember when Uber looked like this. It was all up and to the right.

The growth team was originally created in 2013, founded by Ed Baker. It experimented with a ton of different organizational configurations – I joined a few years after it was created and spent about 3 years there, and spent most of my time on driving growth on the rider side of the platform.

Above: While I was at Uber, a lot of amazing projects were run out of the growth team. My colleagues in China Growth made incredible progress – shoutout to Ben Chiang, Han Qin, Michelle Chen, Jia Zou, Vinay Ramani, and many others – in addition to much of the progress being made across the US and the rest of the world.

At its peak , the growth team included China Growth and had over 500+ people. It was an amazing, dynamic time for the company. I learned a ton and am excited to share some of the ideas today.

Uber has changed a lot over the years. We certainly changed logos many times. But I think there are some really critical things that we can pass along to others in the ecosystem.

Let’s start with the basics…

Above: First, why create a growth team in the first place? We know that a lot of companies have folks with formal growth teams, and informal ones with growth PMs/marketers/etc running around.

Above: When you just look at the cross-section of companies in the industry, many of the newest and best B2B and consumer companies have all built growth teams.

We’ve also heard many Boards ask their CEOs to invest in growth teams. Why did this even emerge in the first place?

Above: The easiest way to talk about The Product Death Cycle.

Unfortunately, this is how products are often shipped and released. You have someone with a vision, who builds some features and does a launch. They might get an initial spike of traction, but when growth flattens, it’s not clear where to take things. They talk to some customers, ask what they want, and try again. They add a few more features, re-launch, and so the cycle goes on.

Do that too many times, and all of a sudden, you’re dead.

Why?

Above: If you build it, they may not come, it turns out. Better products, and more features, do not necessarily equal growth.

Many of the key levers for driving more user acquisition, retention, engagement, can sometimes sit outside the toolkit for most great product leaders. There’s a long laundry list of skills that are critical, but not often considered core to the product: adtech integrations, signup funnel A/B testing, optimizing notification delivery, testing price points, testing cohort curves, etc. Yes, occasionally there are people who know all of it – but they are rare!

Furthermore, no one individual can drive this. Instead, you need to bake this into your organizational goals and DNA. You need to collect these efforts within the larger framework of the company.

Above: Thus, we seek to build a framework for growth that’s a discipline and organizational structure within its own right.

We’ve come to see that “design thinking” and “agile engineering” are their own systems of organizational structures, workflows, philosophies, and skillsets. They are key to how we work within a company.

In the same way, we can build growth teams as a system too.


Above: Product Growth is the discipline of applying the scientific method to business KPIs.

It provides an underlying system for increasing metrics whether it’s revenue, acquisition, retention, engagement, or another key business metric.

Above: And just as you’d expect with the scientific method, the steps are build on understanding the data, creating hypotheses that identify why certain processes are happening, prioritizing those ideas, running the experiments, and then repeating the cycle.

That way, if you think your active user count is low, you can analyze the data to understand that you need more top of funnel user acquisition, then hypothesize that a combo of paid advertising and referrals can help, and then execute against that.

📥 Get this deck as a PDF, plus new updates and essays in the future by subscribing to my newsletter.

That is much, much better and more targeted than just building more features that your users ask for, and expecting growth to magically increase as a result. (Maybe you should build those features anyway, but don’t do it for growth!)

Above: Second topic. Let’s talk about the difference between the “Growth Hacker” – a term that Sean Ellis invented and I helped popularize – and a “Growth Team.” This is an important one.

Above: In the early stages of the growth skillset, there were no teams. There were a number of individuals and startup founders who were putting the necessary ideas, workflows, and tactics together. Some of these folks would refer to themselves as “growth hackers” in a tongue-in-cheek way.

As the skillset grew, it was clear that to do anything impactful, especially within the context of a larger/complex product, you needed to organize entire groups of people.

Above: Thus the growth team emerged, with the philosophy that you don’t want a lone genius with all the levers, and a team of helpers. Instead, you need to create an organization with a broad set of skills.

Growth is a team sport, and to run the scientific method on your KPIs, you need a lot of people who can help you.

Above: For most of the missions for a growth team, you need many different functional roles to help – from Product, Marketing, Engineering, Data, Ops, Finance, etc., etc. You combine all of these folks into individual teams and organize them together into a growth org.

Above: What are people doing within all of these roles?

  • Growth PM: A product manager that’s responsible for the experiment roadmap
  • Growth engineer: An engineer who’s focused on technical decisions and implementing experiments
  • Growth marketer: A versatile marketer with an expertise in a given channel – from paid marketing to SEO to email to others
  • Growth data: An analyst focused on creating insights – both macro on the user lifecycle, and micro, on specific experiments
  • Growth design: A designer leading the UX, but with an emphasis on speed

You might also loop in other function – for example at Uber, a lot of decisions around incentive spend had to include folks from Finance or Pricing. And you’d always have to include Ops to think through how it affected things on the ground.

 

Above: Depending on the problem you’re trying to solve, you might have a different makeup on the team. For the new user experience – which might include increasing signup conversion, and maybe even integration into ads – you’d probably emphasize engineers. You’d want an Android and iOS engineers. Plus even performance marketing folks, some data analysts to look at the metrics, etc.

 

Above: If you were working on SEO, on the other hand, then maybe you wouldn’t need designers. This might be more about optimizing page structure, where the content goes, etc. In this case, you might emphasize SEO marketing, data, and a full-stack engineer for web.

Ultimately, the goal is to define the problem based on your insights and hypotheses, and staff the team to solve that particular problem. The individual teams might emphasize different skills, and the macro organizational structure of where the growth team fits has the some complexities depending on the missions of other teams.

 

Above: One common structure is to treat the Growth Team as a set of pods, each one matrixed to their respective functions. So you might have a Growth PM that reports into Product, plus the others, and all together they are the growth team. Many product teams look like this, and this is set up to match.

Alternatively, at Facebook and in an early incarnation of the Uber growth team, you have things set up more like a business unit. You have functions reporting into a GM, and the pods underneath. This has the advantages of creating a lot of independence within the team, with the complication that you split the various orgs – this can cause complexity and sometimes conflict as well.

 

Above: You can obviously pick and choose and have hybrid models as well.

 

Above: Too many startups are beginning with “I need a growth team!” and accepting a random org configuration, without thinking it through from the fundamentals. Ultimately, You have to start with the problems you are trying to solve. Begin with the KPIs, the insights you’ve generated, and then move onto execution. You staff the problem area and the type of execution you want. The organizational structure follows from there.

 

Above: This is a question I often get. Isn’t growth and marketing just the same thing? Isn’t growth and product just the same thing? Can’t everyone just be responsible for growth?

In this section, I’ll walk through some of the practical differences.

First, when it comes to Marketing and Growth, there are a lot of specialties that you want to solve:

  • Brand marketing
  • PR
  • Events
  • Content marketing
  • Email
  • SEO
  • Paid marketing
  • Viral/referral features
  • New user experience
  • User-to-user notifications
  • etc

You could house all of these in a bunch of different configurations, but roughly speaking, you often have three categories of functions:

  • Brand
  • Growth marketing
  • Growth product

It’s usually obvious that Brand ends up in Marketing. And similarly, things like NUX and product-generated notifications end up in a Growth team. But some of the middle levers, like SEO/Paid marketing/Email/etc, could potentially sit in either. I’ve seen both. Facebook has much of performance marketing sitting inside the Growth team. Uber started that way, but ended up having it all go into Marketing. There’s a lot of different possible configurations.

Above: If core product teams have engineers, designers, and PMs, and so do growth teams, what’s the difference? It’s all dependent on what they do. Product teams focus on creating core value. Enhancing product/market fit over time. This means obsessing over every little interaction in the core engagement loop – it’s a game of inches, and those inches count.

On the other hand, growth teams should focus on getting the core value out there to the world – getting as many folks as possible to experience that value.

There’s a middle ground on making users experience core value as frequently as possible – you could imagine putting that in either team, but if the solutions tend to be very iteratively/quantitatively-driven, then maybe put it in the Growth team.

Above: You also have to decide the ownership model. There are two extremes: Growth-as-a-Service and Autonomous. And everything in between.

In “Growth as a Service” – the team doesn’t technically own any feature or codebase. They jump into the highest value part of the product, do their analysis and optimizations, ship a bunch of improvements, and move on. It’s important for the team to be gentle, as they are the guests, but it’s also important that they stay lightweight. If the growth team ends up owning every piece of code they touch, then they would eventually get stuck in maintenance mode for everything.

On the other hand, a full ownership model means that the growth team could own the new user funnel, notifications, ad tech, the A/B testing platform, payment flows, and many other critical areas where numbers trump intuition. This can work, but then the team needs to be staffed properly.

Above: There are ultimately lots of pros and cons to each model. Uber went through the entire spectrum, but over time, came to own more and more pieces of the product. But you’ll have to decide based on your own constraints, org, and product requirements.

 

Once the growth team’s been set up, where should they focus? As discussed previously, their mission and toolkit ought to be distinct from those used by the marketing or product team. Especially in the early days of the team, there should be low-hanging fruit that can be picked off easily.

Although it’s easy to jump right into user acquisition, or looking at churn, let’s zoom out and look at the system. Let’s start with a prioritization framework.

 

Above: Ultimately there are three key things you’re trying to trade off – and one is particularly tricky:

  • Effort. How much design/eng/marketing resources does it take to execute?
  • Success. How likely will it be to be successful?
  • Upside. This is the tricky one – but if it works, how much will it affect overall growth?

Every growth experiment is ultimately a prioritization based on the ranking of these three axes, and over time, your growth team will be smarter about how to pick. But I wanted to provide some notes on where a growth team is likely to go wrong in their prioritization.

The most common anti-pattern on picking growth projects is where a +50% increase on a feature touching 0.01% of users is celebrated, but a +5% increase that touches 50% of your active users feels smaller. Of course when you do the math, the latter is much more important as you ultimately want these bottoms up experiments to hit your top-down KPIs.

Another common anti-pattern is to focus on large effort, large upside projects over low effort, low/medium upside projects. Almost everyone overestimates their chances of success, so it’s better to go for more execution throughout over big bets… until you run out of easy ideas or you have enough resourcing to build a portfolio of small and big projects.

Some notes on each factor:

  • In general, Effort is the easiest to understand. If you define a project, your team will be able to execute against it like anything else. The usual advice I give here is to bias towards low effort projects early on in a growth team
  • Success rate can be controversial, because the things that work in growth are not necessarily things that users will self-report – and thus, people on teams will usually say, “I would never want this. I would never do this.” And yes, you implement the best practices and things work. The classic example here is the desire to add comprehensive content on landing pages, with links to a million other places. It’s a well understood design pattern to provide just as much information as is needed to get the signup – nothing more.
  • Upside, of the three, is the trickiest thing to understand though. It’s also the lever with the most power, as it provides strong guidance on where in the product the growth team should be focusing.

Let’s do a deep dive on Upside.

Above: Upside is ultimately measured in absolute terms – how many additional subscribers did you gain, the number of signups generated, etc. You calculate it using two components – Reach and Impact. Reach is the measurement of how many end users are touched by the change of a feature. Impact is how much the metric moves as a result of the change.

Between these two factors, Impact tends to be the most random. Sometimes a change you’ll make moves things by +5% and sometimes it can move things +50%. In the main, you’ll get something in between for the vast majority of your projects. For some projects, impact can be huge if it’s a product experience that can happen multiple times – for example, a new highly-relevant notification that’s sent in the core engagement loop of a product. Or something that significantly amplifies a viral loop, causing the flywheel to spin faster and faster. (But that’s out of the norm- but also tells you that you might want to focus on these outsized impact cases)

Reach, on the other hand, is an amazing lever that is often misunderstood. This is often the sweet spot for understanding the best kinds of projects.

 

Above: In the main, most product teams focus on making their core product experience better, which benefits their core users. This has a lot of benefits – after all, they are the most engaged, the most valuable from a monetization perspective, and in a multi-sided platform, they produce the photos/content/sales/etc that sustain the rest of the ecosystem.

On the other hand, core users are often only a small % of your total active users.

Above: Depending on how you define core users, they are usually only 5-25% of your active user base. If you are looking at the segment of your userbase that actually produces content, rather than just consuming it, you’ll see it’s usually a small %. Or the ratio of your hardcore users who are generating a ton of content, versus purely passive consumers. It’s always a small amount.

As a result, if you have projects that can target your active users, but not your core ones, then you might have 4-20X more reach! Wow.

But that’s not all, there are more concentric circles.

Above: On average, only 10-50% of your registered users might be active in any given month. 50% is world-class good – like Facebook and their ilk. Usually most products are closer to 10-20% because the vast majority of products have a ton of one-hit wonders: People who try the product once, but then forget to ever come back.

Projects at this level ought to focus on activation. If you can understand what gets a user to become active, then you can introduce that during the onboarding flow, thus converting them to active or core users.

The other set of activities here – for products with large, established audiences – is the flow from being inactive/churned to coming back into the product. Are they getting relevant emails to get reactivated? If they’ve forgotten their password, are you optimizing that flow as critically as if it were a signup flow?

Above: Of course, for many products – and this is more of a web thing – there are people who look at a product but never sign up. Most landing pages might only have 10-50% conversion rate to signup! Furthermore, a lot of products have “side doors” – like Dropbox shared file links, or YouTube video pages – that get the majority of the traffic. Those become critical places to optimize.

Above: Of course, even bigger than all the people who have interacted with your product at all – even in a logged out state – there’s everyone in your primary acquisition channel (whether that’s on Facebook or Google or something else) that have never heard of you before. This is true top of funnel acquisition.

And of course, there are all the channels you haven’t even experimented with. That’s why adding a new channel – like trying a referral system when it doesn’t yet exist – can be such a big needle mover.

Above: All of this is to say that if you are looking for the biggest lever on growth upside, it’s probably in addressing  Reach. And think of the concentric circles when you are finding that your growth team’s projects collide with the core product team – move to further and further concentric circles, whether that’s targeting new users, churned users, and everyone out on the edge who hasn’t yet bought into your product.

The other fascinating exercise is to look through your existing features and roadmap and circle everything that touches non-users (or inactives) as opposed to active/core users. You’ll be surprised that there are generally very few.

The above was shared from Airbnb’s growth team who did exactly this exercise – only 6 items out of 33 were for non-users. (Shoutout to Gustaf, who ran their guest growth!) A growth team can rapidly expand this list and give some love to everyone out on the edges of the audience.

 

Above: Final topic. Let’s say that you as an individual are thinking about joining (or starting) a growth team at a company. What should you expect, and how might you evaluate the opportunity?

Above: There are a lot of organizational and cultural aspects that can get in the way of setting up a successful growth team. First, there’s leadership DNA – is there an understanding of what the growth team does? In particular within the Product and Marketing peers? Or is this something that’s being forced top-down by the CEO or board without leadership buy-in? It can get painful if people don’t fundamentally get the mission of the growth team.

Company culture is an important aspect too. If the culture is like Uber 1.0’s, where experimentation is encouraged – as long as it’s scoped to a city or two at a time, or as a 1% test – then that’s great. “Move fast and break things.” On the other hand, if the company is extremely design and brand conscious, it can be harder. Famously, Apple and Snap are two companies that rarely ran A/B tests until the recent era. In evaluating a company for experimentation, it’s good to understand how open folks are to a big change to the homepage, for instance, even if it’s 1%. Or in the new user flow.

The ownership model, as previously discussed, can either on a spectrum: SWAT team model, with little/no code ownership, or strong ownership of areas like NUX/notifications/adtech/etc. Both can work, just make sure you know what you’re getting into and that the staffing reflects it.

IMHO, the best case scenario, in my opinion, is to have a team that is:

  • Bought into having a growth team, and knows how it compliments the existing functions
  • Supports experimentation, even extreme as long as its tested with a small group
  • Dedicated staffing that’s already in place, with a bias towards strong ownership on for everything outside of the active user base

The worst version, of course, is where people don’t really get why you have the growth team, there’s a ton of risk aversion on rapid experimentation, and no staff… just an expectation to run around and convince other teams to build your amazing ideas. That’s a recipe for failure.

Above: There are common lines of disagreement to implementing a growth team. Sometimes the incentives of a company are set up to reward large, complex projects (with codenames and executive oversight) rather than many lightweight changes that move the business along. This can get baked into everything from how projects are reviewed to perf review, to everything else.

📥 Get this deck as a PDF, plus new updates and essays in the future by subscribing to my newsletter.

Similarly, before starting a growth team, almost certainly there were also folks looking after growthy parts of the product. By moving those responsibilities away, or starting to encroach on “engagement” which overlaps with the core product team, there can be anti-bodies that make growth projects much, much slower.

Above: The foundation of the organization has to be ready to accept a growth team, and that starts with a fundamental understanding that the environment has changed:

  • Growing tech products has changed, and the playbook has changed in the last decade
  • Explicit headcount/roadmap has to be dedicated towards making growth happen – “build it and they will come” doesn’t work
  • Creating a pipeline of growth experiments will need a different process. The scientific method as applied to KPIs. Not just a subset of marketing and product projects
  • And finally, the team structure and skillsets to make this successful are different

As you might imagine, creating this foundation of mutual understanding is a big effort by itself. And y0u’ll need the help of your startup’s CEO, or your business unit’s GM, and the layer above them too. And all your peers.

Above: There are tactics to overcome the inevitable organizational friction you’ll hit. Here are a few of them.

OK, that’s all folks! Thanks for reading this far, and hope you enjoyed this deck

 

PS. Get new updates/analysis on tech and startups

I write a high-quality, weekly newsletter covering what's happening in Silicon Valley, focused on startups, marketing, and mobile.