Skip to content

Change 6 of 6

Scaling

Grow without adding approval layers.

Build shared capability and self-service products that help more teams act independently.

The change

Add capability without adding a queue.

Adding teams can recreate the delays that the first pilot removed. Shared experts become queues, coordination roles multiply, and teams need agreement from an increasing number of people before they can move.

Scale the capabilities that allow teams to stay independent. Enabling Teams help people develop skills and apply standards. Internal Product Teams turn recurring shared needs into usable products. An Ecosystem Team aligns strategy and investment across products.

AI can increase how much each team produces, which makes shared specialist queues and gaps in judgment harder to absorb. Coaching, usable standards, and self-service help that capability grow with demand.

What changes in practice

  1. Build skills where gaps recur.

    Use Enabling Teams to develop capability across teams. Combine coaching on real work with reusable playbooks, clear capability standards, and apprenticeships. Judge progress by whether teams can handle the work independently.

  2. Productize proven shared needs.

    Give reusable capabilities a clear owner and users. An internal product should earn adoption by solving a real need. Track reliability, ease of use, and whether it removes waiting. Mandatory use can hide a service that is still a bottleneck.

  3. Inspect the new dependencies.

    When a team is added, look at what it will need from the rest of the organization. Avoid growing an approval or coordination layer around it by default.

A team of teams

Five responsibilities. One connected organization.

Stream Teams build the products that customers want. Product Teams provide these Stream Teams with direction, Enabling Teams build their capability, and Internal Product Teams run shared services. An Ecosystem Team ensures that the teams within the unit are aligned.

The Ecosystem Team aligns Product Teams, Enabling Teams and Internal Product Teams, shown as peers on the same level. Stream Teams sit beneath Product Teams and own customer outcomes. Enabling Teams coach across streams; Internal Product Teams provide shared services.

Stream Team

A small, persistent team researches, designs, builds and improves one customer value stream. Its responsibility continues after release: did the change help customers, and what should happen next?

Responsibilities and example
Who is involved
Usually two to four people, with Designer and Developer as the core roles and additional expertise where the value stream needs it. The whole team works together across research, design, development and improvement.
Decides
Chooses and tests solutions within agreed strategy, outcome and risk boundaries. It is autonomous within the boundaries set by the Product Team.
Connects
Its Product Team supplies direction and operating conditions. Enabling Teams strengthen its capabilities; Internal Product Teams provide shared services.
For example
An onboarding Stream Team follows the journey from sign-up to successful first use, rather than stopping when the registration screen is shipped.
Stream Team implementation guide ↗

Product Team

The leadership team for a product sets vision, strategy, investment priorities and team boundaries. It develops people and removes organizational constraints so Stream Teams can pursue outcomes.

Responsibilities and example
Who is involved
A Product Manager works with functional leads such as Design, Development and Marketing. The goal is product leadership rather than delivery.
Decides
Sets direction and agrees outcome boundaries; leaves solution choices and day-to-day work to Stream Teams. It remains engaged through evidence and ongoing alignment.
Connects
Aligns its Stream Teams and works with peer Enabling and Internal Product Teams. A parent Product Team or Ecosystem Team provides the wider strategic and investment context.
For example
A Product Team prioritizes improving first-time customer success. Stream Teams investigate the obstacles and decide which solutions to test.
Product Team implementation guide ↗

Enabling Team

Senior practitioners help teams become stronger in a discipline such as research, quality or engineering. They coach in the work and develop reusable practices, playbooks and communities.

Responsibilities and example
Who is involved
Usually one or two experienced practitioners. They coach the Stream Teams on real work so teams can become independent afterwards. They do not take over delivery or become a recurring specialist queue.
Decides
Facilitates rather than taking over delivery. It is not a central research or testing department that every feature must pass through.
Connects
Works across Stream Teams and with functional leaders. It is a peer of Product and Internal Product Teams.
For example
A research specialist coaches an onboarding team through interviews and synthesis so the team can continue learning directly from customers.
Enabling Team implementation guide ↗

Internal Product Team

Runs a platform or internal service as a product, with internal customers, a roadmap and feedback. It makes common needs self-service so teams do not negotiate the same request repeatedly.

Responsibilities and example
Who is involved
It is identical to a product team with Product management and the expertise needed to operate the service.
Decides
Provides services to internal customers, including Stream Teams. Support can range from documented processes to automated self-service, with an explicit route for exceptions.
Connects
Serves teams across products as a peer of Product and Enabling Teams. Review investment against usefulness, adoption, reliability and necessary obligations. Low adoption is a reason to investigate and improve the service, not an automatic funding cut.
For example
A platform offers a supported deployment path that teams can use themselves. A legal service supplies approved terms for common cases and a clear route for exceptions.
Internal Product Team implementation guide ↗

Ecosystem Team

Sets strategy, portfolio structure and investment across the products and supporting teams of a business unit. A larger organization can contain several such ecosystems, each with its own scope.

Responsibilities and example
Who is involved
Business-unit and functional leaders responsible for a portfolio, rather than the daily work of delivery teams. In smaller organizations this could be the executive team.
Decides
Sets direction and investment choices within its business-unit scope. Product Teams own product strategy, and Stream Teams retain local solution decisions within that context.
Connects
Aligns Product, Enabling and Internal Product Teams as peers. Evidence and constraints from those teams inform the wider strategy.
For example
When priorities shift between products, the Ecosystem Team rebalances investment and shared capability rather than reprioritizing each Stream Team’s backlog.
Ecosystem Team implementation guide ↗
How the model fits larger organizations

As a product scales, there might be too much work for a single Product Team. In such circumstances you can split a product into multiple sub-products each with their own Product and Stream Teams. For example, a marketplace product could have separate Buyer and Seller sub-products.

In smaller organizations, the Ecosystem Team may be the executive team. But in larger organizations you could have separate Ecosystem Teams per business unit.

Regardless of the level, the responsibilities stay consistent. Each level sets direction and conditions for the scope below it without taking over that team’s decisions. Evidence from those teams informs the direction above.

Add a level when the scope needs distinct leadership, not as another approval layer.

Marketplace business unit

Ecosystem Team

  • Marketplace product

    Product Team

Practical examples

Keep specialists connected to their craft.

The Search, Booking, and Stay Management Teams may each have one designer. Working closely with developers builds shared context, but a designer can lose access to peers who challenge their work and help them grow. A Design Enabling Team makes sure that support remains available across team boundaries.

  • Training. Build skills through workshops and apprenticeships.
  • Coaching. Pair on real work and help people apply their craft.
  • Knowledge sharing. Run communities of practice for peer feedback and shared learning.
  • Guidelines. Maintain practical standards and playbooks. May even own the Design System until it matures into a self-contained product.

Specialists stay in their Stream Teams. Enabling Teams build their capability, with hands-on support reducing as people become confident.

A designer remains inside each of the Search, Booking, and Stay Management Teams. Dotted connections link the designers to a Design Enabling Team, which supports their craft across team boundaries.

Turn repeated work into a shared product.

Search, Booking, and Stay Management keep implementing the same authentication and session-management features. Each team spends time maintaining them, and fixes have to be repeated. That recurring need gives an Internal Product Team a concrete starting point for a shared platform.

The Internal Product Team provides authentication through documented, self-service interfaces and owns its reliability, security, and ongoing improvement. Stream Teams use the platform while keeping ownership of their customer experiences and releases.

Search, Booking, and Stay Management each maintain authentication. The repeated capability becomes one shared authentication product owned by an Internal Product Team. All three Stream Teams use it through self-service interfaces.

Align products around the same business direction.

The booking business grows to offer stays, flights, and expense management, each with its own Product Team. Stays is pursuing European business travelers while Flights invests in US leisure travel. Both may grow, but their investments do little to strengthen the same customer offer.

The Ecosystem Team makes the company priority explicit: business travel in Europe. It aligns investment across the products, and each Product Team sets its strategy and Stream Team objectives within that direction. Teams bring back evidence about demand and results so the Ecosystem Team can reconsider the market focus or allocation over time.

An Ecosystem Team aligns the Stays, Flights, and Expenses Product Teams around business travel in Europe. Each Product Team keeps its own scope within the shared company direction.

Scaling in practice

Real case studies from UXDX conferences and other sources.

Haier Group logo

How Haier continuously evolved their organisational structure to manage empowered teams more effectively.

Kiwi.com logo

How Kiwi.com enhanced its product discovery process by establishing a comprehensive research operations (research ops) infrastructure.

Browse 7 scaling case studies ↗

Common objections

This dilutes our specialists across teams
It helps you make better use of them. Enabling Teams are small, senior teams whose job is to raise everyone else's skills, so your strongest specialists work across many teams instead of being spread one per squad. They own the standards and the knowledge base, which lifts the baseline for everyone. A principal engineer who helps forty people improve will usually have a bigger impact than one embedded in a single team.
There is no promotion path for specialists in product teams
There is, and it runs alongside the management path. ZeroBlockers has two career tracks. Capability standards describe what each level looks like for each craft, so people can be promoted for the depth of their expertise without having to take on direct reports. The Staff and Principal roles sit on Enabling Teams, where senior specialists can focus on their craft and help raise the standard across the organization.
Enabling Teams are overhead. They do not deliver anything
They deliver through other teams, so their value shows up in how those teams perform. One or two people setting capability standards, spending time with teams each week and writing playbooks can raise the level of ten or more Stream Teams. The alternative is to embed the same seniority in every team, where each person lifts one team and the same questions get answered ten times over. To keep the cost in check, Enabling Teams facilitate and don't take on delivery work, so they don't turn into another queue. Their knowledge base is written for self-service too, so they don't become a help desk. If you notice an Enabling Team doing delivery work, it usually means the change has stalled.
Should we build a platform before starting the pilot?
It's usually better to wait. If you build a broad platform before teams have run into their real constraints, there's a risk of creating capabilities that don't remove the blockers they face. Start the pilot, see which needs keep coming up, and let the evidence from those first teams guide what becomes shared.
All common objections ↗