Move freight forward with confidence
Your team already knows how to run a reliable operation. IntelliTrans gives them the clarity, tools, and support to do it with greater confidence and control.
There’s a particular kind of confidence that comes from deep domain expertise. You’ve moved bulk commodities across rail networks. You know the Class I relationships, the dwell time dynamics, the seasonal crush, the difference between what a shipper needs and what they ask for. That knowledge is genuinely hard-won and genuinely valuable.
It is also, occasionally, the thing that stops you from seeing clearly.
The people who know an industry best are often the last to question its architecture. Ironically, the sharper the expertise, the stronger the pull. Daniel Kahneman spent decades studying why this happens. In Thinking, Fast and Slow he drew a distinction between the “inside view” — the perspective of someone immersed in the details of a problem — and the “outside view” — the perspective of someone looking at the base rate, the structural pattern, the thing you can only see when you step back far enough. Experts, he found, are systematically over-indexed on the inside view. The more you know, the more your judgment is shaped by the specifics in front of you, and the harder it becomes to see the pattern from the outside.
That cognitive trap plays out at the industry level too. I heard Clayton Christensen lecture at Harvard Business School (HBS). His framework explained what Kahneman’s insight looks like at scale, which is incumbents trapped by their own expertise, optimizing a model that a better-positioned entrant would eventually render obsolete. The innovator’s dilemma isn’t just a market dynamic. It’s the industrial consequence of an entire organization defaulting to the inside view.
What neither framework gave me was a personal methodology for what to actually do about it as a leader. That’s what three industries taught me, and that tension is at the heart of Perspective Arbitrage.
This isn’t a soft skill. It’s a deliberate methodology focused on knowing when to lean on domain expertise and when to deliberately set it aside and ask the questions an outsider would ask.
My experience in venture capital sharpened this instinct early. When you’re evaluating whether to back a company, you can’t afford to be captured by how an industry currently works, you have to assess whether it should work that way at all. That’s a different cognitive posture than operating inside one. In venture capital, the outside view is the job. Every assessment starts with a single question: is this model capable of creating lasting value, or is it optimizing a flawed architecture? The discipline I've carried into every operating role since is holding that posture while also building the domain fluency the role demands
The arbitrage is in the gap between those two lenses. Domain knowledge tells you how to execute better. The outsider lens asks whether you’re executing the right thing. Both matter. The risk is defaulting to one at the expense of the other, and in my experience, the pull toward domain knowledge is strong, because that's what gets rewarded, promoted, and trusted.
Perspective Arbitrage is the practice of holding both simultaneously, and knowing which one the moment calls for to unlock value the model alone cannot see.
Bulk commodity shippers have historically thought about visibility as exception management; you instrument the network to know when something has gone wrong. Car on wrong track. Shipment behind schedule. Detention accruing. While it has started to evolve, the entire mental model is built around catching failure.
A technology company would ask a different question: what if visibility is a planning input, not an alert system? What if the data that tells you where your railcars are could reshape how you commit inventory, sequence production, or negotiate with customers? That’s not a better version of the existing model. It’s a different model entirely, one that domain experts didn’t build because the existing one worked well enough, and working well enough is the enemy of working differently.
Trucking has historically thought about capacity as a procurement problem; you negotiate rates, build carrier relationships, and manage a routing guide. A technology company would ask a different question: what if capacity isn't a procurement decision at all, but a data problem? If you can see real-time carrier availability, lane performance, and demand signals simultaneously, you're not procuring capacity, rather you're orchestrating it dynamically. That's a different model entirely.
Rail itself is another example. It’s an infrastructure-dependent mode, which means decades of optimization have been applied to a fixed physical constraint. The expertise in the industry is truly extraordinary, and it has been largely directed at making the existing network more efficient. The outsider question is whether the constraint is the infrastructure or the information layer sitting on top of it. If you can see the network clearly enough, fast enough, and act on that signal in real time, the physical constraint becomes less determinative than it appeared. The model was the constraint, not the railroad.
I didn’t develop this methodology at IntelliTrans. I watched it play out across three industries before I could name it.
At Virgin Media, the consumer internet business was run by people who deeply understood cable infrastructure, customer acquisition costs, and churn dynamics. What it lacked was a technology company’s instinct for instrumentation, the idea that every user interaction is a data point that should reshape the product. Once we started asking technology questions of a cable business, the growth model changed.
At Info-Pro, we were building fintech SaaS in a market with decades of entrenched workflow assumptions. The domain experts knew exactly how compliance and data processes worked. What they were slower to question was whether those processes needed to exist in that form at all, or whether software could eliminate the workflow rather than accelerate it.
At IntelliTrans, the pattern was the same but the stakes were highest — because this time the technology forcing the question isn't just software, it's AI. The sharpest operational minds in the business had spent years perfecting how to navigate the existing information layer. What they hadn't asked — because the current model worked — was whether that layer itself could be rebuilt to change what's operationally possible. The information layer we're rebuilding isn't incrementally better than what existed before. It's a different category of capability entirely. And unlike Virgin Media or Info-Pro, this isn't a retrospective. The work is happening now The pattern is consistent across Virgin Media, Info-Pro, and IntelliTrans: mature industries with deep domain expertise tend to optimize the existing architecture rather than interrogate it. The expertise becomes self-reinforcing. The people who rose through the organization often did so by mastering the current model, which creates a structural bias toward refinement over reinvention. Kahneman predicted this at the cognitive level. Christensen documented it at the industry level. What I’ve been working out, across consumer internet, fintech, and now industrial freight, is what it demands of you personally as a leader who has to interrogate the model while running it.
That’s the methodology. And it’s harder than the theory suggests.
Knowing that Perspective Arbitrage matters is one thing. Building it into how you actually lead is another. The tool I’ve found most useful is what I think of as the Visiting Investor Test.
This isn’t a theoretical exercise. It’s a deliberate cognitive switch, Kahneman’s outside view made operational. The visiting investor has no attachment to how things have always worked. They’re not defending a prior decision or protecting institutional knowledge. They’re asking whether the architecture makes sense given what’s now possible. That’s the posture Perspective Arbitrage requires, and the Visiting Investor Test is a way to force it in a structured, repeatable way.
In practice this means asking questions that feel almost impolite inside a mature organization. Not “how do we move more freight more efficiently?” but “why does a shipper need to own this problem at all if the information layer can absorb it?” Not “how do we improve our visibility product?” but “what would a technology company build if they were starting this from scratch today, with no legacy architecture to defend?”
These questions make domain experts uncomfortable. They should. That discomfort is the signal that you’ve successfully adopted the outside view, that you’re no longer optimizing the model but interrogating it.
Supply chain is in an unusual moment. The infrastructure is the same. The physical constraints haven’t changed. But the information layer is being rebuilt from the ground up — AI, real-time visibility, predictive modeling — and that changes what’s possible at a structural level, not just an operational one.
Kahneman showed us why smart people can sometimes get trapped by expertise. Christensen showed us what happens to companies when they do. The difference today is the pace and scale of what AI and real-time data are making possible, and the window for interrogating your model before someone else does it for you is narrowing. The question for supply chain leaders is whether you're going to wait for that pattern to play out around you, or develop the personal methodology to get ahead of it.
So here’s the provocation: when did you last apply the Visiting Investor Test to your own business? Not whether you could move freight faster, cheaper, or with less exception handling. But whether the way you’ve structured the entire operating model — the assumptions baked into how you think about inventory, commitment, visibility, and customer value — still makes sense given what’s now technically possible.
The domain expertise in this industry is extraordinary. It always has been. What’s changed is that pairing it with genuine technology thinking - not tools, but the mindset - is now the difference between leading the next chapter and optimizing the last one.