In my first "real" job, I was a software engineer for cargo aircraft avionics.

The airplane I worked on had a very strange relationship with the world. One of the systems (that stored flight path data) understood the world was a sphere. Another, older system provided terrain overlay data, and rendered the world as a cylinder. When the two sources where overlaid on the same map in the cockpit display, a few very strange things happened at the extreme north and south edges of the map.

It was exactly the sort of interesting problem that is easy to understand and describe, but requires weird math to fix. As a budding engineer, this felt like a very exciting problem to solve.

Then, after a few months of hearing that we were going to fix it, we got a chance to talk (just once, for an afternoon) with the pilots that actually flew the airplane.

We told them we were going to fix the problems that were caused, and they scoffed.

"We don't deliver to Santa very often. Who cares what the map looks like at the North Pole?"

The actual problems they had were much more practical -- the flight management system they used every day was unstable and unreliable, and would routinely crash while they were in-flight, resulting in labor-intensive data-entry and the increased risk they would miss something important going on around them in the cockpit. It was a hard problem to describe, unpredictable to reproduce, and involved very little math and a lot of careful debugging.

But unlike the map distortion around Santa's workshop, that problem Mattered.

I've learned a great deal about User Centered Design principles since the early 2000s, but the key lesson is always worth repeating:

Get time with your users.

Early, and often. And Listen.

When I moved from doing direct Product design work to leading multiple teams, I had to re-frame that laser-keen focus on user need and expand it to take into account strategic thinking and the intent of my own organization, and the organizations I supported.

For the first couple of years, I focused so hard on trying to tell the teams what I thought I knew that I forgot I had no idea what was really going on. Luckily, I was put in the right position to be reminded of my own ignorance, and that meant I could fix it.

Good research is hard work. . . but it doesn't have to be complicated

When I started doing research at the portfolio level and treating it with the gravitas and discipline it deserved, the results were immediately obvious -- it was easier to talk to teams, it was easier to align roadmaps, and it was easier to identify and communicate outcomes.

The teams I am leading now have vastly improved alignment with our organizational outcomes due to the research we've performed and shared, and we're seeing those teams set attainable goals, and creating and tracking metrics that will help us confirm that we're on the right track.

A better Turbo-Encabulator is just around the corner.