What is a Growth product team’s product?

About a year into my first Growth product job, the company I was working for hired a new head of product. Soon after he started, he disbanded the Growth team. He argued that everyone in the Product organization should be focused on growth, not just one team. The logic seemed sound enough. If other product managers weren’t focused on acquiring new users and retaining them, then what else could they possibly have been focusing on? Diligently, I shifted my focus to the new product area to which I was assigned. 

But I continued to follow the Growth space from the sidelines, attending the Reforge Growth Series in its early days (before it developed into a cult-like following) and referencing concepts from Andrew Chen and Casey Winters on a regular basis. I came to discover and appreciate that, while achieving growth-related outcomes is everyone’s job, Growth — capital G intended — isn’t and shouldn’t be. Coming full circle, I’m currently VP of Growth at Betterment, and a passionate defender of the line between Growth and what we traditionally think of as Product.

You say you’re a growth product manager. So, what’s your product?

When a new engineer or designer joins the team, I walk them through how I distinguish Growth from Product. It really comes down to what the teams’ products are. For a traditional Product team, their “product” is usually a set of features, functionality, and user experiences. For Growth, I stress that the “product” is actually a way of working: rapidly testing robust hypotheses, interpreting the results, and generating the next set of testable hypotheses from those interpretations as quickly as possible. When you’re on a Growth team, either as a product manager, designer, or engineer, your top priority is to enable a rapid test-and-learn cycle. The development of specific features and functionality falls within that cycle. However, unlike the work of a traditional product manager, it’s not the heart and soul of the work.

That’s because there’s a different set of primary motivations underlying the two types of teams. Growth teams are primarily problem-motivated teams: how do we increase our new and active user numbers? How do we connect with users to prevent them from churning? Product teams, on the other hand, simultaneously juggle offensive and defensive motivations. Offensively, Product teams create or define new categories through the features they build. They seek to further differentiate against other products. Defensively, they build experiences that engage users in order to solidify usage. Problem-solving certainly exists in a traditional product manager’s repertoire. However, it’s part of a broader set of strategies for achieving outcomes. For a Growth product manager, I’d argue that it’s the strategy for achieving outcomes. 

Growth Product teams

There’s usually not a single, obvious solution to the problems a Growth product team tackles. That’s why Growth teams need to invest more heavily in working effectively than in the development of features and functionality. In order to drive impact through problem-solving, it’s essential to identify the right problems to begin with. It’s also important to establish efficient feedback loops that indicate the success or failure of a tested solution. Even if a solution “wins” a test, there’s opportunity to iterate and improve. Again, this requires an effective process to accomplish successfully.

There are lessons in this model that can benefit all product managers. Not just those that sit within Growth teams or have Growth ambitions. Approaching your product development process as a product, similar to the way Growth teams do, can open your eyes to new methods of discovering and delivering features. Methods that may end up yielding better results — or help you avoid over-investing in feature scoping. After all, like churn reduction or new user growth, there’s no single, obvious solution for building great products.