Journey Management Begins When Ideas Grow Legs
The alignment sprint ends with a set of selected Big Solutions, each with an owner, a test plan, and a set of OKRs. This moment — when ideas have been selected, resourced, and hand
The alignment sprint ends with a set of selected Big Solutions, each with an owner, a test plan, and a set of OKRs. This moment — when ideas have been selected, resourced, and handed to teams for implementation — is commonly treated as the conclusion of the service designer's primary work.
It is actually the beginning of Journey Management.
The Transition From Orchestration to Stewardship
Up to this point, the service designer has been the orchestrator of the process: designing the structure, facilitating the discovery, running the workshops, producing the map. These are high-visibility, directive activities. They require the designer to be the person who moves the work forward.
Journey Management requires a different posture. The solutions are now owned by cross-functional teams with their own expertise, their own priorities, and their own ways of working. The designer's role is not to direct their work. It is to maintain the thread that connects what they are building to the customer experience it is meant to improve.
This is stewardship: holding lightly the shape of the journey while the solutions find their adult forms.
"Journey Management begins the moment ideas grow legs. It is the period in which you agree with the owners of the Big Solutions on how the orchestration will work, and you take responsibility for keeping the red thread intact until ownership naturally shifts elsewhere."
What the Red Thread Is
The "red thread" in journey management refers to the continuous connection between each team's delivery work and the customer experience it is meant to serve. It is the connection between a sprint's output and the experience score it is meant to lift. Between a feature's design decisions and the customer pain it is meant to address. Between a team's quarterly OKRs and the journey stage they are responsible for improving.
This thread is not self-maintaining. In the course of normal development, the urgency of near-term delivery constantly creates pressure to defer or compromise the customer-experience rationale behind decisions. Technical constraints reshape what is built. Scope is cut in ways that systematically remove the elements that would have created emotional impact. A new team member joins and optimizes their area without knowing the customer context behind the choices they are working with.
The steward's job is to notice these drifts and correct them — not by asserting authority over the teams, but by asking the questions that reconnect the delivery work to its original customer-experience purpose.
Distributed Ownership, Central Stewardship
Journey management at scale works because ownership is distributed while stewardship remains central.
The team working on a Big Solution owns that solution's delivery. They decide the technical approach, the sprint structure, the feature prioritization. What they do not own is the strategic coherence of the overall journey — how their work fits with the adjacent Big Solutions, how it connects to the organization's shared experience score OKRs, how it is performing against the customer outcomes it was designed to serve.
The steward maintains that coherence without taking back the ownership that has been deliberately given to the teams. This requires a specific kind of soft authority — the influence that comes from being the person with the most complete picture of the journey, not from occupying a position of organizational power above the teams.
The steward succeeds when the journey sustains itself — when teams internalize the customer-experience logic well enough that they maintain the red thread without being reminded. This maturity is the goal, and when it is reached, the journey management practice no longer depends on any individual steward to function.
Back to Writing