Growth Hacks: Should you manage your growth team separately?

Growth Hacks: Should you manage your growth team separately?

Ready to Hack Growth?

Should you manage your growth team separately?

“Should I manage my growth team separately” is a question that I have been hearing more than once from heads of growth of companies of all sizes.

In the end, what they really want to hear is more opinions and arguments so they can discuss it internally with whoever the approver is (it can be the CPO, the CMO, and more mature companies, the CEO).

Could your Sales team manage their pipeline with a Trello? Yes.
Could your Marketing team manage their leads with a spreadsheet? Yes.
Could your Ops team manage their routine with a To-do list or even post-its? Yes. So… why don’t they?

1) Projects (one time) vs. Process (ongoing)

For once, those are all constant processes that tend to increase in size, and like a domino effect, it leads to an increase of complexity, management necessity, data generated, and data analysis… You get the idea, right?

If you are doing a one-time job with a pre-defined beginning, end and no need to evolve upon it, I would definitely use a general (and preferably free) tool. However, if this is — or will be — an ongoing process, make sure that you are starting out with the right tool and people, so your chances of succeeding increase significantly.

2) Cultural Changes

A lot has been written about the growth mindset or the cultural changes required for the successful implementation of a growth team. Culture is not something you can touch, and definitely not something you can buy (which makes it harder for people to understand).

But let me borrow Jeff Bezos quotes from the 2019 Amazon shareholders letter and try to explain what it really means:

From very early on in Amazon’s life, we knew we wanted to create a culture of builders — people who are curious, explorers. They like to invent. Even when they’re experts, they are “fresh” with a beginner’s mind. They see the way we do things as just the way we do things now. A builder’s mentality helps us approach big, hard-to-solve opportunities with a humble conviction that success can come through iteration: invent, launch, reinvent, relaunch, start over, rinse, repeat, again and again. They know the path to success is anything but straight (…)

(…) None of this would be possible without a culture of curiosity and a willingness to try totally new things on behalf of customers.

As a company grows, everything needs to scale, including the size of your failed experiments. If the size of your failures isn’t growing, you’re not going to be inventing at a size that can actually move the needle (…)

3) KPIs

One of the most common mistakes I have seen growth teams making is running experiments for the sake of running experiments. This means they are not connecting their tests with an objective, or they are not using the North Star metric concept nor the OMTM (one metric that matters), neither the Obsession metric — or whatever you would like to call it.

During a chat with Rajan Sheth, Growth at Heroku (Salesforce) SALESFORCE/HEROKUGROWTHMANAGER, he mentioned their growth structure: a three-layer cadence of KPIs where every test needs to be connected with a superior level KPI, which also needs to be connected with a major company KPI.

This ensures the growth team is not having 1% progress in every direction but 100% in one single direction — making it easier to demonstrate its value company-wide while also having focus.

4) Special Integrations

Your project management tool probably won’t be integrated with your Analytics account. Your stripe account likely won’t be integrated with your intercom account. This happens because each specialized and dedicated tool focuses on building integrations that will provide real value to their target customers.

A growth management system will likely integrate with your marketing and product stack, while your project management tool will likely integrate with time-tracking, expenses management, etc…
This increases data-confirmability since it is being extracted and updated through its original roots instead of manually or through multiple layer integrations (data center > spreadsheet > Zapier > pm).

5) Risk aversion

As our research The State of Growth has shown, the most successful growth teams fail in up to 75% of their experiments. This is comprehensible if we take into consideration that growth teams will be running experiments of things that have never been done before. They will be thinking outside of the box and taking risks that no other department can afford to take, being responsible for executing tests that no one is sure will work out.

Take for example the OKR methodology, which offers a 30% margin of error (meaning if the whole company achieves 70% of their KR, the company has done well and if 100% is achieved, the company has outperformed themselves and done extremely well). If every other department of the company starts to fail in 75% of their goals, everything will fall apart.

So if you are managing both words under the same roof, with the same rules, same people, and setup, two things can (likely will) happen:

  • Growth team do not take enough risks: this means they are betting on tests they are confident will work out well, which also means they are not truly innovating, and the expected results will likely not be out of the curve (at least not achieving sustainable long term growth);
  • Other teams will take too many risks: in this case, which is even worse, other teams will incorporate the growth mindset and will start to take too many risks. This can increase the failure rate of their operation and the results for the company as a whole can be catastrophic.

Thoughts? Let us know.
Actions? Try out Experiments!


Should you manage your growth team separately? was originally published in Growth Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Join The Rockstar Entrepreneur Community Now: Start Rockin Now

Similar Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *