How to scale (2 of 5) – Product team structure

Welcome to the second part of my ‘How to scale’ series (you can find part 1 here).

One of the first objectives when thinking about structuring your product teams is to ensure that Product is separated from Core engineering.  The core engineering team can then focus on creating architecture that can scale, and services that can easily be consumed by product teams (e.g., environments as a service, infrastructure as a service, deployment as a service), while product teams can focus on building experiences that customers interact with.   A good analogy is that the core engineering team build the iPhone, while the product teams build the apps.

In this rest of this post, we look at scaling product teams, the different structures and the advantages and disadvantages of each.

Focus Advantages Disadvantages
Product or feature teams

(e.g., credit card, savings, loans)

Examples include: Atlassian


Best for companies with more that have or want more than one product (i.e., companies trying to cross the ‘gap’ outlined in my last post)

  • Very commercial, clear alignment between teams and business impact
  • Each team has in-depth knowledge on target customers
  • Easy to link company KPIs to team KPIs
  • Clear accountability and governance as teams and leaders have a clear responsibility
  • The team is more likely to maintain /refactor existing code
  • A cohesive product, where work focuses on the biggest impact on the customer
  • Cohesion across products will suffer and need to be coordinated more.  Spotify Chapters and Guilds are a good solution
  • Breath of work for people is narrower. Mitigated with limited ‘tours of duty’ (9 months), good coaching and project work
  • Team focus on product and not customer experience.  Executive and marketing need to help teams focus on the experience and ensure that the together all products make sense to customers and reinforce each other
  • More challenging to ensure the company has a balance between short-term and long-term
Experience centric teams

(e.g., onboarding, referral)

Examples include: Medium


Best for companies that are trying to find product-market, i..e, are in the ‘staring a band’ phase.

  • Good in-depth knowledge of specific customer problem(s)
  • Solve the most pressing problem facing the company
  • Difficulty prioritising features where the value is long-term or unclear (e.g., refactoring)
  • The consistency of products and across the company is more difficult, requiring more meetings or a team to focus on ‘the whole customer.’
  • Lack of commercial focus, as lots of teams, are involved in each product
  • Difficult to determine the impact of changes on whole customer funnel
Project teams

(e.g., growth, launch joint accounts, fix ledger)

Examples include: most digital banks, most start-ups


Best for companies that are just starting out (starting a band)  or have high levels of dependency on third parties

  • Good agility as new ideas can be picked up easily
  • Value as teams work down ‘master backlog’ of most valuable work
  • Improves key metrics (acquisition, conversion, retention)
  • Difficult to coordinate
  • If executives change direction too often the teams will never get anything done and become very frustrated
  • The consistency of products and across the company is more difficult, requiring more meetings or a team to focus on ‘the whole customer.’
  • This is most like an ‘agile at scale’/LeSS/SAFe frameworks, which effectively are not agile and don’t really change anything as they do not empower people
Functional teams

(e.g., design, engineering, business)

Design examples include Apple and Nike, technology examples include Amazon and Google

Best for large established companies in stable industries.

  • Strong role mastery as people work in teams of the same role and can learn from each other
  • Strong cohesion across products
  • Increased brand loyalty
  • Products take longer to build as requirements are often too high, or critical information is missing, requiring re-work.  This can be mitigated with good ‘kick-offs.’
  • Difficult to link customer value to teams
  • The consistency of products and across the company is more difficult, requiring more meetings or a team to focus on ‘the whole customer.’
  • Easy to build up political fiefdoms, which will need to be combated by CEO
Geographic teams

(e.g., EU, North America, Asia)

Examples include: Didi

Best for large companies with a global footprint, which required high degrees of localisation

  • Great localisation, which can give you the edge against global rivals
  • Team size easier to manage
  • A potentially high variance between the same product in different countries which may cause customer confusion
  • Easy to build up political fiefdoms, which will need to be combated by CEO
  • Strong country teams can result in differing internal cultures emerging


I hoped this analysis helps.  In reality, you may need to adopt a hybrid approach, and also change your approach over time.

In my next post, I will focus on the process of software delivery.