Splitting Product Teams
Splitting Product Teams involves dividing a larger product team into smaller, more focused groups that are responsible for specific sections or aspects of the product. This can include dividing by product features, customer journeys, geographic regions, or other criteria that align with the product's structure and goals.
Goal
The goal of splitting product teams is to avoid overburdening a team, which will lead to slower development and lower quality. The aim is to enhance scalability, focus, and efficiency by creating smaller, autonomous teams that can independently develop, manage, and scale different parts of the product.
Context
If your product is successful there will be increasing demands for both supporting the existing product as well as growing the product to meet the needs of the market. You can increase the number of stream teams by assigning them more granular value streams but there is a limit to the number of stream teams that a product team can effectively manage. Splitting product teams can help to alleviate this pressure by creating new product teams that can focus on specific areas of the product.
Splitting Options
There are two structural choices to make when splitting: how the work is divided (the dimension of the split) and whether the resulting Product Teams operate as peers or as a nested hierarchy.
Splitting Dimensions
| Option | Description |
|---|---|
| Geographic Split | Dividing teams based on geographic regions or markets, allowing for localised product development and support. |
| Platform-Based Split | Splitting teams based on product features or modules, enabling specialisation and focus on specific functionalities. |
| Customer Split | Organising teams around different customers or user segments, tailoring products to specific needs and preferences. |
| Market Segment Split | Dividing teams based on market segments or industries, optimising product offerings for different target audiences. |
Peer vs Nested Splits
| Pattern | Description | Best Suited For |
|---|---|---|
| Peer Split | The original Product Team is replaced by two or more independent Product Teams operating side by side. Each owns its own strategy and reports to the Ecosystem Team. | When the parts of the product are essentially separate products serving different customers. |
| Nested Split | A single top-level Product Team is retained for overall product strategy and the Ecosystem Team relationship. Sub-product Product Teams are introduced beneath it for parts of the product that have grown large enough to need their own focus. | When the parts of the product are tightly related (a customer flows naturally between them) but each part has enough Stream Teams underneath it to overload a single Product Manager. |
Nested Product Teams in more detail
In a nested split the top-level Product Team retains the strategic spine; the sub-product teams own the strategy within their domain. Each sub-product Product Team is typically smaller (3–4 people) than a standalone Product Team because it does not carry the full ecosystem-facing responsibility, which remains with the top-level team.
For example, an airline might end up with:
- Flights (top-level Product Team) — owns the overall flights product vision, strategy and the cross-cutting customer experience.
- Booking (sub-product Product Team) — owns the search-to-confirmation experience and its Stream Teams.
- Post-Booking (sub-product Product Team) — owns the manage-trip experience and its Stream Teams.
- Day of Travel (sub-product Product Team) — owns the airport-and-disruption experience and its Stream Teams.
Inputs
| Artifact | Description |
|---|---|
| Product Strategy | The high-level strategic goals and objectives of the product, including where to play and how to win. |
| Ecosystem Strategy | A high-level plan for achieving the ecosystem vision within the next 1-3 years. |
Outputs
| Artifact | Description | Benefits |
|---|---|---|
| Product Budget | The financial resources allocated to the new products, including budget constraints and funding availability. | Ensures the new teams have the necessary resources for development and growth. |
Anti-patterns
- Split not aligned with strategy: Dividing teams without considering the product or ecosystem strategy, leading to misalignment and inefficiencies.
- Overlapping responsibilities: Splitting teams in a way that creates overlapping or unclear responsibilities, causing confusion and duplication of effort.