How to Hire and Structure a Growth Team – TechCrunch
A single adjustment can’t get the job done
Everyone in an organization should own growth, right? It turns out that if everyone owns something, nobody has anything. As a result, growth teams can create enormous friction losses in an organization when they are introduced.
Growth teams are twice as likely among companies that increase their ARR by 100% or more annually. In addition, they also appear to be more common after product marketability is achieved – usually after a company has made around $ 5 million to $ 10 million in revenue.
I’m not here to tell you why you need a growth team, but I’d like to point out that product-centric businesses with a growth team get dramatic results – the average free to paid conversion rate doubles.
How do you hire an early growth leader?
According to responses from product benchmark surveys, growth teams have made a dramatic transition from reporting on marketing and sales to reporting directly to the CEO.
Some of the early writings on growth teams say that they can be structured individually as a stand-alone team or as a SWAT model in which experts from various other departments of the organization come together on a regular basis to find solutions for growth.
My experience and the data I have gathered from software companies with a focus on business users have led me to the conclusion that growth teams in enterprise software should not be structured as “SWAT” teams in which cross-functional leaders come together to think critically about the company’s growth problems. I find that when problems don’t have a real owner, they don’t get resolved. Growth issues are no different and often not prioritized unless it’s someone’s job to think about them.
Getting product centric isn’t something that happens overnight, and hiring someone won’t be a silver bullet for your software.
I’ve put the initial growth setting in a couple of simple buckets. You have:
Product-oriented growth experts: These people are interested in optimizing the user experience, reducing friction losses and expanding usage. They’re usually pretty analytical and may have a Product, Data, or MarketingOps background.