Boeing – Aligning Product Teams Around a Shared Future Vision

Aligning Teams Around One Future

Designing research-led workshops that turned stalled product questions into roadmaps, named owners and Monday-ready next steps.

Over three years at Boeing Digital Services, I designed and led roughly 25 service-design workshops, every one requested by a team rather than assigned from above. Teams often arrived with a solution already forming but only a few vague bullets describing the problem, no shared evidence and no agreement on what had to happen first.

I led the full arc: research, synthesis, workshop architecture, facilitation and the transition into roadmap planning. Each engagement ended with a defined direction, named owners, exposed dependencies and next steps the team could begin the following Monday.

Product, engineering and business leaders owned the commitments, resourcing and delivery that followed. My responsibility was to create the evidence and decision structure required for those commitments to be made.

Workshops at a Glance

Requested, Not Assigned

Approximately 25 workshops over three years, initiated by teams seeking help with stalled product or organizational decisions.

Research Before Facilitation

Each engagement began with interviews, existing evidence and current-state synthesis—not a blank ideation wall.

Decisions Before Ideas

Activities were selected to resolve a specific decision, expose tradeoffs and sequence the work that had to come first.

Owners Before Exit

Every session ended with a roadmap, named owners, dependencies and next steps teams could begin immediately.

Building Before the Problem Was Framed

Many teams arrived after solution work had already begun. The problem statement was often a handful of broad bullets, while different leaders held competing assumptions about the customer, the underlying capability gap and which work should come first.

My job was not to run an ideation session. It was to identify the decision blocking progress, build an evidence base around it and design a workshop that forced the right tradeoffs.

The maps were not the point; the conversations they forced were.

One roadmap assumed roughly ten architects’ worth of work while the organization had one data architect available.
Exposing that dependency changed the sequence.

Research Before the Workshop

I began each engagement before the workshop room. I interviewed the people doing and managing the work, reviewed existing research, product plans and technical constraints, then mapped the current workflow, stakeholder dependencies and unresolved assumptions.

This pre-work changed the quality of the session. Participants were not starting from opinions or a blank wall; they were reacting to evidence that could confirm, challenge or narrow what the team believed.

When the research contradicted the preferred solution, I made that conflict visible and used it to reframe the decision.

Turning Evidence Into Workshop Decisions

I converted the research into working artifacts participants could correct and build from: current-state journeys, stakeholder and dependency maps, opportunity areas, future-state criteria and prioritization exercises. They were incomplete enough to invite correction but structured enough to keep the room focused.

During the workshop, I used those artifacts to move from many perspectives toward one sequence of decisions: what problem to solve, which capabilities were foundational, what could be deferred and what evidence was still missing.

In one engagement, the team entered wanting a single-pane-of-glass experience. The evidence showed that the shared data foundation did not yet exist. We reduced roughly 15 ideas to the three capabilities that had to come first.

Roadmap, Owners and Dependencies

The workshop did not end at a future-state vision. I translated the agreed direction into a sequenced roadmap with named owners, cross-team dependencies, unresolved questions and immediate follow-up work.

This was where enthusiasm met capacity. The roadmap exposed whether the organization had the people, data and technical foundations required to deliver the direction.

In one case, the plan depended on roughly ten architects’ worth of work while only one data architect was available. Making that mismatch visible changed the sequencing and prevented the team from treating an aspirational roadmap as an executable plan.

Roadmap and ownership artifacts used to separate committed work, delivery dependencies, deferred ideas and assumptions requiring further evidence.

One Workshop in Practice: APM

One engagement focused on APM (Aviation Process Mapping), where teams needed more than a product concept. The final output connected the proposed experience direction to the organizational change required to support it: future workflows, capability expectations, instructional content and materials teams could use to communicate the direction.

The interface work shown below is a representative concept set created to make the workshop direction concrete. It illustrates the experience principles and workflow logic discussed during the engagement; it should not be read as a fully implemented production product.

Portfolio reconstruction of representative APM concepts and change materials. Conceptual direction; not a production release.

What Changed Across the Engagements

These engagements made service design useful at the moment teams had to commit—not only when they needed research or interface work. After the early workshops produced clear ownership and next steps, teams began requesting the method through word of mouth, reaching approximately 25 engagements over three years and more than two per month at peak.

Across my Boeing work, I supported more than 20 product-team and internal roadmaps that were stalled, churning or struggling to move forward. Implementation remained with the teams responsible for funding, staffing and delivery.

My contribution was establishing a defensible direction: which work was foundational, what could wait, who owned each next step and what still required evidence.

Decision outcome

Preferred solutions changed when the research or delivery foundations did not support them.

Delivery outcome

Sessions ended with sequenced roadmaps, named owners and actions teams could begin immediately.

Organizational outcome

Teams repeatedly requested the process, making service design a trusted mechanism for resolving product and leadership decisions.

Facilitation becomes strategic when the room is designed to make a decision, not merely produce ideas.

Common Questions

What did you own versus the participating teams?

I owned the research plan, synthesis, workshop architecture, facilitation and the artifacts used in the final readout. Product, engineering and business leaders owned the commitments, resourcing and execution that followed.

How was this different from a typical design workshop?

Typical workshops generate ideas. Mine were built to move one stalled decision, with the evidence prepared before the session so the room could converge on a committed direction instead of a wishlist.

How did you avoid confirming the team’s preferred solution?

I brought in evidence that could contradict it. In the single-pane-of-glass engagement, the desired interface was ahead of the data foundation, so the team reduced roughly 15 ideas to the three capabilities that had to come first.

How many of the roadmaps were executed?

I do not have a clean execution count across every engagement. I supported more than 20 roadmaps that were stalled, churning or struggling to move forward; implementation depended on the funding, staffing and ownership that followed.

Why did teams keep requesting the workshops?

Because the output was usable. Teams left with decisions, owners, dependencies and next steps they could act on immediately, rather than another set of workshop notes.