Travis Root

I'm the head of product management for the company formerly known as ForeFlight, now Jeppesen ForeFlight. That's an aviation company, software as a service. We have our data arm Jeppesen, which makes charts and data for airliners so they know where they're going, and ForeFlight, which makes the sort of Google Maps of the sky.

Generally airliners use our Flight Deck Pro product, which is tailor-made for them. I don't really deal with that side of the business. I deal with general aviation, so that's folks flying their Cessnas on the weekend, your weekend warriors; business aviation, your rich-guy business jets; and military aviation, from trainers to fighters, bombers, you name it. That's all around the world.

Product management is sort of the art of deciding what to build, what will drive business value, customer outcomes, what's worth the time for the engineers. Proud to run that — been doing it for about 10 years, came up as a very junior role and now oversee the general business and military markets.

Working in a vertical — you have to bring a lot of domain knowledge to it. It's very difficult to do this job if you're not a pilot. I happen to be one. Most of the people who work for me are, and you have to understand the workflows, the lingo, what matters when, what doesn't. Much different than working in a horizontal. If you're making a CRM for all different sorts of businesses — dental offices, plumbers, whatever — you don't necessarily need to know any of those industries very well. When you're working in a vertical like aviation, you certainly do.

Many of them are, yeah. A little under half of them are pilots. That's great because they bring their own creativity and knowledge to the problem. Certainly helps the development process, designing what's going to work in the space and what's not. So we definitely prioritize that in our hiring.

So there's really two ways you could use it. You could use it to build the software, and what comes out the other side is more or less the same software we've always been building. We are doing a degree of that, and we're holding that to the same standard we always have, which is good and bad because reliability and safety is paramount. But it puts a brake on the advantage you could get out of AI, which can generate thousands of lines of code in a fraction of the time it would take a human. But we have to know if that code is any good. The state of the art today is, it takes an engineer to sort of read through all those lines of code and make sure it's up to our standards. You can apply AI on top of AI to help with that problem, but it doesn't catch everything. You can apply unit tests and integration tests on top of that, but they don't catch everything. So we have sped up our development with AI, but only to a point.

The other side is, you can use AI in the product to do things that are difficult to do with classical algorithms. Aviation is kind of a ripe space for that. There's a lot of elements of aviation that are natural-language-based — talking on the radio, these things called NOTAMs, which are notices to airmen, sort of plain-text notes about what's happening at the airport or in a given airspace. Those were invented in a time when sending characters around was very expensive, back in the 60s and 70s. So they have all these weird abbreviations. They're very hard to actually read. The net effect is most pilots actually kind of ignore them, even though they're really not supposed to.

Both those problems — radio communications, NOTAMs, and many others — are ripe for AI to come in and do something with. But again, reliability is a concern. What if it interprets the NOTAM the wrong way, misses something, or tells you inaccurate information? So it's been challenging to design reliability into the system when working with LLMs.

Yeah, it's its own unnatural language, but still spoken and heard and interpreted.

The state of the art of AI has become so much more useful over the last year. It's gone from just sort of something you can chat with and it's mostly right, sometimes it's not, to where it can actually do stuff and more and more reliably accomplish what you're actually trying to accomplish. That's come about now that we've got the agentic harness around the models — Claude Code is a great example. There's Claude Co-Work now, which is less specific to code. OpenAI's Codex is right there along with it. If you think about what we've always wanted Siri to be on our phones, it's this agentic harness with a model in the middle. Siri never really lived up to that promise, but now we're seeing things that are living up to that. That's got me really excited.

I'm a little scared of OpenClaw. I've installed it, but I haven't really done anything with it. We've taken it as inspiration for, what if you could put some guardrails and assurances around this? What could this be in the aviation vertical? Because a lot of our customers are small flight departments — the CEO or the C-suite has a corporate jet and they've got their assistant sort of running it, and the assistant may or may not know how to actually accomplish that. Or it all falls on the pilot who spends most of his time flying the plane but now has to do all these other side things as well. So what if we could reliably automate that through a system like OpenClaw? OpenClaw today, we would not trust to do that, but we're thinking about, what could we trust to do that?

Yeah, well said.

Everyone's freaked out about what this means for employment. Everyone's got their aha moment when it comes to using these things. If you've never used Claude Code or Codex — once you see what it can do, you sort of understand there's almost no bottom to what it could do when it comes to knowledge work. For a long time, I thought of AI as really just putting words on the screen, but a lot of our jobs are also putting words on the screen too.

We're getting a lot of that unease from the broad public, from the consumer sector in particular. It's very understandable, because the sort of machine that eats everybody's jobs, that's soaking up all the capital and interest in the industry, is kind of hard to wrap your head around.

Oh yeah. And I'd say that's very common around my colleagues, around other companies in the industry, in every industry.

I've got a team of about eight people now, eight product managers, and they're all making heavy use of AI, some more than others, to write product requirement documents. Generally I tell them, that's what you shouldn't use it for. Writing the PRD, I find, is the act of thinking through the problem — it's writing it down. And to be fair, I don't think anyone is reading my PRDs to begin with. So if I'm saving time writing that, who am I really helping?

But it's been phenomenal for research, for prototyping. Now the requirements are not necessarily things written in the document. You can put that in code up front and use that as a jumping-off point. So it's been useful in that regard.

We've got close to a hundred engineers.

It is. Some engineers are leaning forward into that, and we're trying to define what our development looks like broadly, beyond just what the role of the engineer is. The line between the engineer and the product person has gotten very blurry. The line between the designer and the engineer and the product person is now very blurry as well. So is that good? Do we need these sharp distinctions between people anymore? Because a big function of product management was to make sure your engineers weren't wasting their time on something that nobody would want. Well, if the return on their time has gone up 10x, 100x, is that important anymore? It still is to some degree, but what does it look like to cheaply produce code and test it — and not just test it for functionality, but test it for market response?

It's a big open question, not only what does the engineering role look like, but what does development at large look like? What we've experienced there is, now that we can quickly and cheaply produce code, it just revealed bottlenecks everywhere else. Now we are not going nearly fast enough on design, on quality assurance, on our CI/CD pipelines that are completely overloaded. It exposed all of the other bottlenecks in the process that were never a problem before because writing good code took so long, but now it no longer does.

Yeah, yeah.

Making sure that the code we're producing is up to our standards. The PR reviews are still highly manual. The unit tests and integration tests, we don't really trust enough that we can get those passing. Sometimes you ask the AI to help you pass those tests and it says, okay, I cheated on the test, in so many words. You've got to be careful that you catch those. Quality assurance and PR reviews are our biggest bottleneck.

Right behind that is design. The thing about design is, it's one of those jobs like product management where anybody can kind of do it. Engineering used to not be the case because you had to know how to write code that worked. But if you could do that, you could say, that looks good enough — or, I have domain knowledge here, particularly in our field where we employ a lot of pilots who can go fly themselves and understand what the problem is and what needs to be built. You could kind of just get yourself there as an engineer. And now engineering is becoming that where everybody can kind of do it.

Taste is very important. Convenience, ease. I think a big problem when you look at AI adoption, particularly with people who are not technical or in the tech field — OpenAI talks about ChatGPT's weekly active users at some astronomical number like 300 million. But why are they talking about it as weekly active and not daily active? I find that very telling. If you look at who returns daily, it's something like 5x smaller. Like 80 percent of people decide that this world-changing new technology that is soaking up all the attention and capex in the industry — the average person cannot find something useful to do with it more than once a week. I find that very telling about what the moat in the software industry is actually going to be.

Because you open this thing up and it's a kind of blank window staring at you, waiting for you to decide to tell it what to do. Well, a lot of software actually told you what to do. It encoded a process. It coached you through a workflow that needed to be done. AI doesn't yet do that. I think we're not far away from doing that. We could and are building that functionality today. But to your point, that requires some thought and taste, as it always has.

And I think the new crack might look like the old crack. Because remember, it took us 30 years of the Internet to figure out that the feed is what would hook people. It wasn't obvious from day one. We're still very early in AI. It might take us a long time to figure out what the next correct paradigm is to think about it. In the meantime, the new will kind of look like the old. So I think we'll quickly see something feed-driven, and maybe that will be better, maybe that will be worse than what we've already seen. I think it'll be kind of roughly the same.

The paradigm we're using today is to think of it as a person that you're managing. So you just go tell it what you want done as you would tell a person. But there are a great number of people in the world, in the workplace, who don't actually want to be a manager. So giving them something to manage is going to have, if you think about it that way, predictable results.

Yeah. The lawyers getting in front of judges with completely made-up cases is a great example.

I don't think it's been a big discussion around that. We recently went through a separation from a large strategic company. We were owned by Boeing. Boeing, as you've heard, is going through what they're going through, and divested us to improve their cash flow. When we changed ownership, that resulted in a layoff. That would have happened regardless of how we were divested, whether it was to the public market or to private equity, because the reality is a large strategic — our entire financial picture was a rounding error on their quarterly earnings. What we were spending on headcount didn't really matter. So AI was not a factor in that. If AI didn't exist, I think it would have gone down more or less the same way. How we're thinking about it now is, well, thank God AI is here, because we can now keep our velocity — or at least have a chance to keep our velocity and productivity up — when otherwise it would have fallen off dramatically.

Oh, you haven't heard about this? This has happened a number of times. Obviously the legal profession, you have to do a ton of reading, citing cases, and almost all of it stands on existing case law and precedent. Lawyers, without understanding what ChatGPT is or how it works or how it can hallucinate, were using it for legal research. And it would just out of whole cloth make up cases.

Yeah. Because the opposing side will go check these cases and see what they say and quickly find out that they don't exist.