How to scale cross-functional growth teams

In one of our previous essays, the biggest misconception about growth, we talked about the set-up of your first cross-functional team. If you didn't read this piece, please do so before you continue. It's critical to understand the fundamentals of product-led growth because this lies at the core of rapid growth within successful startups.

At every stage of your company, the structures of your cross-functional teams' set-up will vary. It needs to grow hand in hand with the maturity of your company.
You can start scaling your teams by letting them focus on multiple challenges at once. These problems can be regarding the famous AARRR framework from Dave McClure, different product features or combining this with even geographical locations. You will start hiring a VP of growth, who will be responsible for these multiple cross-functional teams and every team will have different skillsets depending on the problem at hand. In this essay, we will talk about the different set-ups of cross-functional teams within organisations, how should you scale these teams and how to align them with the rest of the organisation.

Different team structures

When your first cross-functional team is moving the needle for your organisation, you can start with focusing on multiple problems at once. It's important to first think about the structure of these teams relative to your current company structure. When you will not do this, responsibilities will overlap and people miss clear metric accountability. Therefore, we suggest to first think about the following two structures.

Independent model vs. functional model

Within Off The Record we are a big fan of these models about structuring your cross-functional teams within an organisation. There is a great blog about these models from Andrew McInnes. Both models have ups and downs but our personal preference when you start scaling your growth team is the independent model. Meaning your growth department has a VP of growth and is working autonomously on different parts of the customer journey or product features. You also will have a separate marketing team, product team, engineering team etc. but as we mentioned in our previous read they target on validated initiatives and your growth teams on big hypothesis.

When growth is deeply embedded in your organisation the functional model becomes more interesting. At Off The Record we advise to use this model when you have a strong analytical foundation (data-driven), the growth mindset is deeply embedded (iterative and learning-driven), everybody has there own growth OKRs, you have one clear North-star metric and people understand the concept between growth- and non-growth initiatives.

Within the functional model, teams will decide themselves which growth- and non-growth initiatives get worked on, especially the VP product manager. There will be no Head of Growth who will manage this process because everybody in the organisation understands the need to contribute to the companies growth metrics. We often will start applying this model when the above requirements are met and you have more than 10 independent cross-functional teams in your organisation.

The focus of your cross-functional teams

When you decided which model you would like to use you need to decide on which problems you want your cross-teams to work on. We mostly use one of the following:

1. Metric focused
   When you use metrics as your foundation for defining the cross-functional focus points you will probably use the famous AARRR framework from Dave McClure. However, instead of naming your teams' acquisition team, activation team, retention team, we like to define the problem within that area as the team's name. (e.g. SEO team, onboarding team, win back team)
   
2. Feature-focused
   Using features as your foundation will mostly be possible within organisations where the product is non-tangible. Possible options are, sign-up flow, create a post flow, radar function etc. When you choose this option, you need to have at least a few insights that improving these features will improve your growth metrics. If not, start with metric focused teams.
   
3. Geographical  focused
   Finally, if your business model has different growth challenges within different geographical locations (e.g. one city needs to work on improving referral rates and another city needs to focus on activating new users) then start with this option. The breakdown of geographical focused teams will help you maximize ROI in every city.

Which one to use, heavily depends on your product and business model. More technical products (Spotify, We Are Eves, Juke, Storytel etc.) will be more feature-driven but more tangible products (Marie-Stella-Maris, Felyx etc.) will be more metric specific. Whatever you choose, keep in mind that your team set-up and focus can change after each month, quarter or year.

Growth- versus Non-Growth initiatives

When your first cross-functional teams are growing and you let them zoom in on product-led initiatives it will definitely happen that this will have a high impact on your product roadmap. This means that prioritization is becoming more and more important for your product roadmap. Therefore, it's important to divide the roadmap with growth and non-growth initiatives.

Growth initiatives

This are improvements and experiments which are based on data and not on intuition or gut feeling. All the initiatives follow a clear process, based on research, creating a hypothesis, launching MVP's, analysing results, systemise and focus on getting more people experiencing the core value of your product without the loss of product experience. Growth initiatives needs to be explored first before you start with building a big epic.  

Non-growth initiatives

These are improvements that probably have a non-iterative approach, initiatives are more or less about improving the customer value and the implementation takes a longer time (3-6 month). This doesn't mean this will not have any impact on your metrics, but the implementation is more vision-related then metric related. Non-growth initiatives can be things like invoicing, back-end related topics and probably not have a clear hypothesis.

If you don't divide your roadmap into two different initiatives you will encounter problems along the way. Your cross-functional team wants to move faster but will not be able because the roadmap is already full with longer bets. This would heavily impact your product-planning and will increase costs, not revenue or users. Therefore we suggest using two swim lanes and divide these initiatives so your roadmap is also aligned with your cross-functional teams and non-cross functional teams way of working.

Scaling the business or running the business.

When your cross-functional teams scale it often occurs that people will be working in two teams. You are not able yet to hire hundreds of new people but you need to keep an eye on multiple things. Therefore, we mostly introduce growth days. This way you can divide your work hours in scaling the business and running the business.

Scaling the business
On these days you will be executing, analysing and preparing experiments or having meetings with your cross-functional team members and not your functional team members. It helps when members schedule this time on the same days to maintain attention, therefore we call this your growth days.

Running the business
All operational work will be done during these days. Also, 'always on' (validated) work will be done during these 'normal' days. You will probably also meet with functional team members. After a certain period of time always check how much time you spend on running the business vs scaling the business. It can occur that some periods require more operational work instead of scaling but always try to create the perfect balance between these two.

Align your functional and cross-functional teams

Finally, when you use the independent model and your cross-functional team members work fully on the biggest growth levers, we like to ideally create a clear split between cross-functional teams and functional teams.

The cross-functional teams work on problems that need to be validated and your functional teams will work on optimising validated initiatives. E.g. When a cross-functional team validates a high-over hypothesis, like the validation of an MVP loyalty program, we prefer to task this to the product team who will become responsible for optimising the flows and make it pixel perfect.

Again, when you choose to work with the functional model the alignment of these teams will not be necessary because every team will work on growth and non-growth initiatives.

Conclusion

Scaling your cross-functional teams can be hard but will pay off in the end when done correctly. If your teams (cross and functional) become miss-aligned it will affect product planning a lot which could impact your costs.

Therefore, start with choosing which model (independent or functional) suits your organisation best before continue scaling. If you choose the functional model from the start, please be aware of the challenges and general culture in your company. If people don't understand growth vs non-growth initiatives this model will only give you problems later on.

If you choose the independent model, make sure your teams are aligned. Meaning that your cross-functional team works on big hypothesis and your functional team on optimizing validated hypothesis.

Secondly, focus within every cross-functional team is key. The most common and easiest one is metric focused teams but if feature-focused teams suit your business model or product better, use that one instead.

Don't start a revolution but scale teams like an evolution. Don't start with 10+ cross-teams at once. Start with one, refine the process and scale your teams slowly. This will eventually speed up the process and will have a way better adoption rate.

And finally, the most important learning we always apply is to scale your teams based upon the culture in your organisation. Don't do it because it's hype, only do it because it makes sense.