Skip to content

Aligning structure to strategy

Design customer-facing ownership boundaries and the support around them so small teams can act without recurring cross-team waits.

Who it is for

Product Teams

Product and functional leaders designing or expanding Stream Teams.

Practitioners who understand the customer journey, technical dependencies, and specialist capabilities.

Duration
1 day

Inside the module

What the module covers

The aim is a structure in which most customer-facing changes can be made by one team without waiting on another.

This module takes leaders through the structural decisions behind Stream Teams: small teams of two to four people, built around a Designer and a Developer, that each own a customer-facing value stream from idea to satisfied customer. The cohort maps one of its own customer journeys, finds the natural seams in the domain, and proposes team boundaries, success metrics, funding, and composition.

By the end, participants have practiced how to

  • Compare splitting teams by function, feature, journey stage, and technical entity, and explain the communication and code costs of each
  • Facilitate an Event Storming session that maps domain events, commands, policies, and hot spots along a customer journey
  • Draw bounded value streams from an event model, accepting some duplicated entities to keep teams independent
  • Define outcome metrics for each value stream and state the assumed link to business impact metrics
  • Allocate value streams, funding, and roles to Stream Teams and record the result in a Stream Team charter
  • List each team's remaining dependencies and decide when to revisit metrics, funding, allocation, or boundaries

Module outline

How the time is spent

Each part ends with a short exercise, on your own work where you have it and on a prepared case where you do not. We adapt the examples and emphasis to the people in the room.

  1. Options for splitting a product

    Why coordination cannot fix a dependency problem, and the trade-offs in each common way of dividing work between teams.

    Put it into practice

    Sketch how your teams are split today and mark the customer-facing changes that most often need more than one team.

    Topics covered

    • Functional versus cross-functional teams
    • Splits by function, feature, journey stage, and technical entity
    • Conway's Law and the reverse Conway maneuver
    • Team size and the growth of communication paths
    • Customer journey map as the starting point, including acquisition
    Every possible dependency drawn between 3, 5, and 10 projects: 3 connections, 10 connections, and 45 connections. The web of 10 projects is dense with lines.

  2. Event Storming the customer journey

    A hands-on group modeling workshop that surfaces how the domain really behaves before anyone draws a boundary.

    Put it into practice

    Run a short Event Storming exercise on one bounded step of a real customer journey, enough to learn the method and produce a partial event model. A full Event Storming session for the whole journey takes half a day to two days and is planned separately.

    Topics covered

    • Domain events, commands, policies, and aggregates on colored sticky notes
    • Hot spots for contested or unclear areas
    • Domain experts and facilitation in the room
    • Ubiquitous language shared by domain experts and developers
    • Understanding the domain before proposing solutions

  3. Boundaries, metrics, and funding

    Turning the event model into independent value streams, each with a measure of success and a share of the budget.

    Put it into practice

    Draw candidate value stream boundaries on the partial event model, name an outcome metric for each stream, and rank the streams by strategic importance.

    Topics covered

    • Bounded value streams drawn from the event model
    • Duplicated logical entities in place of shared dependencies
    • Effort, output, outcome, and impact metrics
    • Value stream success metrics linked to business goals
    • Value stream funding by strategic importance and complexity

  4. Composing and reviewing Stream Teams

    Matching people and authority to each scope, checking what still blocks the team, and keeping the arrangement under review.

    Put it into practice

    Draft a charter outline for one pilot Stream Team, list the dependencies you already know that team would still have, and agree who will work on removing each one.

    Topics covered

    • Designer and Developer core roles plus specialists by value stream
    • One high-priority stream or several lower-priority streams per team
    • Stream Team scope and Stream Team charter
    • Autonomy audit of each team's remaining dependencies
    • Reviews of metrics, scope and funding, allocation, and boundaries

Practical results

What the cohort leaves with

  • A partial event model for one step of a real customer journey, with hot spots marked, and a plan for the full Event Storming session
  • A bounded value streams map with candidate Stream Teams assigned to each stream
  • Success metrics for each value stream, with the assumed link to a business metric
  • A draft Stream Team charter for a first team: value streams, success metrics, composition, funding, working agreements
  • A dependency list for that team, to be worked through by leaders and supporting teams

Before the module

Bring the customer journey map, an outline of current teams and systems, and the product strategy and budget constraints.

The company learning plan

Where this module fits

Part of the Product Teams courses, taken at the Lead the product teams stage of the implementation.

See all company courses →

Product Teams

Explore the supporting documentation