Transforming engine data access

The problem

Aircraft maintainers working with Honeywell engines had a data problem. To diagnose engine health, they had to physically connect a laptop to each aircraft, manually download data one engine at a time, and sit with the connection — in hangars that could be freezing in winter and sweltering in summer — while the download ran. The whole process could take up to an hour per aircraft.

Meanwhile, a competitor had already moved to automated wireless data capture. Maintainers knew it.

Honeywell needed to modernize — and do it in a way that actually fit how maintainers worked.

My role

I led this program as Technical Product Owner, responsible for customer access strategy, cross-functional alignment, and delivery across a team of 9 and a $1.3M budget.

UX design was led by Havana Nguyen. UX research was led by Taylor Kostal-Bergmann. My job was to make sure the team had what they needed — real user access, clear direction, and the organizational support to build something that actually worked in the field.

Getting close to the problem

Before we designed anything, I wanted the team to understand what they were building for. I partnered with our business contact at the Honeywell engines facility, who was instrumental in identifying corporate jet fleet maintainers in the Atlanta area willing to talk with us.

We visited 4 customer sites, bringing a rotating team of 3-4 people per visit — always UX design and research, and engineering or QA when slots allowed. Getting engineers and QA into customer environments wasn't standard practice for this team. It required some coordination but it paid off — when the people building the software have watched a maintainer struggle with a physical connection in a cramped hangar, they make different decisions.

I also arranged for the team to tour Honeywell's engine manufacturing facility. Watching these machines being assembled — understanding how many systems had to work perfectly together, how much was at stake if something went wrong — gave all of us a deeper appreciation for what our users were responsible for. Safe flights depend on people like the maintainers we were designing for.

What we learned in the field

Maintainers' primary concern was fast access to fault codes and exceedance data. The current process forced them to download one engine at a time, monitor the connection constantly to catch interruptions, and sit with the aircraft the entire time. Data corruption could happen silently, meaning they might not know a download had failed until they tried to use the data.

The hangar environment shaped everything. Maintainers moved between aircraft, used smartphones and tablets constantly, and worked across multiple manufacturers' tools — each engine maker had its own diagnostic software. If a fleet had mixed manufacturers, maintainers were juggling multiple systems just to get a complete picture.

What we built

We designed a web and mobile application that replaced the manual download process with automated cloud-based data uploads via Wi-Fi, with a companion Bluetooth mobile app for quick engine health checks in the hangar.

The web interface modernized the engine data viewer — adding visual flight leg separators to the chronology view, incorporating MCID descriptions alongside fault codes, and including altitude data to help distinguish airborne faults from ground-level issues. Each design decision traced back directly to something we'd heard or observed in the field.

The mobile app let maintainers connect to nearby aircraft via Bluetooth, initiate uploads, and check engine status quickly without returning to a laptop.

The hard parts

The biggest technical challenge was the Bluetooth connection. The hardware box was mounted inside the aircraft, which meant the Bluetooth signal needed to broadcast through the aircraft's metal skin. Wi-Fi would have been a more reliable connection, but in a highly regulated industry like aerospace, connecting to an aircraft via Wi-Fi raised legitimate security concerns — the engines hardware team ruled it out for that reason. Wi-Fi was designated for cloud upload only, once data had already been transferred off the aircraft. We spent considerable time working through the Bluetooth reliability problem, and it created real integration challenges when the hardware and software teams — located in different cities — finally brought everything together.

The other challenge was cultural. This team built machines, not software. Agile development — build something, test it, learn, iterate — wasn't intuitive for engineers accustomed to fully documenting a design before building anything physical. Shifting that mindset took ongoing work throughout the project.

The application launched in a limited alpha with 5 Challenger 300 customers. Automated cloud uploads reduced engine data access time from 1 hour per aircraft to 10 minutes — giving maintainers faster insight into engine health and freeing them from monitoring a physical connection through an entire download.

What I learned

Getting a cross-functional team in front of real users is worth almost any amount of organizational effort to make happen. The engineers who visited customer sites made better decisions than the ones who hadn't. That's not a coincidence.

The maintainers we worked with were some of the best users I've encountered in my career. They were knowledgeable, passionate about their work, and genuinely invested in helping us understand it. They wanted us to get it right as much as we did. That kind of user relationship doesn't happen automatically — it requires building trust, showing up prepared, and treating their time and expertise with respect.

One broader conversation happening across our aerospace team at the time was the idea of a digital engine logbook. We'd discussed it as a potential future direction, but maintainers in the field were cautious. The logbook is a legal document — it traces the aircraft's entire maintenance history and directly affects resale value. Losing it to a corrupted file wasn't theoretical; it was a real concern. That conversation was a useful reminder that users often have very good reasons for holding onto analog systems, even when a digital alternative seems obvious.

And finally: hardware and software need each other earlier than anyone thinks. The Bluetooth-through-aircraft-skin problem wasn't unsolvable — but discovering it late in the process cost us time we could have spent building. Tighter integration between the hardware and software teams from the start would have made the alpha smoother.