When I met Ryan, his problems were radically different…
They were growing quickly. His team was doing a fine job. They implemented Growth Processes, but after a few months, they realized that they weren’t moving the needle.
He had planned to launch campaigns within a few days. His experiments were launched in weeks because of a lack of attention from other people within the organization.
That’s usually a problem faced by big corporations. I never heard such a thing from a startup with 20 people. That’s when I decided to investigate.
It was after running dozens of interviews and studying hundreds of the fastest growing startups that I realized most companies don’t sincerely care about Growth.
I realized that most startups face these issues and have no idea of how to solve them. My research led me to some interesting findings that I’ll share with you today.
These lessons should help you to operate in a more efficient manner and start experimenting very quickly.
THE BACKSTORY
When companies hear about Growth as a practice, it always seems like a wonderful idea.
We live in an era where data is available at every touchpoint. This data enables us to launch things to discover what works and what doesn’t.
These experiments will empower you to improve your Growth rate over time because you’re improving the flow of users across your entire business model.
Investment decisions become simple. You just need to launch more experiments to improve your growth rate.
DOESN’T THAT SOUND NICE? IT SURE DOES. ON PAPER.
Most companies try to hire people to handle Growth. These people are responsible for launching experiments and “growing the business”.
What generally happens is that your efforts fail because Growth is the responsibility of individuals and doesn’t involve the rest of the company.
When Ryan took over his new position, he was full of good intentions. He worked through the strategy and started building a backlog of experiments.
After that, Ryan decided it was time to launch experiments. 45 days later, he had only launched one. Ryan failed because:
- Experiments took weeks to launch, instead of days
- Lack of seriousness about the process (stating hypothesis, documenting results)
- Experiments got distorted by other teams (you launch something that doesn’t look like what you had in mind)
- He didn’t have the right analytics stack
- He didn’t test the instrumentation of his tools
Ryan’s story isn’t a one-time thing. I’ve met tens of startups who tried the process and brilliantly failed to experiment.
There are a hundred more reasons why Growth as a practice could fail. Let’s focus on the first one: Experiments take way too much time.
Why does that happen? What can we do to solve that issue for good?
THE ISSUES
The process requires you to move so quickly that you can’t let anything stand in your way.
If you can’t get a hold on someone supposed to help you launch an experiments, you’ll most likely fail to launch it in time.
We’ve identified 3 main source of failures (Goal Misalignment, Team Dependance, Political Misunderstanding). We get into more details about each of them in the following section.
GOAL MISALIGNMENT
Here is a very common scenario:
- The Growth Manager (GM) needs to improve Retention. The Design team needs to re-do onboarding by the end of Q1.
- While the design team is late on their planning, the GM is waiting to launch her first experiment. The design team becomes a bottleneck.
- By the time Design is done with the onboarding, The GM has been working on the backlog (thus delaying the experimentation).
- When the design team finally has some time to work on the experiment, the experiment is late by 45 days.
The Growth Manager is late. She had hoped to launch 2 experiments per week, she was only able to launch 1 in 45 days.
The issue is simple. Their goal is different. The way to achieve them is also different. These teams can’t work together just like that.
TEAM DEPENDENCE
They’re dependent on each other. If one team fails to deliver their work within the given timeframe, the other will suffer.
Doing so is hard for both teams. The Growth Manager may keep pushing for her experiments, but the only thing that the design team wants to work on is the onboarding.
Sometimes a holdup on a project is due to a circumstance that’s out of your hands. Successful teams documented those dependencies and understood the associated risks. They built clear plans and check-ins for working through them.
– Jay Simons (Atlassian)
The best way to work through these dependencies is to re-organize the way they work in a way that alleviates all these dependencies.
POLITICAL MISUNDERSTANDING
When people notice someone is working on their own garden, they feel worried. It’s their work and they don’t want anyone to touch it.
The GM sometimes has to touch the product to have impact. That generally leads the Product team to think that they did a poor job and that the GM is trying to take their ownership away.
It’s hard because you’re stepping on someone else’s shoes!
That’s because Growth as a practice is misunderstood within the organization. People believe that you’re taking away their role whereas in fact, you’re just trying to build upon it to make it better.
THE STORY
Jerome (name was changed) was hired to bootstrap the Growth Team at a very successful company. When trying to launch experiments, he often got jammed by the Product Team.
As a good Growth Manager, Jerome doesn’t want to launch beautiful piece of code. He wants to get it out there ASAP.
We know that 3 out of 4 experiments always fail. Why should we write something great that will get thrown away?
Like most product teams, they didn’t agree. As difficult as it may be for Product teams, it’s okay for an experiment to avoid code standard (as long as it doesn’t introduce bugs).
Both teams are right here. Growth wants to launch quickly. Product wants to launch something that live up to their standard.
It truly shows a misunderstanding and miscommunication between the teams and it can be tough to work through that…
THE DOWNSIDE
By having to work through these issues, the speed of learning of everyone in the company is minimized. That leads to:
- Issues in terms of communication
- Frustration from the team that’s being held: their lateness is out of their hands
- Friction and Politics between your different teams (Collaboration becomes harder)
- Lack of pressure because no one can be held accountable (“We’re late because of the design team”)
- Reduced creativity because your people are working with others that are wired like them, they won’t get truly innovative ideas that way
THE END RESULT
The Growth manager wants to launch things at lightning speed. But she needs resources from other parts of the organization who have different goals and priorities. Thus, the iteration lasts much longer than it should.
Since speed of learning is determined by how many experiments you can launch, if you increase the iteration duration, you’ll ultimately decrease the speed of learning. By doing so, you’ll highly limit the impact of the GM on your bottom line.
That’s why it’s so hard to implement Growth Processes within teams and companies who aren’t designed for high speed of learning.
The efforts of implementing Growth Processes are generally dead by now. The GM tried to launch some experiments for a few weeks but the organization wasn’t ready.
The GM is now doing something else. She might join the product team or become an in-house consultant (more on that later).
How can we design our environment to foster speed of learning? How can we make sure everyone understand that system?
THE SHORT TERM SOLUTION
Successfully implementing these processes doesn’t require a different organization from day one. You just need to encourage change by taking things step by step.
People don’t believe in what you’re trying to achieve when they’re worried that you’re going to hurt the business, product and customers, rather than help it.
The main priority when you’re getting started is to prove results to the entire organization. That last point is just primary:
- People want to do right for the customer; they want to create an experience that solves the customer’s needs.
- They also want to grow the business as fast as possible. It’s in their best interests.
People aren’t here to slow down your Growth efforts. They want that to happen. You just need to prove to them that what you’re doing is for the good, not harm.
How can we get started and prove results to the entire company without taking away too much resources?
THE CONSULTANT
Back to Jerome, he couldn’t launch enough experiments to have a positive impact on the business; he quickly became an internal “Growth Consultant”.
He now helps every team within the organization to get into the right mindset and consider everything they do as an experiment.
In that fashion:
- He let everyone take ownership of their roles;
- He educates everyone about the Growth Mindset
This position can be a great start because it leaves you the time to educate everyone in the company about these methods.
THE 5-DAY GROWTH TEAM
You don’t have to change the entire organization to start experimenting. Why don’t you start with a small pool of people during a week?
Gather a few people that are willing to try something new. Take them in a room and launch some experiments for an entire week.
That would completely lift all the issues raised above. That will give you some data around how things are working and if that had a positive impact on your bottom line.
You can then promote a case study with everyone else to show your results and get everyone onboard.
If you struggle to understand this concept, you should read Sprint by three partners at Google Ventures. The process is different, but the speed of execution is similar.
The Company-Wide Hackaton
Dapulse is in the Project Management space. They have an innovative product and it’s quite hard to explain the value to someone that has never used Dapulse before.
They were struggling with 4 different areas:
- Website Conversions: Homepage, Pricing
- Onboarding and First Time Experience with the product
- Mobile signups to desktop
The team also struggled to get fresh ideas (thinking outside the box). To improve their growth, Dapulse organized a company-wide hackaton.
They looked at their entire funnel and created small groups with various high impact areas (e.g. on-boarding, sign up flow).
Each group involved someone from every department (Product, Design, Marketing, Customer Success and Support).
By so doing, Dapulse generated ideas from many different perspectives. The ideas were launched in a few days.
Instead of going all-in, Dapulse tried it first.
The best part? It was fun. The entire team got out of the daily grind to work on a complex problem. Who doesn’t want to be part of that?
They know that it’s working, what’s next? They could start by:
- Doing that more often: Monthly or Quarterly
- Dedicating a small team into launching these experiments
You don’t have to be all-in. Inspire yourself from this story and try to find ways to experiment while limiting risks.
What happens after that? You’ve proven results but what can you do to take it further?
THE LONG TERM
I always thought that the Process and Strategy were the key pieces of the Growth puzzle. I quickly realized that correct implementation of these methodologies would require a much deeper kind of change.
The only way you can start with Growth is to educate your entire team and show them that it can have a positive impact on both customers and the bottom line.
It requires change from the entire organization. It’s a mindset change!
It also requires changes in Structure, Responsibilities and many other things. The only way you can make it to this ideal is by taking things slowly.
There is no right or wrong answer. Growth is a new field and rare are the people with 10 years of experience.
Overall, you can find some information about Growth Team Model. However, implementing such changes will require time and commitment.
Rome wasn’t built in a day. You’ll need to experiment with different structures and go gradually. Just as an example Buffer changed their structure 4 times.
Spotify is also well known for their experiment on their Product Team structure.
CLOSING THOUGHTS
“The others” are depicted like the nemesis of Growth. This is only one part of the story and this thinking is plain wrong.
In the end, Growth and Product teams aren’t the only ones involved. Everyone is, Including Marketing, Support and Customer Success departments. They all have something different to bring to the table to build a better experience.
If someone can have a positive impact on the users and on the business, the title / department of that person doesn’t matter.
The only way to get into that thinking is to put your ego aside and start thinking about your users and customers.
