Defining ‘growth team’

Let’s start by looking at some general characteristics of a product team

Product teams must write sustainable software that solves specific user problems very well, is supported by a suite of tests, is bound to an SLA, and introduces as little technical debt as possible (among other things). They must maintain and document this software, respond to customer requests, and are dedicated to advancing the product feature for the long term.

A product team’s roadmap is generally determined by the business and by customer requirements.

Because product teams are focused on their area of the product, their knowledge of a new user’s path through the application is generally limited to their area of focus.

The typical definition of a growth team differs in a few key ways

Growth teams may experiment with MVPs of features that generate growth, but they typically work on improving flows rather than new features.

This work typically takes the form of an experiment that seeks to prove a hypothesis as quickly as possible. If an experiment does not work, it will be removed from the product. As a result, growth teams typically favor speed of development over the sustainability of code (initially). When an experiment has proven to contribute meaningfully and is promoted to production, the team may “production-ize” the solution or find a fitting owner for the MVP within the product organization.

A growth team’s roadmap is much less defined and fluid. It is subject to the results of its experiments and new findings as the team explores product analytics and conducts research.

Growth teams intimately understand the new user’s journey through the product from marketing to sign-up and beyond. This allows a single team to be tasked with growing metrics such as sign-ups and PQLs that are heavily dependant on the initial user experience. It also reduces the requirement for all other teams to duplicate research and effort learning and improving this journey.