When Continental launched its first ancillary products—checked bags, exit row seats, buy-on-board meals—the industry was changing. Massive investment in the product. Massive investment in the technology to sell it. New check-in flows, seat maps with pricing, purchase paths at the airport, online and in the air.
The teams moved fast. As they should. Oil was past $100 a barrel for the first time ever and the existential threat was real. These new products would generate hundreds of thousands in revenue on day one.
The business owners who pushed these products to market needed daily revenue reporting immediately. So they worked with the developers who'd built the check-in software to get raw exports from the production database. No transformation. No cleansing. Just rows. That's not reckless—that's resourceful. You launch a product, you need to see how it's performing. They worked with what they had.
The data had duplicates. Missing refunds. Regularly overstating revenue. But it was first to press, the numbers were exciting and leadership celebrated them.
Later—always later—the data made its way into the warehouse. Joined with ticket, booking and loyalty records. Deduplicated. Refund logic applied. The cleansed version showed lower revenue—not so welcome news.
Here's what went wrong. It wasn't that the business moved too fast. It's that the product got a team, a budget and a deadline. The data got "we'll figure it out later."
The real problem isn't speed—it's asymmetric investment
This is the pattern. Not just at Continental, not just with ancillary products—everywhere. Airlines invest heavily in the product and the technology to deliver it. The data never gets the same investment at the same time.
New seat engine delivered. Data feed later.
New marketing cloud sending emails. Warehouse integration later.
New loyalty platform migrated. Customer 360 later.
And that "later" version? It arrives just good enough to satisfy the immediate need. Nobody goes back to define it properly, govern it, make it a foundation. Because by then, leadership has moved on to the next product launch. And the minimally viable data feed quietly becomes permanent.
Last week I showed you three departments producing three answers from the same airline. This is how that starts—not with teams moving too fast, but with organizations funding the product and not the data.
Every product launch that treats data as an afterthought adds another ungoverned pipeline to the architecture. Another set of silent business rules baked into transformation code that nobody documented. Another definition of revenue or customer or transaction that exists only in one team's reporting and doesn't match anyone else's.
Over time, these minimally viable data integrations accumulate. Each one works for its original purpose. None of them join with each other. And the organization loses the ability to answer questions that cross boundaries—because nobody ever invested in a unified model.
And here's what makes this expensive. When a commercial leader has a new idea—a pricing experiment, a loyalty partnership—the first question is always, “Can we get the data?” In an organization running on minimally viable data, the answer is always, “Yes, but it'll take time.” So the idea gets shelved. Or gets done with bad data. Or gets done once as a heroic manual effort nobody can repeat.
The business stops asking new questions. Not because the questions aren't valuable. Because the data was never funded to keep pace with the products it supports.
The business stops asking new questions. Not because the questions aren't valuable. Because the data was never funded to keep pace with the products it supports.
The answer isn't to slow down. And it's not a twelve-month architecture program that tries to boil the ocean. It's including data in the product investment from the start—same urgency, same ship-it fast-and-iterate cadence, same seat at the table.
Define the data alongside the product, not after.
Staff it alongside the product, not later.
What it looks like when data gets invested in at the speed of the product
When I say "shared definitions," I don't mean a glossary on SharePoint.
I mean decisions—encoded into the data architecture—about how every downstream consumer sees the world. Does a no-show count as recognized revenue or get backed out? Why does web analytics revenue never match revenue accounting? And which one is right? How do you define a unique customer who isn't in our loyalty program?
These aren't abstract questions. Each one changes a number on someone's report. In organizations running on minimally viable data, each pipeline answers them differently—not because anyone decided to, but because each was built at a different time by a different team for a different purpose. The business rules are buried in code. Undocumented. Unreviewed.
The teams that solved this did something nobody gets promoted for. They sat in rooms and argued about every one of these edge cases. And the resolution didn't live in a document—it got encoded into the unified data layer from last week. One set of rules. One transformation logic. Every report downstream inherits the same answer because the definition lives in the architecture, not in someone's head. That's shared truth.
The danger isn't that the definitions are wrong. It's that they're invisible.
The critical part: this work didn't require slowing down. It didn't require a massive governance program or an enterprise architecture initiative. It required including data people in the product conversation from the beginning—giving them the same access to stakeholders, the same deadlines and the same expectation to deliver.
That's the real shift. Instead of each product launch adding another minimally viable feed to the pile, every new data source gets integrated into a foundation where the hard questions get answered. A new report doesn't require a new pipeline. It requires a query.
That's when innovation comes back. The commercial leader with the pricing experiment doesn't hear 'it'll take months.' They hear 'we can have that tomorrow.' Not because the technology got better. Because data work was delivered alongside product work and definitions got settled from the start.
At Continental, this eventually became standard practice—data investment written into every capital request as a line item, not a phase two. The result wasn't slower product launches. It was faster answers once they launched, and a foundation the next product could build on.
What this means Monday morning
If you're building the data: look at the transformation logic you maintain. If there's a rule you inherited and can't explain, that's a silent definition shaping a number someone trusts. Surface it.
If you're leading a data team: the next time a new product launches, don't wait to be invited. Make the case that data belongs in the original investment—and show what it costs when you're not in the room. Progress over perfection keeps you there. Dogma gets you uninvited from the next launch.
If you're the executive funding the investment: ask whether data is a line item in the capital request or somebody else's problem. Fund them together and you'll get answers at the speed of the product, not months behind it.
The most valuable work in data often doesn’t come with a clear business case the way products do. Fund it anyway. It’s the foundation on which all the other business cases are built.
That daily ancillary revenue report from the raw production export? It stayed in circulation longer than anyone would like to admit. The governed version eventually won—but only after someone did the tedious, uncelebrated work of reconciling every discrepancy and proving, line by line, that the complete data told a different story. Nobody got promoted for that work. It just quietly became the foundation everything else was built on.
What's in the pipeline
Long Lake, an AI-focused investment firm backed by General Catalyst and Alpha Wave, agreed to take Amex GBT private for $6.3 billion. The Travel Weekly headline named the asset directly: an AI-focused firm is buying the world's largest corporate travel platform "and its deep data." Corporate travel is one of the cleanest behavioral datasets the industry produces—who flies where, when, in what class, for whom, for how much. Whether the $6.3 billion bet pays off depends on whether GBT's definitions are clean enough to feed the models Long Lake intends to run on it.
Virgin Atlantic became the first airline to launch a booking app inside ChatGPT. Skyscanner and Omio rolled out their own ChatGPT integrations weeks earlier with multi-airline aggregation. The distribution channel is suddenly conversational, which raises the bar on the data underneath. Natural language queries don't tolerate four definitions of revenue, three definitions of unique customer or a fare bucket that means something different in two systems.
What I'm cooking this week
Traveling this week, so it’s time to break out the frozen double batches of homemade goodness. My oldest will help out. Thawed bolognese, add pasta. Thawed beef stew, add rice. Thawed tomato lentil soup, add sourdough.
—
Bought my ticket for the Skift Data + AI Summit. June 3 in Manhattan. Last year sold out and the speaker list this year runs from Amadeus to Amex GBT to Mews. The growing AI conversation now is all about the plumbing underneath, and expect to hear a lot about it.
If you're going, find me.
The vector
The plumbing gets built when the cost of not building it shows up on the same page as the product launch. Those conversations happen around the boardroom table, not in project plans or enterprise standards documents.
Next week: The Existing Assets Pattern—why the answer to your data problem isn't a new platform.
—Ben