Boeing – Aligning Leadership Strategy and Vision

Aligning Leadership Strategy and Vision

As Boeing Digital Services’ lead and only service designer, I synthesized research across sales, product, implementation, training, and support into a future-state service blueprint spanning roughly eight portfolios. Leadership used it for about 18 months to guide planning, and the split-Salesforce dependency it surfaced became a funded consolidation effort.

Scope and Impact

MAPPED THE FULL SERVICE

Connected five lifecycle stages, roughly eight portfolios, and about a dozen frontstage and backstage lanes in one Figma blueprint.

GROUNDED THE MODEL IN EVIDENCE

Synthesized approximately 15–20 interviews, then refined the model through seven cross-functional working sessions.

USED IN LEADERSHIP PLANNING

Revisited in twice-yearly leadership reviews for about 18 months to track priorities, progress, and unresolved dependencies.

SEEDED A FUNDED FOLLOW-ON

The split-Salesforce dependency became a funded consolidation effort I helped scope with the internal team and Salesforce.

The Problem Lived Between Teams

Boeing’s digital services spanned roughly eight portfolios and a chain of teams from sales and marketing through implementation, training, and support. Each group understood its own responsibilities, but leadership lacked an end-to-end view of how customer context, ownership, systems, and data moved between them.

The friction lived between teams, not inside one interface. I chose a service blueprint to connect the customer journey with the backstage roles, processes, systems, and dependencies shaping it and to give leaders one operating model they could inspect together.

Customer context was collected by sales, re-collected by implementation, and reached training incomplete—or not at all.

Sales captured customer context to close a deal. Implementation often repeated the same questions because documentation varied and teams worked in separate Salesforce instances; training received even less. The blueprint placed the breakdown in one end-to-end row, making its downstream effects—delays, missed expectations, and rework—visible to leadership.

Building the Future-State Service Model

I synthesized approximately 15–20 interviews across sales, marketing, product, implementation, training, and support into a future-state service blueprint. It connected five lifecycle stages with the customer experience, internal roles, processes, artifacts, data, technology, and measures required behind each stage.

Rather than inventing a centralized model from scratch, I combined the direction each portfolio was already pursuing and refined it through seven cross-functional working sessions. The result gave teams one structure for asking concrete questions: Who owns this handoff? Which system supplies the data? What must be ready before work moves downstream?

Simplified portfolio view of the future-state blueprint; the working version included portfolio-level activities, dependencies, systems, and ownership detail.

What the Blueprint Surfaced

The model shifted three conversations from anecdote to decision: when design entered the lifecycle, how customer data moved between systems, and which interactions should become repeatable.

Design Entered After Direction Was Set

UX research, requirements, and prototyping appeared after key product decisions. Moving those activities into the early lifecycle stages made design an input to product direction rather than a downstream repair function.

Shared Data, Split Salesforce Instances

Sales and implementation depended on the same customer context but accessed it through different instances, permissions, and records. The blueprint reframed a recurring tooling complaint as a consolidation, access, and ownership decision.

From One-Off Handoffs to a Service Pattern

Connecting each customer moment to the roles, artifacts, and systems behind it gave teams a reusable engagement model instead of rebuilding the same handoffs for every product or customer.

How Leadership Put the Blueprint to Work

Leadership used the blueprint to track cross-team dependencies, select a priority, and fund the next step.

Leadership Planning Reference
The head of Boeing Digital Services and his leadership team used it in twice-yearly reviews for about 18 months to track progress, unresolved dependencies, and where cross-team attention was still needed.

Funded Salesforce Follow-On
The split Salesforce instances emerged as the clearest actionable dependency. The issue became a funded follow-on, and I partnered with the internal team and Salesforce to scope the core problems and shape a roadmap for the appropriate instances, tools, access, and permissions.

Limit and Lesson
The blueprint guided prioritization and coordination; it did not reassign organizational ownership. After roughly 18 months and significant restructuring, it was retired rather than maintained as a permanent operating model.

Leading Through Evidence, Not Authority

I had no formal authority across the portfolios, so the model had to earn trust through accuracy. I used interviews and working sessions to reflect each team’s responsibilities faithfully, then facilitated decisions around the dependencies leaders could act on.

One sales leader initially viewed blueprinting as unnecessary. Reflecting his team’s own pain points accurately changed the conversation, expanded my access to sales research, and built credibility that carried into later research and service-design work.

Common Questions

As the only designer, what did you own versus leadership?

I owned the research plan, interviews, synthesis, blueprint architecture, Figma artifact, and facilitation of seven cross-functional working sessions. Leaders decided which findings to fund, sequence, or assign. I made the dependencies and options visible; they chose the organizational response.

How did you get research access across eight portfolios?

By that point, I had enough cross-organizational relationships to reach the right contributors in each portfolio. I conducted approximately 15–20 interviews and used working sessions to close gaps, reconcile conflicting perspectives, and confirm how work moved across functions.

How was the future-state model reviewed and corrected?

I did not treat the first version as a final truth. I synthesized the interviews into an initial model, then used seven working sessions with the people represented to correct sequence, ownership, dependencies, and system assumptions. Leadership review confirmed that it was useful for planning, not that every detail would remain permanent.

What would have made it outlast the reorg?

It would have needed formal ownership, a maintenance cadence, and a defined place in planning governance—not only executive sponsorship. The blueprint remained useful while leaders actively revisited it, but a living operating model needs someone accountable for updating it as teams, systems, and priorities change.

When is a service blueprint the wrong tool?

When the problem is contained within one team, one workflow, or one interface. A blueprint earns its cost when the customer experience depends on coordination across roles, processes, systems, policies, and handoffs.