How to scale (2 of 5) – Product team structure
Posted by Max on November 16, 2018 in Blog, leadership |
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.
Like this:
Like Loading...
Related
Pingback: How to scale (3 of 5) - Agile (process) - getting better every day
Pingback: How to scale (4 of 5) - architecture - getting better every day
Pingback: How to scale (5 of 5) - culture - getting better every day