What is the best way to split a cross-functional product development team? Here are six approaches with their respective pros and cons.
1. Feature Teams
A cross-functional team with the end-to-end ownership of a feature. For example, an e-commerce checkout process or product recos.
The members of the feature team work directly on all code bases required to further develop the feature, even if they are not responsible for that part of the software system themselves.
Feature teams in an e-commerce platform product.
The pros and cons of feature teams are:
➕ Clear internal responsibilities regarding who owns which feature.
➕ Low overall lead time of changes for individual features, as there are few dependencies on other teams.
➖ Difficult to assign business metrics to a product, only proxy product metrics.
➖ Prone to project-oriented roadmaps that focus on feature building rather than solving user problems (Marty Cagan).
2. Product Teams
The team has the end-to-end ownership over all related features that add up to a product. For example, it could be a cloud email product, which in turn consists of different features.
The split into product teams offers the opportunity to measure teams on the value of the product for the customer - not just on the completion of a project.
Product teams own a set of features that add up to a product.
The pros and cons of product teams:
➕ Allows teams to develop a clear product vision and strategy.
➕ The team operates in a clearly understandable business context (market, competition).
➕ Assignment of outcome-oriented product metrics such as active users or retention rate.
➖ High cognitive load due to context switching and collaboration within the broad technical domain.
➖ Multiple codebases need to be touched to release to production (Team Topologies).
3. Customer Lifecycle Teams
Teams are based on the customer’s lifecycle. The individual phases depend on the company, but a good starting point for a lifecycle is for example: Acquisition → Engagement → Monetization → Retention.
As a result, a cross-functional team receives the ownership of the acquisition lifecycle phase, for example.
A customer acquisition (lifecycle) team in a music streaming product.
The pros and cons of aligning the team split with the customer lifecycle:
➕ Identity-shaping team purpose (you know which customer problems you solve with software artifacts).
➕ Good assignability of customer-oriented business metrics such as customer acquisition cost or churn rate.
➖ Learning curve within the organization, which team is the right contact in case of problems or suggestions for improvement.
➖ Lifecycle stages may overlap, which makes it difficult to differentiate between teams.
➖ Multiple codebases need to be touched to release to production.
4. Persona Teams
The team split is based on personas and their specific needs. This approach can be helpful for example in a marketplace environment, when consumers want to browse products, while retailers are provided with tools for advertising and billing.
Other possible persona teams are for example prospects or system administrators.
A seller persona team in a marketplace product.
The pros and cons of persona teams:
➕ Identity-forming team purpose (you know who you are building software for).
➕ Clearly defined business context.
➖ The disadvantages tend to be similar to those of customer lifecycle and persona teams.
5. Client Teams
A cross-functional product development team has the ownership of a user-facing client. For example: in the video or music streaming environment, companies offer clients for numerous platforms: iOS, Android, Web, Android TV, gaming consoles, set-top boxes, smart speakers, wearables and more.
Client teams in a video streaming product.
The pros and cons:
➕ Clearly assignable ownership of client-side parts of the software stack.
➕ Tends to have a lower cognitive load for team members because of the technical domain boundaries.
➕ Teams develop deep expertise for their client platform.
➖ Cross-client initiatives require a high degree of collaboration.
➖ Clients with a low number of numbers may need to rely on shared resources (UX/UI, QA), which can lead to bottlenecks and waiting times.
6. Technology Teams
By dividing teams by technology stack, they gain ownership of areas such as frontend, backend, middleware or DB. But when it comes to developing the best possible product for the user, this approach usually proves to be ineffective.
However, in very early stages of a company or in small organizations with few parallel initiatives, this structure can be a good choice.
Each technology team owns a defined domain in the software system.
The pros and cons of technology teams:
➕ Clearly assignable ownership of software stack components.
➕ High level of competence within the specific team tech stack.
➖ Teams run the risk of taking on the role of a workbench and only processing anonymous pull requests without customer reference.
➖ Cross-product initiatives require changes to different code bases. The flow of work is often interrupted and waiting times occur.
➖ Risk of suboptimal software architecture due to functional silos without direct collaboration (Conway’s Law).
So Which Team Split Is the Best?
As always: it depends. On the company culture, technical maturity and the size of the organization. According to Matthew Skelton in Team Topologies, the decision should aim to make teams more autonomous and reduce their cognitive load in order to continuously deliver valuable software.
References
- Matthew Skelton & Manuel Pais (Team Topologies)
- Eric Evans (Domain-Driven Design)
- Marty Cagan (Product Operating Model)