The Problem

A world-class engine company with a fractured customer experience

GE Aerospace’s engines power roughly half of commercial aviation. The airlines operating those engines — Delta, Southwest, FedEx, American, and dozens of regional carriers — have engineering teams responsible for keeping those planes in the air, on schedule, and within contract. That means constantly tracking engine health, managing repair visits that can take months, negotiating work scopes, and troubleshooting issues in real time.

The digital tools supposed to support all of that work had a fundamental structural problem: they were built by teams that didn’t talk to each other, organized around internal org boundaries rather than customer needs, inside an organization that had largely convinced itself it wasn’t really a software company.

The customer portal team, the FMX flight analytics team, and the SmartShop repair operations team each had their own engineering org, their own design team, their own PM structure, and their own executive stakeholders. Customers were expected to navigate between all of them and figure it out on their own.

A powerplant engineer at a mid-size carrier might track a shop visit in one tool, pull diagnostic case data from a completely separate system, approve a work scope change by email, and search their inbox for a PDF contract. None of these systems were connected. The experience wasn’t designed — it was inherited. And it was a direct reflection of how GEA was organized internally.

This is Conway’s Law in its most visible form: the shape of the customer experience mirrors the shape of the internal organization. Nobody inside had a role specifically tasked with looking at the whole picture. That was the actual job.

The Approach

Going wide before going deep

Before making a credible argument for what needed to change, I needed to understand the full scope of the customer relationship — not just what happened inside GEA’s tools, but what customers were actually responsible for, who on their team was doing it, and where GEA’s digital ecosystem fit into their daily operations.

I started with stakeholder interviews across GEA’s internal teams, specifically to understand how disconnected the product organizations really were. What I found confirmed the hypothesis: no shared understanding of the customer journey, no common definition of who the “user” was, and no cross-team forum for connecting the dots. Each product pod optimized for its own feature set.

Then I went to the customers. We spoke with engineering teams at five major carriers covering the full spectrum — from large airlines with dedicated specialists for every function to smaller operators where one or two engineers manage an entire fleet. Any recommendation that didn’t scale across both ends of that spectrum didn’t make the cut.

What came out of that research wasn’t a feature request list. It was a clear picture of four distinct journeys that GEA’s tools were failing to support:

The research fed into a detailed service blueprint covering the full MRO lifecycle — engine removal through return to service — mapping customer touchpoints, GEA associate actions, and underlying systems at every stage. That blueprint became the first artifact that let stakeholders from different teams see the full customer journey in one place, including all the places where internal handoffs created gaps customers had to bridge themselves.

The Key Decision

Convincing an industrial company that it was also a software company

The hardest part of this work wasn’t the research or the deliverables. It was the organizational resistance. GE Aerospace had spent decades building world-class engines for world-class airlines. That legacy created a kind of institutional confidence — bordering on complacency — about the customer relationship. The assumption in a lot of rooms was that customers were fortunate to work with GEA, not the other way around.

Making the case for a unified customer experience also meant implicitly making the case that the current organizational structure was producing a broken one. That’s a hard argument to win in a room full of people who built that structure.

I couldn’t win it with better slides alone. It required building relationships across org boundaries, finding allies who could advocate for the customer-centered view when I wasn’t in the room, and framing the problem in language that landed for each stakeholder group — competitive risk for executives, workflow clarity for product teams, data credibility for engineers.

The insight that landed hardest: no customer cares how your internal org is structured. They care whether the experience works. When the org chart becomes the customer experience, the customer loses.

The service blueprint was the critical tool for making this concrete. For many stakeholders, it was the first time they’d seen their piece of the product in the context of everything around it, including the gaps the customer was expected to fill themselves.

The Solution

Four journeys. One coherent customer experience.

The primary deliverables were four future-state customer journey maps — one for each critical scenario identified in research — paired with the full MRO service blueprint. These weren’t aspirational wireframes. They were grounded in real research, validated against what customers said they needed, and designed to give product teams a concrete north star they could build toward incrementally.

Each journey mapped the experience from the customer’s perspective — what they were trying to accomplish, what GEA currently made them do to accomplish it, and what a connected, transparent, proactive experience could look like instead. The pain points at the bottom of each map came directly from the research, not editorial judgment.

One of the more pointed findings was the integration gap between the customer portal and GEA’s separate FMX flight analytics platform. Engineers used both interchangeably, but the two tools were built by entirely different organizations and shared no data. Diagnostic information lived in FMX. Work scope approvals lived in the portal. Inspection data from the shop floor wasn’t accessible to customers at all. We prototyped what it could look like to bring those data streams into a single connected case view.

Each severity state surfaces different information and actions — all within a single view, without switching tools. The service bulletins panel (bottom right) shows how the concept pulled relevant technical documents into context automatically, rather than requiring engineers to search for them separately.

A note on timing: My design team was laid off at the end of 2023 before this vision was fully realized — part of a broader organizational shift that, honestly, reflected the same cultural friction this work was trying to address. The team that inherited it built directly from it. That’s the most honest measure of whether the vision was right.