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 ones, like how to measure the success of these teams.
Today, I’m going to talk about a few key topics that you need to figure out as you build a growth team for your company.
Starting with the basics, let’s pause to ask ourselves 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.
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.
I’ll bet you’ve also heard many Boards ask their CEOs to invest in growth teams. Why did this even emerge in the first place?
The above diagram is 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?
Because 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!
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” 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.
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.
And just as you’d expect with the scientific method, the steps are:
1. Build on understanding the data
2. Creating hypotheses that identify why certain processes are happening
3. Prioritizing those ideas, running the experiments
4. 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.
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.
What’s the difference between a “Growth Hacker” and a “Growth Team”?
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.
Growth is a team sport, and to run the scientific method on your KPIs, you need a lot of people who can help you.
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.
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
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.
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.
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.
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.
Let me walk you 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
· 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 3 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.
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.
You also have to decide the ownership model. There are two extremes: Growth-as-a-Service and Autonomous. And everything in between (shown above).
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.
As shown above, there are several pros and cons for each model. Deciding on which one is best for you will be based on your own constraints, org, and product requirements.
nce 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.
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.
Of the 3 above mentioned factors, upside is the trickiest. 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:
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%. 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 often the sweet spot for understanding the best kinds of projects.
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 platform.
On the other hand, core users are often only a small % of your total active users.
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 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.
On average, only 10-50% of your registered users might be active in any given month.
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?
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.
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.
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.
OK, that’s all folks! Thanks for reading this far, and hope you enjoyed this one.