How to consistently run a better Growth Process in your team (based on my experience mentored 40+ growth teams)

acer621

New member
Having mentored more than 40 different growth teams across industries over the last couple of years, I've decided to pen down a couple of things that I noticed can make a huge difference between the best growth teams and the rest. I plan to make a much larger playbook for growth teams going forward (feel free to reach out if you'd like to discuss)

As a Growth team, your first step is to figure out your North-Star Metric, Key Metrics, and Objectives. Once you've done that, and you're starting to run some experiments already, the next biggest hurdle that you would face is ensuring consistent team alignment on what worked, what didn't, and what we're doing about it. This translates to:
  1. Consistent weekly growth meetings
  2. Consistent weekly experiments
  3. Consistent sharing of learnings
As you can already see, consistency is absolutely key! Let's dig into each of these:

Consistent weekly growth meetings

To be successful with growth, it’s about being a bit stubborn with a routine. No, not running the same experiments all the time. By stubborn I mean you need to review, brainstorm, and plan as a team, consistently.

This is the ideal 1 Hour Weekly Meeting structure that I've found to make a difference:
  1. Look at how your metrics are moving (10 minutes)
  2. Check the status of your experiments - what worked, what didn’t, how you’d improve next time (15 minutes)
  3. Define what you want to achieve next week (10 minutes)
  4. Get to brainstorming ideas on what experiments you can run to achieve those goals (20 minutes)
  5. Quickly assign who is responsible for what in the next week (5 min)
Consistent weekly experiments

In the beginning “smaller is better”. You’re low on resources, need to test and see what works, and be able to pivot quickly. Instead of running complicated and long experiments that you’re not sure will work out - cut them down to bite size chunks. Sure, at the beginning you’ll spend more time planning your experiments than executing them, but in return you’ll get:
  1. A team that’s more focused and data oriented.
  2. Quicker wins, better morale.
  3. Learnings at the cost of little resources.
  4. Efficient iterations.
Consistent sharing of learnings

Of course, during any experiment your team runs, they need to ensure proper documentation of the learnings, that are also accessible by the entire team. This way, everyone will not only find ways to improve or what experiments to increment next; they’ll also know, more importantly, why things didn’t work. And believe me: learning from “mistakes” and understanding how not to repeat them turns your growth from steps to leaps in just a matter of weeks.

With all these three, your team will have the visibility, focus, and documentation they need to just get to it and grow consistently.

Hopefully this helps some new growth teams to manage their process better and get more sustainable results. If there is a particular process that worked for you, I would love to hear about it as well!
 
@acer621 Very good points. I'm the first in to this startup on the commercial side. New (AI) product, good product, sales has been done in founders network for a couple of months. Prospects: mid market and up, many industries, global. They want to "start small and see what works" before I get a chance to hire to my future team. I'm struggling to execute enough tests to get any results back. Can't get more people in my team atm. Got any tips? I'm sick of coming back with "not yet" "I'm going to" all the time.
 
@chaitealatte456789 That's a very interesting problem you've shared. I've definitely come across that many times. It's a challenge every growth person in an early stage faces, with getting buy-in from the management to invest more into growth.

The way I usually deal with it is exactly what you've mentioned: start small and show results. And I add that with showing how we can get bigger results by investing more.

For example, if my goal is to increase the number of qualified leads in the pipeline,

I might come up with different experiment ideas, and run just 2-3 of them because they're easy to run (e.g: Scrape LinkedIn profiles, get email addresses, and send personalised emails). The key here is to get as many ideas as possible, so that you can prioritise based on the resources you have at hand for now (I usually use the ICE framework).

I'll report back saying "We've run these 3 tests to achieve our goal of 100 qualified leads. We have 105 leads from this one test, while we've learned XYZ from the others. However, in order to execute on those learnings and get even better results, we'll need some more resources."

Having said that, doing it only once isn't going to get you what you need. You need to be consistently showing results and learnings, and proving how more resources will accelerate both the learning curve and growth. It's a long process, but much more effective than just hoping they'll understand.

Hope this helps :)
 
@acer621 I like what you shared, but I have to be honest, documenting everything is pretty hard, we are mostly focused on execution, and then after months we just end up repeating the same "experiments"... Are they even experiments by then, if we experimented before and just didn't learn from it?

How do you go about sharing the experiment results?
 
@carlossantana305 Documenting experiments is definitely one of the most painful parts for any growth team member. It's time consuming, and doesn't seem to add as much value compared to actually executing and getting some results.

However, imagine the time you've lost in repeating the same mistakes, and the cost of doing that, and you can see how it's worth investing time into documenting.

Showing this ROI of documenting to the team should go far in getting buy-in from everyone to follow the process.

Adding to that, I usually set up incentives for the team to close their experiments and share learnings (like additional resources to execute their favourite ideas, etc). This helps them get started with documentation in the beginning until they start seeing the value of it by itself.
 

Similar threads

Back
Top