When should an enduring product team be split into two teams?

A product team is growing, its planning meetings are crowded and changes wait on a few specialists. Leaders consider dividing it. A premature split can turn one overloaded team into two teams blocked by each other.

Look for a persistent team constraint

A split is a change in accountability, not simply a reduction in meeting size. Check whether delays come from unrelated user journeys, too many systems to understand, competing priorities or an actual shortage of capacity. Look at recent features and incidents: which work needed everyone, and which work formed a stable, separable stream? The GOV.UK guidance on changing team size identifies communication overhead and different skill needs as reasons to consider smaller teams. That guidance describes government service delivery; the diagnostic use here is a recommendation for product organisations.

Compare changes short of a split

Before splitting, reduce work in progress, remove avoidable approvals, improve a shared tool or assign a specialist support route. A single multidisciplinary team may be the least costly option when work and operational responsibility remain tightly coupled. Team Topologies treats a team’s cognitive load and supporting team types as design concerns; it is an organisational model, not a guarantee that any particular split will improve throughput. Test whether a proposed platform or enabling service would remove the recurring burden without creating another queue.

Give each new team coherent ownership

If a split is justified, Product and Engineering jointly map users, outcome, service boundary, data and dependencies. Give each team a decision owner, engineering ownership, access to user evidence and responsibility for operating what it changes. GOV.UK guidance on multiple teams suggests dividing work by theme, product or feature to minimise dependencies. A feature-based split can be temporary if both teams must repeatedly alter the same systems. Prefer a boundary that allows each team to make useful changes and learn from the result.

Plan and review the transition

Agree interfaces, incident ownership, escalation and how cross-team priorities will be decided. Transfer knowledge deliberately; do not leave one team dependent on an undocumented expert in the other. Review a few changes after the transition: how often did work cross boundaries, how long did decisions wait, and could each team maintain its service? If the new arrangement increases coordination cost, revise the boundary. Team composition may change as the product evolves; it need not be frozen into a permanent structure.

Example

Hypothetically, a subscription platform team owns customer onboarding and billing operations. Recent work shows separate user goals but a shared identity dependency. Leaders first remove a manual approval queue. They then give each of two multidisciplinary teams a defined outcome and service responsibility, while agreeing an identity interface and an incident escalation route. After several releases, they review whether work still waits at the new boundary.

FAQs

• Does a large team always need to split?

  No. Size alone does not reveal whether the work can be divided coherently or whether another constraint is causing delay.

• Can teams share specialists?

  Yes, if availability, priorities and decision routes are explicit; chronic waiting may mean the arrangement needs to change.

• Who decides the split?

  Product and Engineering leaders should decide with the affected team and service owners, using evidence about outcomes, capacity and dependencies.