Hacking or Engineering?

Managing Growth Teams

Read

In this essay, we’ll focus on growth hacking: What is it? How should companies structure growth teams? What’s the archetype of a good growth hacker? What are common failure modes for growth teams, and how can firms avoid them?

Others have written about growth teams and how to manage them, including Sean Ellis, Brian Balfour, Andrew Chen, Anu Hariharan, Kyle Poyar, and Tom’s HBS colleague Mark Roberge.  We’ll build upon their insights and add our own, along with those of the product leaders we spoke to.

What is Growth Hacking? 

Since it was coined in 2010, the term “growth hacking” has raised objections for two reasons. First, some observers maintain that growth hacking is simply marketing, rebranded. Second, critics argue that “hacking” is a misnomer, because it emphasizes clever, ad hoc tactics that drive customer acquisition, rather than the systematic, iterative approach to experimentation employed by the best growth teams. 

As explained below, we agree with these objections, but we’ll use the term growth hacking anyway—because it has become entrenched in the tech industry’s vernacular.

The core tactics employed by growth teams—in particular, A/B testing—have been practiced for decades by direct marketers, including magazine publishers, mail order retailers, and credit card issuers. In that regard, growth hacking is indeed marketing rebranded.  However, the advent of the Internet has vastly expanded the range of businesses with a direct connection to their customers and has provided real-time data that makes experimentation faster and cheaper. 

Marketing was reconceived as growth hacking in another way. To drive prospects to the top of the conversion funnel, marketers in online businesses required support from engineering and data analytics teams, for example, to build landing pages and track the performance of ad campaigns. Their old school solution—relying on marketing agencies for technical support—was too slow and costly. In many companies, however, in-house engineering resources were tied up building features to boost engagement further down the funnel, in tandem with product managers. 

Great product leaders are students of human psychology as they relentlessly pursue their product’s what and why.

Furthermore, these product features were often designed with limited input from marketing, leaving no-one focused on the end-to-end customer journey. Marketing was responsible for top-of-funnel customer awareness and activation, whereas product teams were responsible for middle- and bottom-of-funnel engagement and retention.  An organizational innovation—cross-functional growth teams spanning the full conversion funnel, with members from marketing, product, engineering, design, and data analytics—helped solve this coordination problem.

Leveraging insights about psychology, successful growth hacking (engineering) builds upon a deep understanding of how a product meets fundamental human needs to design hooks that activate and reinforce desired customer behaviors— boosting customer acquisition, engagement, and retention rates. In this sense, growth hacking is not ad hoc, as the term implies; growth engineering is a more apt description. 

Consider how some tech titans have leveraged their deep understanding of fundamental human needs. For Facebook, the driver is the need for human connection. For Google, it is the need to be informed. For Amazon, it is the need for convenience (2-day shipping) and trust (easy returns). For Apple, it is the need to own and display aspirational products.

Great product leaders are students of human psychology as they relentlessly pursue their product’s what and why. What do my users do with my product and why does it fulfill some basic human need? Unlocking a product’s what and why can lead to explosive growth.

How to Structure Growth Teams?

Growth teams tend to be structured like product teams: the growth team leader has a role akin to that of a PM. That is, they are responsible for building consensus about what their team should work on, after consulting with team members, their supervisor, and others in the organization. After discussion and debate, team members follow the leader’s “what to do” direction, but they do not formally report to the team leader. Rather, they report to a manager in their function (engineering, marketing, design, etc.), who provides guidance for “how to do it” choices. 

Product leaders we interviewed, including Andrey Khusid, Chamath Palihapitiya, and Deb Liu, gave seemingly paradoxical advice for organizing the growth function: keep it centralized and decentralized.

The logic for centralization: When it reaches sufficient scale, a tech company benefits from having a central staff unit that can: 1) provide shared infrastructure for rapid A/B testing along with quick, reliable analysis of test results; 2) set standards and provide technical assistance to ensure that experiments are designed and interpreted in a consistent manner; and 3) collect and communicate growth team best practices and new ideas across the organization. 

For example, Deb Liu suggests a role for a central unit that specifies long-term “holdouts,” which withhold from a small subset of the user base—say, 1%—a feature that previously was made available to the rest of the base. Holdouts can be used to gauge the feature’s long-term impact on overall product performance, since the performance benefits of many features are subject to a gradual reversion to prior levels, after an initial spike.

The logic for decentralization: As noted above, growth engineering requires deep understanding of the root causes of customers’ behavior—in particular, psychological needs—in order to devise mechanisms that lead to outcomes valued by customers. Individuals who are close to the product and its customers are best equipped to glean these insights. Consequently, experiments should be designed and run locally.

It’s critical that both central and distributed growth teams are synchronized. Key, inviolate learnings must be embedded in the central unit. A continuous, regular dialogue across all of the teams can promote an exchange of ideas, leading to serendipitous growth green shoots. At LinkedIn, we accomplished this by having a weekly meeting of everyone involved in growth efforts. This meeting was considered to be so important that the CEO was a regular attendee.

Where Should Growth Team Leaders Report?  

Startups should not introduce growth teams until they have product-market fit. Before then, the venture’s user base is probably too small to run experiments aimed at optimizing performance. Also, optimization efforts may be wasted if the venture pivots. 

After the startup has achieved product-market fit and starts scaling, the leaders of its first growth teams may initially report to the founder/CEO, who—as we explained in an earlier essay—is likely to still be spending lots of time leading product development, and may not yet have appointed a product leader.

As the company gets bigger and growth initiatives proliferate, reporting arrangements for growth team leaders will tend to be structured in one of three ways:

  1. All growth team leaders will report to a growth function head, who in turn reports to the CEO.
  2. All growth team leaders will either report directly to a VP-Product or CPO, or to a growth head who in turn reports to the VP-Product or CPO.
  3. Growth team leaders will report to the heads of their respective functions, with team leaders who have a product orientation reporting to the CPO, team leaders working on data analytics and infrastructure projects reporting to the CTO, and team leaders working on “top-of-funnel” customer acquisition projects reporting to the CMO.

There is no “one best way” to organize the growth function. Which approach makes sense will depend on the current context of the company, the skill sets of the key leaders, and the objectives at hand. 

What’s the Archetype of a Good Growth PM?

In our essay about hiring a venture’s first PM, we spoke about “full stack” PMs who can both formulate and execute product strategies. In contrast, growth PMs tend to be more “angular.’ They are super analytical, have great facility with statistics, love to move fast, and have no attachment for a given feature if it doesn’t meet the desired objective.

Chamath Palihapitya seeks another attribute for growth PMs and especially for growth team leaders: they should not only be highly analytical, but also capable of what he calls “open-ended” thinking, that is, problem solving that assumes no fundamental constraints. Palihapitiya contrasts open-ended thinking with “concentrated” thinking, which seeks to maximize long-term customer value by identifying, isolating, validating, and then harnessing the mechanisms that drive desired customer behavior, through regimented experimentation and analysis.

Ideas that result from open-ended thinking might seem silly at first blush, like people wanting to open up their homes to complete strangers (AirBnB). However, some blue sky ideas can lead to spectacular breakthroughs. In Palihapitya’s view, a growth PM’s project portfolio consists of 90% bets (requiring concentrated thought) and 10% leaps of faith (requiring open-ended thought).

Given this unusual, angular profile, according to Deb Liu, only about 10% to 20% of all PMs have the right skills and attitudes to excel on growth teams. For this reason, it’s important to design a recruiting process that gauges candidates’ fit with the growth PM role requirements.

Failure Modes

Some failure modes for growth teams should be obvious: 

  • Having growth team leaders who don’t match the archetype described above
  • Lacking a robust growth engineering infrastructure, leading to slow and brittle deployment cycles
  • Iterating blindly—for example, changing fonts and colors at random—hoping for performance improvements, without a theory about the mechanisms driving performance
  • Viewing growth engineering as a silo that needn’t get input from marketing, product, and other functions
  • Getting mired in turf battles over whether growth initiatives hurt users’ experience and sacrifice long-term performance in exchange for short-term growth gains

The last failure mode often results from not setting appropriate objectives. A growth team that’s tasked with increasing topline user numbers can design features that stuff the system with low value users who bounce out without truly engaging with the product. For instance, if an e-commerce site gives a $10 referral bonus, then customers will be encouraged to flood the system with the email addresses of everybody they know, regardless of their contacts’ likely interest in the site. If instead, the objective is ‘engaged’ growth, one could modify the bonus to be only paid upon a qualified purchase by the referred user. This will decrease top-of-funnel volume, but yield better qualified and more engaged users. 

Happy growing!

Article gallery

People

Featured

Trend

Poet or Librarian?

Hiring Your First Product Leader

Deep Nishar

Tom Eisenmann

Pathways

Featured

Trend

Technical Debt

Manifest Destiny?

Deep Nishar

Tom Eisenmann

Process

Featured

Trend

Hacking or Engineering?

Managing Growth Teams

Deep Nishar

Tom Eisenmann

People

Featured

Trend

Getting It Right

Hiring Your First PM

Deep Nishar

Tom Eisenmann

People

Featured

Trend

An OS for a World Class Product Organization, Part 1: People

Deep Nishar

Tom Eisenmann

Process

Featured

Trend

An OS for a World-Class Product Organization, Part 2: Process

Deep Nishar

Tom Eisenmann

Pathways

Featured

Trend

An OS for a World-Class Product Organization, Part 3: Principles

Deep Nishar

Tom Eisenmann

Pathways

Featured

Trend

International Expansion

Oh, the Places You’ll Go!

Deep Nishar

Tom Eisenmann

Pathways

Featured

Trend

Managing Acquisitions

The Pushmi-Pullyu

Deep Nishar

Tom Eisenmann