Lessons learned from starting a growth team

In a modern product company, learning fast has become the most competitive advantage. However, learning by delivering is expensive. According to Marty Cagan, at least half of your ideas are simply not going to work. Other studies, for example made by Microsoft, have shown that the success rate is most likely even lower than that.

But what if there is a faster way to gain insights about your product and your customers than building and delivering? What happens when you shift the focus from a build-mindset to a learn-mindset? When you realize that your backlog is just a bunch of untested hypotheses. We wanted to find out: so a year ago we started forming a growth team here at Volvo Car Mobility. We are now fully operational and on a mission to spread experimentation and a data-driven way of working in our organization. In this post I share our learnings from this past year and will hopefully inspire you to start your own growth program at your company. It is going to be a long-ish post but feel free to skip to the end for my key takeaways.

Don’t call it a growth team

So what is a growth team? It can mean almost anything. For us it means a team that focuses on creating hypotheses and then validates these hypotheses by using experiments and statistically sound methods. In practice this means that we run a lot of A/B tests. The idea is to build as little as possible and always be focusing on what can be learnt from the experiments. Our long term goal is to spread a culture of experimentation across the whole organization.

When we started our team last year we named it Team Growth. That is not a good name… It is too generic and it can mean so many different things. Growth and growth hacking are terms that have been floating around the marketing space for years. This has often come to mean activities to attract as many users as possible as fast as possible. Our team is experimenting with the whole product and across all user journeys. We span both activation and retention and see ourself as an experiment program not a marketing growth team. Having this name has caused some confusion. One year later we still haven’t come up with a crisp name and are now going under the name Growth & Experimentation or GX for short. It is not fantastic but at least we have an opportunity to start talking about A/B tests when people are wondering about our name.

Start under the radar

To successfully launch a program like this in an existing organization, you need to start small. A year ago, a product manager, a retention expert from marketing and I started to lay the grounds for our growth and experimentation program. We did it low key and very much in a skunk work kind of way.

We quickly realized that we wanted to get the tools we needed in place before we created a full blown team. The reasoning was that we understood that once this new team was announced we would need to get started running, quickly showing the rest of the organization that this could be done and was worth the investment.

The big players like Spotify and Amazon build their own experimental platforms. We knew from the start that we could not do that. We needed to find something off the shelf.

We went about this thoroughly, spending almost two months meeting suppliers, testing open source tools, and setting up small- to medium-sized proof of concepts. We ended up with a shortlist of seven suppliers and after the evaluation we chose a platform called Eppo. We could not be happier with that choice, but more on that later.

Spreading the gospel

Our mission in our team is “To get every team at Volvo Car Mobility experimenting by leading the way”. The way we are doing this is first and foremost by running as many experiments as we can. Our team north star is “Number of experiments run” and our goal is to launch one experiment per week. A very ambitious goal and a goal we still have not met. But we are getting closer. The first quarter 2023 our number was up to 0.58 experiments launched per week and we are getting faster with each experiment we run.

We have set this north star because we believe that the more experiments we run, the better we get at it which will lead to more impactful learnings.

We have learnt that a combination of running experiments, facilitating hack weeks to get other teams to start experimenting and just extending a helping hand when other teams have questions is a good recipe for success. The key is to be visible but not overwhelm the organization. We are always running experiments but we don’t want to be at all demos and all company meetings talking about our latest findings. We need to find the right time and place to share learnings and our ways of working.

Tools are great and having a compelling vision and mission is crucial but the most important thing when starting a program like this is finding the right people. Being in a growth team is very different from being in a traditional product or feature team. You will need people that are ridiculously curious and that thrives in the high speed, high uncertainty landscape that this kind of team operates in. The most important thing for us is always to scale down what we build, finding the smallest possible thing we can build to prove or disprove a hypothesis. The whole idea with this team is to learn before we build. You will need people that enjoy that kind of challenge.

You also want people that can act as good ambassadors. You need a crew that loves to help their fellow coworkers without being snobbish about the experiments running outside the growth team. The growth team will always be the experts in creating good experiments but it is key when spreading new ideas to let people figure out things for themselves.

Ok, so who do you need? In our team we have

Product Manager
The anchor of the team. Someone that can evangelize and be the champion of the program and also help the team organize their work. The Product Manager holds the team together and pairing up with me — the engineering manager — to make sure we are working as one team and in alignment with our vision and mission.

Growth Lead
Experimentation is hard. There are a lot of traps to fall into. Not only around making sure we are doing experiments that have a chance to yield statistical significant results, but also making sure we are creating hypotheses that will be beneficial for the users and for the company and have the best chance for learning opportunities. Our growth lead helps us stay in a growth mindset and leads the day to day work in the team.

Data Analyst
The data analyst’s main responsibility is doing pre- and post-experiment analyses and to package the learnings in a way for them to have the most impact. Our data analyst helps us with this and also has a background in web analytics so he can help lift the company standards in frontend tracking.

Developers
We need developers to build our A/B tests and to make sure we have the tracking we need in place in the product. In the team we have 2 developers who both think it is great fun to jump between frontend and backend stacks. Also all our experiments live in someone else’s code. The developers in the team also have the skill and empathy to understand what it means to operate in other teams’ codebase. And they are both great ambassadors for growth and for a data-driven approach to development in general.

Designer
We need a designer for the same reason we need developers. We need to be able to quickly create designs that look and behave as beautifully and well functioning as the design we have in the rest of the product but that are created at a much higher pace. Not an easy task and something that takes a lot of skill to pull off.

Service designer
We are lucky to also have a service designer (CX) in our team. Her main responsibility is to help us make sure that we are utilizing all the knowledge we already have about our product and customers when we create our hypotheses. We use our user research to help guide us where to experiment and what to validate.

Marketing automation and retention experts
We have two team members with a marketing background and it has been amazing to have them as part of the team. By having experts in communication and in the tooling needed we are able to use everything we already know about acquisition and retention and also leverage the full power of our marketing automation toolchain when we create our experiments.

Partners and platform

To be able to be successful we realized we would need to hit the ground running. And to do this we decided to leverage the tooling that is already out there and also partner up with people that have deep knowledge in the subject matter. Thanks to Eppo our experimental platform, we were up and running fast and now Eppo is playing a very important role in our work with scaling the experimentation program.

Buying an external platform can mean trouble: you have to find a product that matches how you want to work and a supplier whose values match your own. We wanted to take a data warehouse centric approach. We want to control our data, not send data to third party tools. We also think it is crucial to be able to use all our existing customer segmentation and business and operational data in our experiments. Eppo’s platform sits on top of our data warehouse and can therefore act on all data we have (and want to give Eppo access to), making experimentation design and post experiment analysis a breeze. Furthermore, Eppo has proven to be a very important partner, helping us onboard not only in the tool but also has proven to be a good sounding board for us when we built up our program.

We also decided to partner up with the Stockholm based consultancy firm Signific. Our growth lead is a consultant from Signific and we also had the pleasure to have a Product Manager from Signific for a couple of months to get us started. Having these kinds of experts as part of the journey has been really helpful.Thank you Eppo and Signific, you are awesome.

Key learnings

• Find the right people. You need people with a curious mind, that like to work fast and are good at finding shortcuts — and most importantly love having their hypotheses being proven wrong.
• Work together. We have this year been defaulting to do work together. This has enabled us to create better experiments and we have learned a lot from each other. And of course we had loads of fun exploring this new field together as a team.
• Cross functional means marketing included. Having marketing as part of the team has been absolutely vital for our success.
• Finding the balance between doing your own experiments and helping other product teams is hard. If too much inward looking the team becomes irrelevant. But too much focus on helping other teams, the team becomes reduced to a support function. If that happens the team loses focus and momentum and cannot be the experts we need them to be. This has maybe been the most difficult part in all of this and we are still trying to find a good balance.
• It will be painfully slow in the beginning. Your first 10–20 experiments or so will be painful. Maybe you lack frontend analytics in the part you want to experiment on, maybe you even find out you lack the business metrics. People will be nervous when you experiment in their domain and toes will be stepped on. There are a lot of obstacles in the beginning. It is important to see these as necessary bumps in the road and recognize that for each experiment it gets easier.
• Leverage all the help you can get. Look for competence in your company and don’t forget to look outside product and engineering. And it could be a good idea to also bring in some external experts to get you up and running fast.

This past year has been so much fun. And it is also very cool seeing a growth mindset spreading through the organization. If you are thinking about starting a program like ours at your company or if you already have started and want someone to share and compare ideas and thoughts with, do not hesitate to reach out to me. I would love to get a knowledge sharing community up and running.