The rest of this article has three sections. First, my conviction on the category of AI agents for enterprises. Second, a review of the available AI agents. Third, a deep dive into the AI agent my team and I created.

AI Agents Matter for Enterprise

AI agents will be the most consequential category in enterprise software because they move software across three existing boundaries.

First, AI Agents are a superset of tools and labor. Most enterprise software are tools to automate processes that were specified in advance. Agents can do that too, so they can replace other enterprise software categories in the same way that stronger CPUs replaced dedicated sound cards in personal computers in the early 2000s, or Notion replaced Airtable because they could do lightweight tables and web page forms. But AI Agents are also labor replacements: an agent can accept a goal, determine the steps, navigate systems and deliver an outcome. Its addressable market is therefore not the enterprise-software budget (from which it can heavily cannabalise). It is also the much larger scope of screen-mediated work. The market is not software. The market is work.

Second, AI Agents release businesses (and our whole society) from the bottleneck of labour. Human talent is a scarce, rival, slow-to-produce and difficult-to-move input. AI agents convert labor capacity from something acquired through hiring into something acquired through provisioning. Is it unlimited? No. Compute, energy, data, trust and management attention are the new constraints. But knowledge work is becoming elastic as a result of AI agents. To get a sense of how important it is to liberate businesses and our whole society from the inelasticity of human labour, imagine another naturally constrained input into our economy: land. AI Agent’s impact on labour resembles being able to create new land precisely where a city wants it, in some kind of alternative dimension that doesn’t face rivals for the other uses of that land.

Third, AI agents are the linking bridge for businesses between their past capital investment into systems and processes and the once-in-history capital investments into compute. The world is financing one of the largest infrastructure build-outs in history: data centers. The world is projected to invest approximately $7.6 trillion in AI infrastructure from 2026 through 2031 (according to Goldman Sachs) on top of the record $450 billion spent already in 2025. Agents are how that capital reaches the enterprise P&L because compute is a stranded asset until it can act inside the systems, permissions and workflows every business runs. Data centers convert electrons to intelligence; agents convert intelligence to impact. They let every company leverage the balance sheets of the hyperscalers and convert compute into completed work.

A seller’s guide for AI Agents

If I believe AI Agents are the most important enterprise category, it stands to reason I also think they are a good business to be in. But that’s not because they have pricing power and are mostly extractive.

Most of the rest of this article will give my views on the category of AI Agents from the buyer’s view. But if you want to build & sell AI agents there are probably three key points to note.

First, this is an immensely value-aligned category. To succeed, you make AI agents that do direct, valuable work for enterprises. They’ll pay a lot for that because (a) it’s creating value and (b) the impact on their business is direct in a way that significantly de-risks the purchase. This is an obvious win-win situation. Agents can fuel the rise of enormous software vendors while still transferring an unusually large share of the productivity surplus to their customers. The buyer captures the difference between the cost of agent capacity and the value of the work produced. The vendor captures a portion of a dramatically expanded value pool.

Second, there is plenty of room for multiple winners. I cannot express how frustrating it is to hear “you have to be joking if you think you can compete with [Claude / ChatGPT / Gemini].”. Let me fully channel my inner Jensen Huang here.

“You’re not talking to somebody who woke up a loser. That loser attitude, that loser premise makes no sense to me.” Jensen Huang when responding to the statement “but you’ll lose the market eventually anyway”.

The belief that only the big names of Google, Anthropic, Microsoft, and OpenAI have a chance to win in the AI Agent category is just illogical. There isn’t a structural reason it should happen. People who hand wave towards “their scale” are too lazy to finish the logical chain all through. What % of that scale goes into AI agents? Do they have a lock on any scarce resource? Do agents increase or decrease their distribution advantage? Does a vertical integration to one model family help or hinder? And so forth. Go ask the insiders at these companies if they think they will just “win” by default. Nope. And if in doubt, go ask Github Copilot about getting their business eaten in front of them by the sub-100 person start-up Cursor. Giving up just because they are big is a loser mindset. And a market of this size (most enterprise applications and lots of knowledge work together) is not going to be winner-takes-all.

And third, the AI agent category is attractive because it’s nascent. All the compute in the world in 2019 wouldn’t have made GPT-3 without the right LLM research breakthroughs. All the mechanical engineering in the world wouldn’t have made an airplane in 1900, but a small town workshop could make them in 1920. And no one could have made an AI agent of use in the enterprise in 2023, but anyone can make them in 2026. That means the most important enterprise software category is being born right now, and it’s an immense advantage to be early.

Now let’s look at AI agents from the buyer’s side.

A buyer’s guide for AI Agents

Every company has a mandate to their IT leader to help bring in AI to the business. That means buying AI Agents. Again, we don’t need to get fancy here: every vendor is saying their AI agent is “software that does work for you”. So, what I’d propose to do is to survey the leading AI agent options and explain their strengths and weaknesses. I’ll include the AI Agent me and my team just released, not to sell anyone on it but to explain what animates thinking it needs to exist when these other options are already available.

The good news is that enterprises do have some options: there are multiple AI Agents from reputable vendors. Where they differ is in what kind of worker the agent becomes, who it ultimately serves, and the basis on which it can be trusted. So, buying an AI Agent really amounts to knowing what you want on these aspects and then lining that up with what each vendor has focused on.

Eliminate the wanna-be agents

The first and easiest step is to eliminate the fake options. Every legacy software vendor has added some automated workflows and called these agents. But these are more a marketing game than a real agent. If the agents are so smart they wouldn’t be constrained to just a few workflows. They aren’t connected to anything but the tool they are inside. And they don’t compound into a unique agent for your business. Basically, this is fakery and the best thing to do is ignore them when looking for a real AI Agent.

The Real Options

The following general-purpose agents illustrate the major stories in the category.

1. Anthropic’s Claude Cowork

2. Nous’s Hermes

3. OpenAI’s ChatGPT Work

4. Google’s Gemini

5. Microsoft Cowork or Copilot (Microsoft is fuzzy in deciding what they call their agent)

I’ll speak to each in turn, and address those differentiation questions: what kind of worker the agent becomes, who it serves, and the basis on which it can be trusted. I consider these together to be the “story” of the agent.

Claude Cowork

Claude Cowork’s promise is to delegate the work surrounding your best work. That is an attractive promise, because it means the AI agent isn’t threatening the user at all. It is supporting them by doing the clerical stuff while leaving the best of the job for the human. Their trust story is built on the brand reputation of Claude Code (for engineers), and because work is visible, steerable and reviewable, with scoped access and permission controls.

What I like about Claude's story

1. It chooses a replacement-safe enemy. Anthropic is not saying, “Claude does your job.” It says Claude handles the connective burden preventing you from doing your job well. The customer’s expertise becomes more—not less—important.

2. It ends with an artifact. Decks, trackers and reports are more credible than abstract claims about intelligence. The story concludes with evidence the customer can inspect.

3. It inherits credibility from Claude Code. Rather than asking customers to believe that general agents suddenly work, Anthropic presents Cowork as the proven execution model behind Claude Code, translated for nontechnical users. Independent testing from WIRED largely validated this: the reviewer found Cowork effective at file organization, report generation and several browser tasks, while noting failures and beta-stage limitations.

4. It gives the human a better identity. The user is not reduced to approving automation. They become the person setting direction, exercising judgment and making consequential decisions.

Hermes

Hermes’s promise is that you’ll cultivate an agent accumulates memory, procedures, personality and operational experience. That’s an attractive promise because the AI isn’t threatening to replace the user. In fact, the user is the owner, teacher, and beneficiary of this apprentice under their guidance. Their trust story is built on full control, even down to the source code and on what device it runs.

Cowork’s story is delegation: give the agent the work and get an artifact back.

Hermes’s story is accumulation: every time the agent works for you, it becomes more yours.

What I like about Hermes story

It changes the basis of competition. Most AI products compete on current model intelligence. That advantage is temporary because models improve and competitors can adopt similar ones. Hermes instead competes on accumulated experience. Even when two users run the same model, the agent with months of relevant memory and tested procedures should be more useful than a fresh instance.
The implied claim is that the best agent is not necessarily the smartest agent on day one. It is the agent that has worked with you the longest. Cowork’s story is delegation but Hermes sells accumulation. That makes Hermes less like an on-demand contractor and more like an apprentice who develops institutional memory. The product is not primarily selling one completed task. It is selling the increasing value of a persistent relationship.

It turns open source into a customer benefit. Open source is not presented merely as a development philosophy. It supports the idea that the agent belongs to the customer. Hermes can use Nous Portal, OpenRouter, OpenAI, local models or custom endpoints. Its memory and skills are stored outside the underlying model, so the user can theoretically replace the intelligence provider without abandoning the agent they have cultivated. That produces a stronger ownership story than “you can inspect the source code”:

It gives the customer an active role in making the agent. The user is not simply delegating work, even if that was supposed to imply the boring work. They are teaching, correcting and shaping the agent. That creates a productive emotional dynamic. Time spent onboarding Hermes is framed as an investment rather than a setup cost. Corrections are not failures; they are lessons the agent can retain.

It creates a compounding-value argument. Conventional software provides roughly the same value each time it is used. Hermes promises an upward-sloping value curve:

1. The agent completes a task.

2. It remembers relevant facts.

3. It codifies a reusable method.

4. The next related task requires less instruction.

5. Corrections further refine the method.

All told, Hermes is more ambitious than the other agents.

ChatGPT Work

ChatGPT Work's promise is that you trusted ChatGPT to plan the actions, and now you can trust it to do them too. That’s attractive as a promise because it requires almost no change from chatting. Their trust story is built on the huge consumer experience with ChatGPT, along with how the agent narrates its activity, can be interrupted or taken over, and asks for approval before consequential actions.

What I like about ChatGPT Work story

It builds on an existing relationship. Most agent products require customers to adopt a new interface or conceptual model. ChatGPT Agent appears as a mode inside an established conversational interaction. Yesterday you asked it. Today you can ask it to do it. That is easier to understand than a new category vocabulary.

The elimination of the big handoff. The most powerful use cases combine activities that previously belonged to different places. “Analyze competitors and create a deck” contains research, source evaluation, data organization, writing, design and file production. “Review my calendar and brief me using recent news” combines private context with external research. The product’s value is not any single step; it is carrying context across the entire chain.

It dramatizes the shift in agency. The movement from answers to actions is observable and consequential. Creating a slide deck, updating a spreadsheet or completing a booking is fundamentally different from generating recommendations about those activities. Its no longer one tool for planning and on e tool (the human user) to execute. The before-and-after is therefore clear:

• Before: AI advises; the user executes.

• After: the user directs; AI executes.

The “own computer” UX makes this in-your-face obvious. Users can observe it navigating, downloading, manipulating and producing work. On-screen narration, progress updates and browser takeover transform an invisible model process into something resembling supervised work. This is particularly important because agent value is difficult to communicate through static feature lists. Watching the system cross application boundaries is itself the demonstration.

Google Gemini & Microsoft Copilot

Gemini’s promise is its low friction: it is already present in every Google product, ready to assist you. The same can be said for Copilot for Microsoft. And that’s all most businesses really want right now. They offer the lowest power but lowest friction experience.

What I like about Gemini story

1. Google can plausibly deliver. “An assistant that knows you” would be speculative from a new entrant. Google already stores much of the information people use to manage their digital lives.

2. Lower ambition means higher success rate. “AI Agent” is difficult for most customers to evaluate compared to a prompted action in a specific application. Because Gemini works from within applications it is much more likely to get small scale tasks that are cleanly mapped to that application. That boosts chances to succeed.

The Trust Gap

In a perfect world, an AI agent must be two things: powerful and safe.

Powerful

• Intelligent enough to handle ambiguous work.

• Connected across enterprise systems.

• Compounding as organizational knowledge accumulates.

Safe

• Aligned to the enterprise’s authority and policies.

• Operating through approved skills.

• Tested before release and monitored during operation.

Power means it can reason through ambiguous work, act across your systems, and become more useful as organizational knowledge accumulates. Safety means it serves the enterprise, operates through approved ways of working, and produces evidence that it remained within policy.

Which is the greater barrier to consequential AI agents for most enterprises today: capability or trust? Trust, obviously. And that is the root issue I see with the options already reviewed. When Claude says “delegate the work behind your best work”, or Hermes says “cultivate an agent that belongs to you”, or ChatGPT says “agent can do it for you”, who do they mean with “you”?

Consumer agents serve the person giving the prompt. Enterprise agents must serve the organisation. And above all that means predictability. Traditional automation is predictable because it cannot improvise. Consumer agents are powerful because they can. The enterprise challenge is to preserve that intelligence without skipping control.

Obviously these agents have safety features. They offer permissions, confirmations, visibility, sandboxes, and administrative controls. The gap is who those protections are designed around: the individual user. In an enterprise, the person giving the prompt is not always the ultimate authority. Their authority is delegated and bounded by law, company policy, data rights, contractual obligations, and the rights of other people. An enterprise’s AI agent must therefore know more than what the user wants. It must know what the enterprise permits—and produce evidence that it stayed within those boundaries.

Why we made Trimble Arc Agent

In Q1 2023, newly installed in a role over all product & engineering at Transporeon, I laid out a generative AI strategy that centered on a mission to transform ourselves, to bring AI Agents into our workplace and to treat them as colleagues making consequential decisions. We built a new organisation, the Applied AI group, dedicated to this mission. We achieved deep, consequential transformation of ourselves. And the culmination of that work was an enterprise-grade AI Agent that we released for sale: Trimble Arc Agent. Way back at the start we had the firm conviction that dogfooding was key. How else would we know what an AI agent needs, how to roll it out, how to make it safe? And how else could we legitimately propose to help our customers into the AI age if we had not gone there ourselves?

Like Claude, ChatGPT, and Hermes, our Trimble Arc Agent can do knowledge work, take modest quality requests or triggers and produce quality work within company systems and procedures. It is smart, it connects to all your systems. And it accumulates knowledge and skill, becoming uniquely yours. But unlike the alternatives, Trimble Arc Agent knows who it works for. It understands enterprise identity, authority, policies, and risk boundaries. It moved us from experimenting with agents and hoping they behave correctly, to delegating important work with evidence, control, and accountability.

Three mechanics for safe enterprise AI agents

Above all, there are three mechanics of safety that make Trimble Arc Agent uniquely appropriate for enterprise use.

First, allegiance: who it serves. A consumer AI agent won’t help you build a bomb, but it will blindly contravene team norms, customer contracts, or company policy. Consider these demands on an AI agent:

1. Enterprise policy and legal obligations.

2. The authority delegated to the employee.

3. The employee’s task instructions.

4. Information encountered in emails, documents, applications, and websites.

In an enterprise context, instruction lower in that hierarchy must not override one above it.

Second, skills: how we work around here. Obviously skills seem ubiquitous: Andrej Karpathy’s proposal of them resonated with the world the same way his voice coding and other ideas have. But skills have deeper meaning for enterprises. A skill is a versioned, testable unit of delegated authority. It defines:

• The outcome the agent may pursue.

• The permitted data, tools, and systems.

• The company’s procedure and decision rules.

• Required approvals and escalation conditions.

• Quality, evidence, and audit requirements.

• Tests and runtime signals.

An agent that reaches the right result through the wrong process may still create regulatory, security, financial, or reputational risk. Arc Agent skills are how you teach the AI Agent the company’s procedures, judgment, standards, constraints, and ways of working. And by skill I don’t mean workflow. A workflow prescribes every step. A skill gives enough freedom to handle ambiguity, with explicit boundaries a company cares about.

Third, controls: how you know. Safe behaviour should not be just observed or prompted, but independent of the large language model. Every skill is evaluated and red-teamed before release, enforced and monitored while operating, and supported by an attributable record afterward. Production exceptions become future tests, so assurance improves with experience.

This approach aligns with established enterprise risk-management thinking: NIST, ISO/IEC 42001, OWASP, and MITRE. None of these are pertinent to consumer AI Agent experimentation.

Skills matter more in Enterprise

Obviously, an agent that learns will compound in value. And compounding is a crucial, often missing, part of the promise of AI agents. But our skills catalogue is not just a means to learn, it is a step-by-step means to trust in delegation. Every approved skill expands what the agent can safely own. It makes the agent more powerful and also safer. No other AI agent has this duality, this use of safety as the pathway to useful.

The last thing to say about skills is to look at their lifecycle. The catalogue creates an enterprise control point because each skill goes through:

Define → test → approve → publish → execute → monitor → improve

This resembles how enterprises already manage software, policies, and operational processes. It gives agent behavior an owner, a release process, and a history that is appropriate to enterprise IT, unlike plugins-at-your-own-risk in the other AI agents.

In summary

Here is a quick table summary of how I think of the major AI agent options.

Whatever your view is on these options, I hope we can agree that AI agents are an exciting, important, and timely category emerging for enterprise software. Whether you are a buyer, vendor, investor, or industry analyst: this is worth understanding.

Today’s article is about what that means for SaaS as a business model, and it’s triggered by my experiences with the rollercoastering of the SaaS Apocalypse. I felt it from six different seats at the table: as a public market investor, a private equity LP, a venture capital LP with stakes in AI natives, a B2B SaaS leader accountable for headcount decisions, an individual product creator, and a serial entrepreneur watching for what comes next. What follows is what those six vantage points have in common.

The Debate About Winners & Losers

The consensus is that making software is getting easier, faster, and therefore cheaper. No insider would really challenge this. But the reason there are both buyers and sellers in the SaaS Apocalypse market turmoil is that people can disagree about what this implies for SaaS businesses. Maybe cheaper, faster, easier software creation means all power is in distribution and hence incumbents. Maybe it favours upstarts who can start with clean code and small teams, rather than the paralysis of bloated teams and tech debt slowing the ship. Maybe it means both the incumbent and the start-up are commoditized and will be eaten by a foundation model company when their number is called in the waiting room. Maybe model companies are really just wholesalers and the profit pool will remain mostly with data center and chip vendors. Maybe there is no special law of the universe that preserves the profit pool of software and all of these players will be utilities of the future. Maybe AI is a bubble and anyway ChatGPT hallucinated me when I tried it in 2022 so it’s not actually going to change anything.

With the exception of the last view, in which AI is a bubble, I see evidence for all of these perspectives. Most poignantly:

• Incumbents Will Win: In B2B, especially at enterprise scale, the bundling & distribution advantages often overcome whizzy product differentiation. Zoom might be the best video conferencing tool in the world but it cannot field a sales team, pay for brand marketing, or package a multi-product commercial bundle like Microsoft. And so it loses.

• Start-Ups Will Win: AI Native start-ups (and even some non-natives pretending to be so) can vastly out maneuver the rusty old software vendors. Although each little agile twist only nets a small gain, these add up. Start-ups in logistics tech are riding the AI interest to real sales much, much better than the status-quo leaders.

• SaaS will be commoditized: Any logistic tech vendor who thinks their industry expertise is the differentiator is blind to the fact that foundation models are absolutely capable of understanding and reasoning and acting on the full jargon and complexity of logistics. I dare anyone to develop a gradable logistics expertise test and then give it to 100 professionals of their choosing and see if they beat the frontier models. In time how could we doubt foundation models will therefore eat all these little wrapper-applications that simply ride the foundation model?

Paradoxically, I think all three of these explanations are true. Paradoxes come from mistakes in definitions: you get your terms wrong at the setup and a few steps later divide by zero and get an infinite. What’s happening here is a subtle failure to account for the fact that each of these parties needs different outcomes to count as a success. Start-ups need to grow revenue quickly. Incumbents are happy with smaller growth rates but are especially focused on profitability growth. Foundation models simply need usage and that need not be from taking market share in a category like SaaS. All three can succeed in their own terms, and especially if one considers time horizon differences it seems likely they will do so.

An Alternative Hypothesis

But I have a more interesting idea to share. I think we’re seeing an apex moment, a kind of pinnacle culmination in the SaaS business model, that itself harbinges the end of the SaaS business as we currently know it. To be able to move this forward let me break this into three separate claims:

1. SaaS businesses have normalised or codified into a set of patterns and playbooks that anyone experienced in the sector would recognise as prior art.

2. AI natives, despite often making products that couldn’t have existed prior to AI, are actually executing the SaaS playbooks. They are technically impressive and structurally imitative.

3. For the same reason that an AI Native startup can blitz into large scale business, their business model is poorly defended. Their only moat is that of running faster than their peers, and that is brittle as a differentiator.

Eventually, most software will come from sources that operate in the new unit economics, speed, and lack of moat. This era is hallmarked by different playbooks than what we use for SaaS, hence it means an end to the internet-era SaaS and the start of one or more new inheritor business models.

SaaS Culmination

When I first started making software businesses, I listened to the Stanford Series on Entrepreneurship and read books like Four Steps to Epiphany and Lean Startup. There were playbooks but a lot that we now take for granted couldn’t be looked up in a book: growth hacking, for example. Piece by piece there emerged an internal grammar of silicon-valley style software entrepreneurship that proved itself useful in codifying and transmitting hard won lessons. It made people successful, reliably. Places like Y Combinator and then virtually all seed or early stage investors could give the same advice to every software founding team regardless if they were a dog-walking service, a home loan marketplace, or a video editing tool. Stanford went from having a series of guest speakers come give open-ended advice, to formalising these advice into a curriculum and awarding credits for completing it in a semester.

For me, this is reminiscent of the late-Baroque or late-Gothic moment: a style so fully worked out that anyone competent can execute it. That’s both its peak and the beginning of its irrelevance because differentiation shifts towards execution rather than creativity.

AI Natives = Execution

Take as an assumption that a motivated person can learn the art of SaaS entrepreneurship. Also agree with me that generative AI, properly harnessed, will complete tasks that we ask of it. Finally, let’s say that every year a certain number of optimistic, talented, ambitious people think they should try to start something with some idea they have come across. Only now, in the dual moments of SaaS entrepreneurship maturity and AI agents doing their bidding, their odds of success have improved. This is effectively my thesis for how most AI Natives are achieving their astounding growth. Their ability to find market-worthy ideas is probably no better than previous generations. Their intelligence, grit, and working hours are no different. But they inherit a very mature conceptualisation of how a great software business is built and run. And they need much less capital to hire people and are subject to much fewer vagaries of human staff. AI does the execution and 30 years of software business building furnishes the cookbook.

But their dizzying success rates has in it the kernel of the end of SaaS as we know it. Because SaaS business models are built on an assumption of winner-take-most, high-margin, high pricing power, and competitive moats. None of these seem to hold true in the new era, as the AI Natives own success foretells.

Moats vs oceans

I’ve had dozens of conversations with people who worried that a given AI Era product lacks a moat. When a software investor or creator talks about “moat” they mean an attribute that prevents competitors from simply imitating what works in a software and thereby eliminating that aspect as a differentiator. Those are exactly the differentiators we like because they boost win rates and shore up pricing power. In brief, moats are what make software businesses highly profitable. In some sense, a moat around a good software product becomes a natural monopoly. For example, consider SAP. I think SAP is a terrible set of software, and I’m not necessarily alone. But what I couldn’t have done until recently was to imitate SAP such that I could offer their customers essentially the same ERP functionality. If you wanted an SAP-scale ERP and you wanted it to be interoperable with an older version of SAP (for data migration) then the only real option was to buy from SAP. They had a natural monopoly on any future ERP replacement of an SAP customer because the sheer scale and (often undocumented) complexity of their software was a moat.

But in the AI era we can make syntactically and semantically correct code, even millions of lines of it, fast and cheap. Software was never much defended by patents, proprietary file formats, or data no one else could furnish. Most of the moats for SaaS were the barrier of “that would take too long or be too expensive to make”. And that’s ending. But in the twilight of this moment, June 2026, we see the oddity that the speed of some AI natives means they are creating highly profitable, high-revenue businesses in the classic SaaS paradigm before the market saturates with competition. They don’t have a moat, but no one is trying to take their marketshare yet so they don’t suffer from a lack of a moat.

The positive news is that the market for software may be larger, its contributions to society more beneficial, and working in this field more personally interesting in an era where every SaaS business isn’t using a treasure map to get to a high profit point surrounded by a competitive moat that allows them to extract a lot of the value they create. Maybe everyone, eventually, will be happier with less de-facto SaaS monopolies.

The children of SaaS

As SaaS competes with AI Native businesses, and eventually we stop assuming a software business is ipso facto a highly profitable business, we should expect some new business models to emerge. I’ve written about these before, suggesting that future software businesses might look more like hospitality, architecture or other creative design firms, luxury brands, mass customization. Sustaining high profit margins seems much more dependent on process mastery, brand, and the rare cases where data is genuinely a moat.

But one future scenario that I’ve been contemplating more and more is that software businesses become much more normal, operating like a pizzeria or tire repair shop or roofing company. A forthcoming book points out how out of touch with normalcy the Silicon Valley SaaS entrepreneurship model really is. You cannot expect to become a billionaire by opening a hair salon, a taco joint, a fencing contractor, or the hundreds of other normal businesses that make up the economy. But these businesses lead to millionaires or deca-millionaires with a probability that is a thousand times better than SaaS entrepreneurship in the VC-backed winner-take-most style.

What I’m suggesting is that by 2036, launching a software business might feel less like buying a lottery ticket and more like completing a trade certification. High-paying, constantly in demand, with a realistic path to life-changing wealth through the prosaic step-by-step building of something your community actually needs. Not winner-take-most. Not moat-digging. Just: find a real need, serve it well, grow carefully.

Most normal businesses don’t obsess over moats because their relationship with customers isn’t built on delight-then-trap. People have to eat. If you make good pizza, enough of them will come back. That’s may not be as ambitious but it’s a different and arguably healthier conception of what a business is for. The internet-era SaaS model convinced a generation of founders that anything less than a natural monopoly wasn’t worth building. The next era may make more of them happier, even if none become wildly rich as a result.

Here are 12 example screenshots. Keep in mind that every one of these is a fully functional application, not just a “design".

I posted a number of these on LinkedIn just to celebrate a weird proof of a 99% reduction in the cost of software creation: to elevate a tell-tale that our world is changing.

Everything is changing… but what does it mean?

This article is a longer form answer to the underlying question: what does it mean when the cost to make enterprise software falls by 99%? This is a harder question than it appears. The history of technology suggests that when something drops in cost by 99%, the first-order effect is the least interesting thing that happens.

Historical Price Cuts

Books

In the 14th century, a single hand-copied book cost as much as a house. Monks in scriptoriums would spend months, sometimes a year, producing a single manuscript. Knowledge was not merely expensive; it was structurally inaccessible. The largest library in Europe in 1300 — the University of Paris — held 300 manuscripts total.

Gutenberg’s press changed the price of a book by a factor of roughly 340. By the 1490s, a printed copy of Cicero cost a month’s salary for a schoolteacher. What followed was not, primarily, a story about cheaper books. It was the Protestant Reformation. The Scientific Revolution. The collapse of the Church’s monopoly on the interpretation of ideas. The birth of modern democracy. Cities that adopted the printing press grew 60 percentage points faster than comparable cities that did not, over the following century.

Nobody in 1450 predicted any of that. They predicted cheaper book copying.

Shipping

Before containerization, hand-loading a ship cost $5.86 per ton. Malcolm McLean’s standardized container dropped that to $0.16 per ton — a 97% reduction. What followed was not, primarily, cheaper shipping. It was the restructuring of global manufacturing, the rise of south east asia as an industrial power, supply chains that span a dozen countries for a single product, and a geopolitical order that would have been unrecognizable to anyone reasoning from first principles in 1955.

Genomics

In 2000, sequencing a human genome cost $3 billion. Today it costs under $200. What followed was not cheaper versions of the same research. It was research that was literally impossible before: personalized medicine, consumer genetic testing, the design of COVID vaccines in days rather than years.

A 99% cost collapse does not produce a cheaper version of the existing world. It produces a different world, organized around different assumptions, with different winners and losers, and populated by industries and possibilities that were not imaginable from the prior vantage point.

Enterprise software is next.

Where this leads

The interesting question — the one that will determine which organizations thrive in the next decade — is what a 99% reduction in software creation cost actually implies for the world. I want to offer four possibilities. They are not mutually exclusive. History suggests all four will materialize to some degree, in ways and combinations we cannot fully anticipate.

I. Mass Customization

Software today is built for the median customer. This is not a failure of imagination on the part of software vendors; it is a rational response to unit economics. When a product costs millions of dollars to build and must be sold to hundreds of customers to recover that cost, you build for the center of the distribution. You build what the largest number of customers can use. Edge cases are resisted. Workflows are approximated. Organizations reshape themselves to fit the software rather than the reverse.

This is the pre-Gutenberg condition. Before the press, you got whatever the monastery chose to copy. After it, you got niche texts for niche audiences — herbalists, merchants, astronomers, reformers — because the economics of production no longer required mass appeal to justify existence.

At 99% lower creation cost, the economics of software customization invert. The question shifts from “can we make an ROI for your specific workflow?” to “why would we build it any other way?” Every organization’s idiosyncratic processes, edge cases, and differentiators become candidates for software that fits them precisely, rather than approximately.

The implications for enterprise software vendors are significant and uncomfortable. A product that charges $40,000 per month for a functionally simple workflow tool — one that any competent team could now replicate in weeks — is exposed in a way it was not before. As a case in point: Klarna has already cancelled its Salesforce and Workday contracts, replacing both with internally built AI tools. This is not an isolated case. It is the early signal of a structural shift in the build-versus-buy calculus that has governed enterprise IT for thirty years. In other words, I expecta. reversal in the following chart in the years to come:

II. Software for the Previously Unserved

Solar photovoltaic energy dropped in cost by 99% between 1980 and 2020. The first-order effect was cheaper electricity for existing electricity users. The second-order effect was electricity for the 800 million people who had none — people for whom the prior cost structure meant that power plants simply did not exist as a practical option.

Software has its own version of this population. It is not small.

The small law firm running on spreadsheets and institutional memory. The rural hospital whose IT budget cannot support a modern EHR implementation. The NGO coordinating disaster relief across three continents with email and WhatsApp. The family-owned manufacturer whose production scheduling lives in the plant manager’s head. The local government agency whose permitting process is a stack of paper forms.

These are not underserved customers of existing enterprise software. They are non-customers. The prior cost structure excluded them entirely — not because the software wouldn’t have been valuable, but because the economics of building and deploying it never worked at their scale or budget.

At 99% lower creation cost, that exclusion dissolves. Software reaches domains and organizations that have never had it, solving problems that have never been addressed at scale, in ways that will look obvious in retrospect and are nearly invisible from here.

III. The Experimental Surplus

There is a subtler implication that I find interesting.

When something costs 99% less, you do not simply buy the same amount more cheaply. You experiment. The genome sequencing collapse did not produce cheaper versions of existing research programs. It produced research questions that nobody had previously thought worth asking, because the cost of asking them was prohibitive. The answer to “what happens when you can sequence a thousand genomes instead of one?” turned out to be: you discover things you could not have discovered any other way.

Software organizations today run a small number of large bets. The cost and time required to build software means that ideas must clear a high bar before they receive resources. Most ideas — including many good ones — never get built. The ones that do are the ones that survived a gauntlet of prioritization, estimation, and committee approval. The resulting software is, almost by definition, the software that looked safe enough to build. It is rarely surprising. It is rarely beautiful. It is optimized for justifiability, not for elegance.

At 99% lower cost, the calculus changes. You run 100 experiments where you ran one. Most fail. But the ones that succeed are not the ones that looked safe from the outside — they are the ones that turned out to be right. The resulting software, selected by what actually works rather than what was easy to approve, will be less vanilla and more genuinely surprising than anything produced by the prior process.

This is not a small thing. The history of technology suggests that the most important innovations are rarely the ones that were planned. They are the ones that became possible to attempt.

IV. The Commodity Horizon

The most radical possibility — and the one that requires the most careful handling — is that software itself becomes a commodity in a way we can barely conceptualize from our current position.

Clean water is an instructive analogy, though an imperfect one. There was a time when clean water was unavailable to the wealthiest people in most locations. The infrastructure required to deliver it reliably was simply beyond reach. Today, in the developed world, clean water is a utility: essentially free at the point of use, invisible, expected. We do not think about it. We do not pay meaningfully for it. We build our lives on the assumption of its presence. The same is true for sewage, and trash collection, and fire fighting, and a dozen basic services that most societies in history could never offer but are now ubiquitous and cheap.

The question is not whether software will commoditize — some of it already has, and the trend will accelerate. The question is which layer commoditizes, and what remains differentiated.

The water analogy is clarifying here. Water infrastructure became a commodity. What you do with water — beverages, agriculture, manufacturing, medicine — did not. The commodity layer enabled an enormous diversity of differentiated activity above it. The same structure is likely to emerge in software.

This has a direct implication for where organizational value lives. If the cost of producing code approaches zero, then code itself is not the asset. The asset is the judgment about what to build: the domain understanding, the insight into what the customer actually needs, the taste to recognize elegant solutions from mediocre ones. These things do not get cheaper when code gets cheaper. They become more valuable, because they are the scarce input into a production process that has otherwise been automated.

The Uncomfortable Part

Every 99% cost collapse in history has redistributed power, and not all of it has gone where the optimists predicted. There is also no law of conservation of profitability that says when software gets cheaper to make that software companies can keep being profitable in aggregate. Maybe this wipes out software as a profitable business sector.

Containerization created enormous wealth and also hollowed out port cities, eliminated longshoreman jobs by the hundreds of thousands, and contributed to the deindustrialization of regions that had organized their economies around manufacturing. The printing press enabled the Reformation and also enabled propaganda, the mass production of misinformation, and religious wars that killed millions. Cheap solar energy is restructuring geopolitics in ways that are still unfolding, and not all of the restructuring is benign.

Cheap software will redistribute power too. Some of that redistribution will be straightforwardly good: organizations that were previously excluded from the benefits of software will gain access. Some of it will be disruptive in ways that are harder to celebrate: software vendors whose products are no longer defensible, IT organizations whose value proposition was managing complexity that is now automated, developers whose skills were in producing code that AI now produces faster and more cheaply.

I am not raising this to be pessimistic. I am raising it because the organizations that navigate this transition well will be the ones that reason clearly about it — including the uncomfortable parts — rather than the ones that focus only on the upside.

Surviving the transition

The organizations that will thrive in the next decade are not the ones that use AI to simply produce the same software but with less staff. The staff reductions are real (as the following chart shows) as a first-order effect, but it is the least interesting thing that will happen. And if its all you can imagine to do with a 99% cost reduction, then you're not really particpating in the future of enterprise software.

The organizations that will thrive are the ones that ask a different question: what would we do if software were essentially free to build, and then go do that?

The printing press did not primarily make existing readers better served. It created readers who had never existed. The shipping container did not primarily make existing trade cheaper. It made trade possible that had never been attempted. Cheap genome sequencing did not primarily make existing research faster. It made researchers out of people who had never been researchers.

The 99% cost reduction in software creation is not an optimization. It is a phase change. The organizations that treat it as the former will be outcompeted by the ones that understand it as the latter.

We are, I think, very early in understanding what this means. The monks in the scriptoriums of 1450 did not predict the Reformation. I am not going to pretend I can predict the full shape of what follows from here. But I am confident of one thing: the question worth asking is not “by how much could we reduce our headcount while making the same software” It is “what becomes possible now that wasn’t before, and are we the ones building it?”

Content of Interview

1. Generative AI, Intelligence, and the Abstract Nature of Code

• The previous generation of AI (symbolic AI/data science) struggled with anything that couldn’t be structured and specified, requiring years of effort to formulate structured representations of a domain.

• The common argument that LLMs are merely “coherence machines” (predicting the next token) and not truly thinking is dismissed as intellectually dishonest and motivated reasoning.

• AI is now at equivalence or better than the median human in the vast majority of useful ways that the mind operates, including IQ tests, abstract reasoning, expertise tests, and discerning emotional cues in transcripts.

• We should accept that foundation models display “humanlike intelligence or human equivalent intelligence or more and kind of move on”.

• While past software abstractions maintained determinism, Gen AI’s abstraction is non-deterministic; it works by giving agents goals and guardrails rather than step-by-step instructions.
  

2. The Three Fundamental Challenges in Software Development

Generative AI relaxes three key challenges (identified decades ago in Mythical Man-Month) faced by software development.

• Accidental Complexity of Coding: Gen AI relaxes this accidental challenge by enabling natural language programming, moving away from programming languages as highly specified formats to communicate with machines.

• Coordination Overheads with Large Teams: This accidental challenge is relaxed by Gen AI by reducing the team sizes needed for large projects, potentially converging to teams of one or two. The issue with large teams is the lossy communication of ideas, which creates subtle semantic bugs.

• The Essential Difficulty of Forming Good Product Opinions: This essential challenge (software as the embodiment of ideas that are often flawed) is helped by AI, which identifies gaps and refines the core idea.
  

3. AI Primitives (Building Blocks) and Tool Use

• Primitives are the “atoms or the building blocks” from which larger AI-enabled things are built, similar to application layers in the internet age.

• Three clear primitives in the AI age are: Memory (maintaining stateful awareness of past interactions), Tool Use (using external resources beyond internal knowledge), and Persona (maintaining consistency to present as a whole entity).

• Skills are also important and defined as implicit or embodied expertise that a human can teach but the AI cannot do yet.

• Transferring skills involves a multi-step scaffolding process: description, human demonstration, AI self-assessment/correction, generation of fake test cases, attempt to complete cases, and finally, third-party approval for safety.

• The prediction is that machine vision will get strong enough (before March 2027) that foundation models can simply use the browser, making it the universal form factor and potentially eliminating the need for APIs/MCPs (which only exist because machines are currently “blind”).
  

4. Applied AI Strategy: Lessons and Success Cases from Trimble Transportation

• The applied AI team’s mission from2023 was to focus on making “AI as colleagues” to replace whole roles (not just tasks) and maintaining an AI safety mission.

• A key lesson was realizing the team erred by taking desirability for granted, assuming great functionality would inherently be adopted; product managers must validate desirability early.

• Success 1 (Customer Support): Used a breadth-first approach—AI was present on every ticket from day one (e.g., categorizing language) and incrementally increased its autonomous actions (e.g., full resolution). This resulted in faster closure and higher C-sat scores.

• Success 2 (Unsupervised Coding): Used a depth-first approach—full autonomy on a small scope (new feature development, only in Python) then progressively adding complexity (bug fixing) and languages. Success was measured against human-written code using DORA metrics (e.g., low revert rates).

• Failure 1 (General Helper Agent): The horizontal tool was too general; it “skipped the step of having an anchor customer/department” who loved the product, leading to lackluster adoption and low usage intensity.
  

5. The Shifting Role of Engineers and Autonomy in Coding

• Unsupervised coding implies that engineers are shifting from individual contributors to “AI bosses,” managing multiple concurrent agents due to the latency of AI code generation (an hour or two per task).

• The future role is envisioned as a “player coach” model: delegating 80% of “toil” work to parallel agents, while spending the remaining time in creative, real-time collaboration on the difficult 20% of tasks.

• Autonomy approval follows two paths (breadth-first or depth-first) and is built on reliability; self-healing software will be allowed when human intervention becomes rare (e.g., 1 in 1,000 tickets) and catastrophic failure risk is minimal.

• The prediction is that within three years, no human beings will be reviewing “code”.

• Junior staff adapt faster because they don’t have to overcome ego; they are “delightfully surprised” when AI works on a task they can’t do, whereas senior experts are often “watching for the mistakes” to prove the AI isn’t as good as them.
  

6. The New Role of Product Managers: Visionaries and Crafts People

• The product manager archetype of the Coordinator/Project Manager is the “false arch type” and is immune to replacement.

• Market Visionaries survive by producing contrarian but correct opinions and insights, as AI only produces superb mainstream analysis and cannot generate novel perspectives.

• Crafts People survive by having access to a “real human experience” and possessing “taste”—the ability to notice and articulate how a product feels to use, which AI cannot yet replicate.

• Software is “thought stuff,” an idea embodied into a manipulable product, and every part of its design is a choice and an expression of a creator’s opinion.

• The ability to use AI to build large products with solo/duo/trio teams will accelerate a trend against “enshittification” because the software will have a distinctive personality, uncompromised by the “medium sensibilities” of a large consensus-driven committee.
  

7. Organizational Design for the AI Age (Single-Threaded Owner Structure)

• The organization restructured to a Single-Threaded Owner (STO) Structure where all roles for a mission report to one leader (e.g., engineer, designer, PM).

• This concentrates responsibility and autonomy to the middle of the organization (second-line managers/Senior Managers), who are seen as the “centurions” where strategy and execution must be strongest.

• The STO model is based on Conway’s Law, prioritizing coherence at the product level (a cohesive product) rather than the functional level (consistent design across all products).

• The structure enforces “exclusivity,” fixing resource contention up front for long periods rather than managers fighting for resources task-by-task.

• A downside is that this requires maturity of decision-making typically expected of VPs to take place at the second-line manager level, leading to high attrition but producing “amazing” leaders.
  

8. Evaluating Agentic Services (ROI and Safety)

• The ROI for agentic services is “almost entirely labor replacement,” since Gen AI has human common sense, works in natural language, and can operate software (the tool) instead of just being the tool.

• A crucial, often-missed element in evaluation is AI Safety.

• AI can go wrong in “incredibly damaging ways” that are worse than the worst hacking event (like a “mini nuclear bomb”). Buyers should inspect a vendor’s AI safety investment, certifications, staffing levels, and capabilities.

• Another key consideration is the Longevity of the Business.

• Buyers must assess the “blast radius” against their own business if the third-party vendor goes out of business, gets acquired, or pivots away from supporting the product.

Technology Doesn’t Lift All Boats Equally

We tend to imagine technological progress as productivity pixie dust that makes all people more efficient (for example, that the internet made basically all knowledge work a bit better). Economists call this “total factor productivity”. But it is not quite how automation actually works.

Automation targets discrete tasks. It does not care how much human skill, training, or sacrifice was required to perform them. When a toll booth operator is replaced by a transponder and credit card billing system we accept it without much moral hand-wringing because the skill threshold was low and the social disruption, while real for the individual, is legible as progress.

But when the task being automated is a high-skill one, something different happens. The reaction is not acceptance. It is resistance, and the resistance has a logic to it. When a radiologist’s ability to read a CAT scan, or a lawyer’s ability to synthesize case law, or a software architect’s ability to design a system is automated, it does not just change a workflow. It diminishes a form of human specialness that took years to cultivate. It disrupts social power structures. People who were elite because of what they could do find that the thing they could do is no longer the scarce resource it once was. This is not a failure of progress, but it is a cost of progress that we rarely account for honestly, especially inside organizations.

The Career Timing Problem

Here is where it gets personal. Deep expertise is not built quickly. It is the product of years, sometimes decades, of deliberate practice in a narrowing domain. A senior engineer who truly understands distributed systems, a product manager who has shipped ten products and internalized why nine of them failed, a designer who has developed genuine taste through thousands of iterations: these people are valuable precisely because their knowledge cannot be faked or shortcut. Except now, in a narrow but important sense, it can be.

AI automation does not require you to be able to do a task yourself. It requires you to be able to oversee it. To prompt well, to evaluate outputs, to know when the machine is confidently wrong. These are skills of breadth, not depth. They reward people who are curious across domains, who have not yet committed their identity to mastery of one thing, who are still in the phase of their career where they are accumulating surface area rather than drilling down. That description fits junior and mid-career professionals far better than it fits senior ones.

This is the career timing problem. The rules changed mid-game for a vast number of workers. People who made rational investments in deep expertise, following the incentives that existed at the time, now find that the market is beginning to reward a different kind of portfolio. And the cruelest part is that the people most affected are not the ones who made bad bets. They made the right bets, including personal sacrafices for them. But the game just changed.

What Leadership Is Actually For

Any organisation is perpetually in transit between a past that forms its memory and a vision of the future that inspires its efforts. Leadership is a neccessary ingredient to cohere in our beliefs of the past, and to settle our goals of the future. In a present dominated by intruding demands, born of chaotic circumstances, leaders must find a future for their organisation that they have never experienced and may hardly imagine. That is not a ceremonial function. In the current moment, it has immense moral importance.

Without deliberate leadership, organizations navigating AI-driven change tend to default to a damaging pattern. Senior staff, who carry the most internal social capital, shape the pace and form of technology adoption. This is natural but dangerous. Those same senior voices are the ones whose deep expertise is most directly in the crosshairs of automation. The risk is not that senior staff are malicious, just that they are human. Faced with the random devaluation of skills they spent careers building, cynicism is a rational response. Their reaction is one of preserving equilibrium. And though it may not block long-term progress, that does not harness external momentum or supply its own. To listen only to senior staff would be stable but inadequate to providing a vital future for the whole organisation. But also to ignore these voices entirely risks a culture that reduces the individual to an object, a resource. No future vision can be so compelling that great people want to be reduced in this way.

So, a leader’s job in this environment is twofold. First, to meet senior cynicism with compassion while refusing to let it set the agenda. The goal is not to dismiss the experience of senior people. Their depth still matters. There are things they understand that no AI can replicate: judgment under ambiguity, the institutional memory of what has been tried and failed, the ability to ask the right question rather than answer the wrong one well. The task is to find what remains genuinely exclusive about their expertise and build around it, rather than ritualising the parts that are already gone.

The second job is more important, and it is one that organizations rarely do well. It is to create the conditions for younger team members to flourish, not waiting their turn as apprentices under the small deceptions of conformity, but as full contributors whose different relationship to technology is a genuine organizational asset. The traditional model of career progression, in which junior people defer to senior people and earn influence slowly through demonstrated depth, is untuned for this moment. The people who are most naturally fluent in the new tools, most comfortable with breadth over depth, most willing to experiment without the weight of sunk-cost expertise, are often the least empowered to act on those advantages. A leader must change this. It requires actively creating space, redistributing voice, and being willing to let the organizational hierarchy bend in service of the work rather than the other way around.

As I reflected on various acts of leadership, this moment feels like one of the most demanding precisely because it requires the character to act against the advice of many senior experts in one's own organisation. Such decisions are unpopular, but specifically unpopular with the most trusted and empowered people in a company. One cannot ignore feedback from true experts routinely, but neither can one caucus them as the sole means to find a future path. The price to pay in leadership is unceasing self-critique, the constant taking of risks, and a perpetual inner struggle.

In Conclusion

The three ideas at the heart of this article are not separate problems. They are one problem seen from three angles.

Technology automates tasks, not people, but the human cost falls unevenly on those whose identity and status are built on the tasks being automated. The career structures we built to reward depth are now in tension with a world that increasingly needs & rewards breadth. Leadership is a key mechanism for navigating that tension. Leadership avoids the loss of the wisdom of experience while harvesting benefits that comes out of liberation of individual creativity and energies.

The organizations that get this right are not the ones that adopt AI fastest. They will be the ones that hold their people together through the transition: honoring what senior expertise still offers, unleashing what junior talent can now do, and building a shared story about where they are going that is honest about the cost and genuine about the possibility.

As of April 2026, everyone is trying to find their way through a software development lifecycle transformed via AI. Ideation, design, code planning, code creation, code sense-making & review, test case writing & execution, release-note writing, bug triaging, and 1st line customer support are all deeply automated in their core tasks via Generative AI under appropriate harnesses. Leaders of larger organisations therefore ask themselves questions like:

1. Is my organisation as mature in our AI use as others?

2. Do we have the right talent for this AI age, and supposing not, what should we do about that?

3. How should organisational designs be changed to best leverage these new realities?

These questions compound upon other questions a leader must contend with:

4. What are the right customer problems to focus on in this new AI age?

5. Down what paths to find durable moats for competitive differentiation?

While each of these questions has import for the business, I suspect the organisational design is least addressed. The external questions of where to play and how to win are enticing, and the internal questions of maturity benchmarking and even talent are worrying. The org design question is easy to postpone. It seemingly should come after one has answered the others, and it carries significant change management penalties with nebulous benefits.

But org design is a perfect example of how a leader must handle a series of practical problems that intrude, and which circumstances generate, while also creating a vision and path out of rising circumstance. Many smart people will find paths on how to use AI, what talent changes are needed, and how to adapt business strategy. Virtually no one will redesign a large organisation for the leader: their diagnosis, motivating vision, and character to see it through are needed to take an organisation from where it is today to where it has never been.

Still Single Threading

In my contemplations and experiments on this subject, one conclusion is that Single Threading of product & engineering teams is also valid in the AI age. In fact, it seems to be reinforced in its fundemental trade-off of focus & speed over aligment.

I’ve realised the Single Threading informs me of the overall topology of the organisation. It tells me that as low as possible in the org chart there should be a single person, what we call the Single Threaded Owner, who has reporting to them substantially all of the staff needed for a product line. If this number of staff is too large for a single manager, the sub-teams should be as isolated as possible. That means finding a fracture plane to split the group in which they can go as long as possible without needing to meet, jointly plan, etc.

The topology also matters above the Single Threaded Owner. For example, in my organisation of 1,200 people, a whole product line reports to the single threaded owner. But multiple single threaded owners report to a senior manager, who then report a product domain owner, who then report onwards to me. The distance in management nodes between any two single threaded owners tells you also how aligned their products must be: again, the org chart is a first pass on architecture. We do not group teams by their career specialisation (designers report to design managers, etc) nor according to their tech stack (the Typescript applications together, etc). We group them and form upward management topology to preempt the architectural and product strategy alignments needed, since the upper manager role is in part to watch for and nudge to such outcomes. In practice, upper managers are not singlke threaded owners: they are system creators. They own such as culture (what we do, what we reward or publish), resource allocation, and are the goal & performance oversight mechanism for the single threaded leaders. Overall, single threading is a “power to the middle” model that is mightily good at absorbing generative AI into the production process.

AI is Changing the Team Composition

What I realised is that single threading tells us about the macro view on an organisation, the view in which each team is seen as a node in a graph. Now, AI is changing how the team node is defined. I’ll list the key changes and then go into much greater detail on each.

1. Team’s are shifting towards generalist rather than a collection of specialists

2. The ideal team size is falling, probably to a trio (3 people)

Unlike the Single Threading article, my thoughts here are not proven at large scale. So, I’ll state them as hypotheses or claims and therefore signal they could be refuted as more experience accumulates. And this is a good place to say that a lot of what I have learned and am writing about here came from writing and discussions with two collleuges: Märten Veskimäe and Suraj Varier.

Claim #1: Compose Teams of Generalists, Not Specialists

Handover Cost Outweighs Specialisation Quality

Product creation teams are formed of distinct specialists: database engineers, network engineers, infrastructure engineers, reliability engineers, designers, product managers, product owners, QA, etc. Prior to AI, in the past decade this had ossified into known ratios: one product manager to one designer to two front-end engineers to three backend engineers. The ratio worked because the rate at which each specialist could translate inputs into outputs avoided massive queuing delays on the others. If you had five product managers and two engineers, the PMs would make story after story and the backlog grew each week instead of cleared. A significant realisation here is that all the other roles who weren’t writing code in the past were basically existing to organise and prioritise and transfer ideas to engineers because only the engineer could write code and only the written code changed the software.

But if we look back further, over a time period of perhaps 30 years, we see we have been on a path in which the trade-off between “specialization of labor” and “coordination between specialists” has been steadily eroding specialists advantage. Specialisation of labor means coordination between specialists is needed to accomplish an overall goal. The rise of roles like full stack developer happened because (a) the specialist domains of backend and frontend got enough supporting tooling that a newbie or mediocre engineer could handle them, and (b) the balance of quality of outcome vs delay or costs of trade-off tipped in favour of expediency.

The changes from AI mean the hand-over and alignment costs overweigh nearly all specialized labor benefits. As a real example, consider pricing strategy. This is a place where product managers would previously had read many books, attended training courses, listened to podcasts that gave case histories, and cultivated a network of people they trust for tips. That takes years and it makes a senior PM much more effective than an engineer, designer, QA tester, etc, when a pricing strategy task comes along. Its exactly why we have specialized labor: the PM makes better strategy decisions and also does so faster. Or, they did until a few months ago. Now, we see that this very valuable and very hard-won expertise is inferior to a discussion with Gemini. Instead of stopping and handing over the pricing strategy question to a PM, an engineer or designer can just use Gemini and arrive at superior results without coordination with another person. All the person needs is a willingness and interest to use AI in this way, and these are what we refer to as generalism.

The previous example explained how non-PMs can use AI to do PM work. But the same is true for non-engineers doing engineering work. As code abstracts away from being written by hand, the role of both non-engineers and engineers is redefined.

Specialists Increase Coordination Costs

Specialists create handoffs, but handoffs are lossy. No piece of knowledge work is ever handed off intact so easily. It either is subject to a reinterpretation or has to be energetically protected from such changes. Handoffs happen precisely because the first person cannot do what the second person does, and therefore they require translation. Translation creates delay, misunderstanding, local optimization, and role-based non-responsibility. Once work is split across multiple people with strong specialist boundaries, the organization must spend more energy aligning intent, clarifying ownership, and resolving ambiguity.

For a long time, that trade-off was still favorable. The engineer’s ability to write production software was so distinct, and so scarce, that the cost of coordinating around engineering was acceptable.

AI weakens that logic. If product reasoning, design exploration, and code creation can all be materially accelerated by AI, then the relative value of narrow specialization falls while the relative cost of aligning specialists rises.

Non-Routine Work Prefers Generalists

One of the strongest theoretical bases for this shift towards generalists comes from task-based models of technological change. The central insight is that technology does not replace whole jobs in one step, nor does it just make “people faster” like productivity pixie dust. Technology substitutes for particular tasks, regardless of the skill level of the people who previously did the task.

The task framework predicts that AI automation occurs mostly on routine tasks — well-defined, codifiable, repetitive — whether performed by high-skilled or low-skilled workers. What remains for human labor are non-routine cognitive tasks (abstract problem-solving, judgment, creativity) and non-routine interpersonal tasks (negotiation, motivation, persuasion).

Boilerplate code, first-pass wireframes, documentation, requirements synthesis, summarization, and routine analysis are increasingly handled by AI. What remains most valuable for humans is less the repetitive execution layer and more the non-routine judgment layer.

Once technology automates more of the specialist execution, the remaining high-value work clusters at the intersection of the disciplines. These residual non-routine tasks are, by nature, closely related to one another — which is precisely why converging them into a single generalist role is desirable.

Generalists Leverage Good Enought to Reach

On many dimensions, such as quality or scalability or desirability, there will be a learning loop as a product iteratively tries and adjusts. And in each of these dimensions there is a point that is neccessary to succeed,and later a point of diminishing returns to further experimentation. Generalists acting as an AI boss are best positioned to make trade-offs on these dimensions because their career itself is not a commitment to maximizing one aspect of product creation. For example, a team who chooses to have 1 of their 7 staff be a designer has pre-emptively committed itself that 1/7th of their investments will be in the dimension of design. But any such commitment should be reconsidered after each iteration, and using specialist labor makes this essentially impossible.

Generalists are better suited to shifting focus with each learning loop. They are a self-contained Lean Startup learning loop: best positioned to act upon signal wherever it may need to be integrated. That person can define intent, prompt and direct AI, inspect outputs critically, make taste-based decisions, and ship. Again and again. They do not need to be the world’s best in every domain, and perhaps being just okay at all of them makes them more willing to settle for good enough when the time of diminsihing returns is reached. Under older conditions, such a person was exceptional but not structurally necessary. Under AI conditions, that person starts to look like the ideal building block of the organization.

Claim #2: Make Teams of Three People

If generalists are the ideal role for teams, how many should be grouped together? As I said above, I think the ideal team of 5 to 10 people composed from 4 to 5 specialisations is a relic of the pre-AI era. But what should replace it?

I’ve always said that an ideal team is a team of one person. They are limited only by their intellect and energies. But for a product to endure long at all it must be sustained by more than a solo creator, however dedicated they are. In considering this question, I decided for myself that a trio is ideal. The trio matters because it seems to sit at a uniquely useful point in the trade-off between autonomy, resilience, and coordination.

A trio is the smallest unit with internal governance

A solo operator is fast, but fragile. There is no built-in challenge function. No one is there to catch poor judgment, counterbalance overconfidence, or absorb absence.

A pair improves on this, but introduces the risk of deadlock. Two people can disagree without resolution. They can also become overly dependent on one another’s habits and blind spots.

A trio is the first group size that creates a stable internal governance mechanism. One person can propose, another can challenge, and a third can integrate. Conflict can be mediated without immediate escalation. Judgment can be improved without requiring formal hierarchy.

That matters enormously in AI-native work, where teams are increasingly supervising high-output systems and choosing among many plausible options rather than manually executing one obvious path.

A trio maximizes perspective diversity before coordination costs explode

Three people can still hold the whole problem in their heads together. They can remain in one conversation. They can sustain high mutual awareness about product intent, technical trade-offs, and workflow decisions.

After three, coordination costs start climbing quickly. Relationship paths multiply. Role clarity has to be made explicit. Meetings start to substitute for shared context. More effort goes into synchronization, less into creation.

So the trio is significant not because three is magically perfect in every circumstance, but because it may be the smallest unit that gives you real diversity of viewpoint while still preserving the intimacy and speed of a tightly aligned team.

A trio is resilient without becoming bureaucratic

Very small teams are attractive because accountability is visible. Everyone knows who is carrying what. But very small teams can also be brittle.

A trio balances these forces. One person’s absence does not collapse the unit. One person’s weakness does not have to define the team’s ceiling. One interpersonal tension does not necessarily freeze progress.

At the same time, the team is still small enough that no one can hide behind process, titles, or the diffusion of responsibility common in larger groups.

A trio composes cleanly into a larger organization

If the organization is built from self-managing units, those units should be easy to reason about. A trio is small enough to be legible.

A leader overseeing several trios can think in terms of mission, ownership, throughput, and interface quality rather than the team’s internal role choreography. This makes it easier to scale a flatter organization. Instead of managing many specialists inside a large team, leadership can manage a portfolio of small, coherent units with clear boundaries and stronger local autonomy.

In that sense, trios are not just a people decision. They are an organizational primitive.

Generalists and trios reinforce each other

These two ideas belong together.

A trio of narrow specialists often reproduces the old model in miniature: one person owns product, one owns design, one owns engineering. That can still work, but it preserves the same coordination logic the new system is trying to escape.

A trio of generalists is different. Each person can contribute across the full loop. Work can be divided pragmatically. One person may lead a given initiative, but the others can still meaningfully challenge the PRD, review the code, assess the user experience, and help direct AI.

That is what creates the real advantage. The trio is not merely smaller; it is more integrated. The generalist is not merely broader; they are more responsible inside a tiny autonomous team.

This also changes the meaning of collaboration. Instead of collaboration being primarily a handoff between functions, it becomes mutual adjustment between peers who share responsibility for outcomes.

Caution: This is not an argument against expertise

None of this means expertise stops mattering. Specialist knowledge remains real and important. Some domains will continue to require deep expertise. Some product contexts are complex enough, regulated enough, or risky enough that specialist roles will persist much longer. And even in a generalist organization, some individuals will still have natural strengths or deeper backgrounds in one area.

The point is not that specialization disappears. It is that specialization becomes less suitable as the default organizing principle. The center of gravity moves from role purity to whole mission comprehension.

The organization should still value deep expertise, but increasingly as something that is embedded inside generalist teams, shared across them, or concentrated in principal-level roles rather than used to define the structure of every ordinary product team.

Onemodel I think may gain ground is to have truly deep specialists as a bench of advisers or coaches who can be called upon during open hours etc by the trios.

Managerial implication: lead systems, not handoffs

If teams become smaller, more generalist, and more autonomous, management must change too The old specialist team required significant coordination management: resolving handoffs, setting priorities across roles, and translating between disciplines. In a trio-based generalist model, much of that work should disappear or at least shrink.

That does not make management irrelevant. It changes the job. Leaders become less responsible for directing the internal mechanics of each team’s work and more responsible for shaping the broader system: team interfaces, standards, talent quality, AI tooling, risk controls, and the conditions for good judgment at scale.

In other words, management shifts from supervising role execution to designing an environment in which small autonomous teams can perform well. In somesense, this feels like a shift upwards for management. It is closer to how senior leaders work in the Single Threading model, where they set culture and allocate resources and performance manage against goals. Now, this may be happening at level 1 or 2 of management.

The broader claim

The deepest reason to prefer trios of generalists is that AI is changing the economics of coordination and specialized labour. As mentioned above, if we agree that AI automates tasks regardless of the skill level needed by people who previously did the task, we should expect AI removes much of the value of specialization. That value always came with a cost (coordination), which will remain so long as specialists remain. The logical conclusion is to seek less epecialisation, and since velocity allows it, to also reduce team size to this powerful innate number of three.

The trio is compelling because it is the smallest durable team. The generalist is compelling because they are the most coherent worker for an AI-assisted production system.

Taken together, they point toward a different model of product and engineering: fewer handoffs, fewer role silos, more autonomy, more accountability, and a tighter connection between idea, judgment, and shipped reality.

That may not be the final form of the software organization. But it is increasingly a rational form for the stage we are entering now.

In a growing business,most leaders will hire more staff, add coordination layers, and spin up cross-functional structures to keep everyone aligned. Starting in 2021, I began leading progressively larger teams, growing from 10 people to 1,250. A lot of the successes I had can be attributed to a novel model for organising product and engineering teams called Single-Threaded Ownership (STO). The roots of this came from Amazon (such as reading Working Backwards),and Team Topologies. But within Transporeon and later Trimble Transportation it evolved and developed depth and nuances not seen in that reading. The core idea is deceptively simple: give a small, cross-discipinary team exclusive ownership of a business outcome under minimum the frame conditions & interuptions.

What follows is not a how-to guide but a theoretical argument. Why does single-threading work? The answer lies at the intersection of several well-established bodies of thought — from economics and queueing theory to cognitive science and software architecture.

What is Single Threading?

First, the definitions. Single threading refers to creating teams and workload across them in a way that they maximise two forms of focus:

1. The team is solely focused on the completion of its goals, i.e. no other work can impose upon them.

2. The team includes everyone who has the goal, i.e. they will not depend or impose their goal completion on others.

Three elements will force teams to interact with other teams: knowledge, steps in a task, and resource sharing. The more we create teams that lack knowledge necessary to their success, must go through multi-team steps of tasks, or queue for resources, the more we must be ready for high loads of interaction.

For product teams, Single Threading means that a 1st line manager (the single threaded owner) will have a team of up to 12 people who combined all specialist knowledge needed to create & maintain the product line: designers, product managers, backend engineers, front-end engineers, etc. This group has no matrix responsibilities or reporting lines outside the product line, and no oneelse works on the product line. They are alone, and meet rarely if ever with other sister teams.

When team-spanning interaction is impossible to avoid, such as for leveraging a thin platform for its services, the next best thing is to have a rock-solid definition of the target interaction. Does my team give yours workload, or the other way around? Do we have joint goals? Is this interaction temporary or permanent? Contract-like agreements about how internal teams should interact is crucial.

What Is Org Design Actually For?

When choosing an organising model, it helps to be clear about what org design is supposed to achieve. I think about three goals:

1. Effectiveness — ensuring enough effort is applied to the right business outcomes.

2. Labor Productivity — maximising the output per unit of labour input.

3. Architectural design — because how you group people is, whether you like it or not, the first draft of your system architecture.

These goals are in tension. Effectiveness tempts you to throw more people at a problem. Productivity tells you that more people will slow you down. Architecture reminds you that the grouping itself has consequences far beyond the labour dynamics. A good organisational model must navigate all three simultaneously.

The Central Problem: Diseconomies of Scale

Labour hours scale linearly with headcount. But output does not, because five forces push against it:

Alignment costs grow super-linearly

The number of possible pairs of people who might need to coordinate grows quadratically. Meetings, Slack threads, and documents are tactics to slow this growth, but they can at best make coordination costs grow linearly — and in practice, they don’t even manage that.

Queueing waste multiplies invisibly

Specialisation splits work into sub-tasks handled by different people. Each handover introduces waiting. Organisations try to keep specialists busy by giving them queues, but queueing theory tells us clearly: the more local queues you create, the worse global wait times become. The result is a tapestry of invisible delays that no one can see end-to-end.

Motivation erodes

Intrinsic motivation depends on autonomy, mastery, and impact. Larger organisations can improve mastery through specialisation, but they systematically erode autonomy and the feeling of personal impact. When 10 people build a successful product, each one feels it. When 10,000 people do, no one does.

Complication breeds misunderstanding

Bigger organisations are simply harder to model accurately in your head. Even a decisive leader acting unilaterally will make worse decisions because their mental model of the system is more likely to be wrong.

Humans are wired for small groups

We evolved to trust, collaborate, and communicate effectively in groups of roughly 5–15. Larger structures degrade the quality of social interaction — trust weakens, honesty suffers, identity diffuses.

Any organisational model worth adopting must actively fight these forces.

Why Single-Threading Works

The STO model is a principled response to the forces above, grounded in several converging theoretical traditions.

Conway’s Law: Org Design Is Architecture

Melvin Conway’s famous observation — that organisations produce system designs that mirror their communication structures — implies that org design becomes system architectures. Single-threaded teams produce modular, well-bounded systems almost by default. The team boundary becomes a service boundary. The org chart becomes an architecture diagram. This is not a side effect of STO — it is one of its primary virtues.

Coordination Cost Theory: Brooks Was Right

Fred Brooks warned us in 1975: adding people to a late software project makes it later. The deeper principle is that coordination costs increase non-linearly with the number of interdependencies. Every dependency between teams is a communication channel that must be maintained, a potential source of misunderstanding, and a queue where work waits.

STO attacks this directly. The defining aspiration is **minimal dependencies**. The best meeting between two teams is no meeting. The best collaboration is no collaboration. Teams interact through explicit, contract-like interfaces — not through ad-hoc negotiation. This doesn’t eliminate coordination, but it transforms it from an ongoing negotiation into a stable protocol.

Cognitive Load Theory: Protect the Scarcest Resource

Human attention is finite, and context switching is devastatingly expensive. Research consistently shows that dividing attention across unrelated responsibilities degrades decision quality and productivity far more than people intuitively believe.

Single-threading is, at its core, a cognitive load management strategy. No one in the team is expected to multi-thread across unrelated missions. Everyone’s primary job is *one outcome*. This sounds obvious, but compare it to a matrix model where an engineer reports to an engineering manager, is assigned to a product pod, contributes to a platform initiative, and sits on a cross-functional working group. That engineer is perpetually context-switching, and none of their responsibilities gets their full attention.

Agency Theory: Align Incentives by Clarifying Ownership

When accountability is diffused across functions and teams, you get classic principal-agent problems. No one is truly responsible for the outcome, so no one’s incentives are fully aligned with it. Free-rider dynamics emerge: each function can point to the others when things go wrong.

STO collapses the accountability structure. One team — led by one owner — is responsible for a business outcome, measured in financial terms: revenue growth, cost of sale, win rate, customer ACV. Success and failure are legible. Incentives align naturally because the owner’s success is the initiative’s success.

The Human Factor: Small Groups Work Better

Finally, there’s the simple anthropological reality. Humans form effective working units in groups of 5–15. Trust is high, communication is rich, coordination is natural. STO teams are sized to fit within this range — typically 5–10 individual contributors under a manager. This isn’t a coincidence or a convenience; it’s the model deliberately working with human social instincts rather than against them.

What About the Alternatives?

It’s worth understanding why other models exist and what tradeoffs they accept.

Three-Legged Stool

This means you organise all staff into career specialties: engineering, product, design triads. This respects functional expertise and career development, but at immense coordination costs between the three legs and diffused accountability.

Matrix Pods

This means functional reporting + cross-functional pods, basically the Three-legged stool for authority and a mission team as a task assignment. It balances specialisation with product focus. But you pay a heavy penalty on chronic role ambiguity, influence without authority, and context switching.

Shape Up / Bench

This means project assignments from a talent pool. It offers flexibility & efficient allocation of scarce talent. But it gives no long-term ownership and triggers loss of context between cycles.

Platform & Delivery

This means a stable platform team + ephemeral delivery teams. It offers a clear separation of concerns for infrastructure vs. features. The downside is that delivery teams lack continuity, ROI is very difuse, and platform can become a bottleneck.

Each org design model makes a different bet on the tradeoff between specialisation, coordination cost, context switching, causal clarity between investment and outcome, and global vs. local optimisation.

STO bets aggressively on minimising coordination cost and context switching, and on maximising causal clarity — at the acknowledged expense of some resource efficiency. Your best talent can only work on one mission. Some teams will have to “round up” on staffing where a shared model would have been leaner. These are real costs. The argument is that they are easily compensated by the gains.

STO Is Not Easy

No model is without failure modes, and intellectual honesty requires naming them:

Silos

Too much autonomy can produce teams that don’t share learnings or reusable solutions. Some mechanisms for cross-pollination are needed, or one must accept this silo outcome as a tax for the other efficiencies.

Leadership scarcity

The STO model demands a specific kind of leader — someone who can manage across functional disciplines, think commercially, and operate with genuine autonomy. These people are rare. The job is also very demanding, and therefore churn in the STO role is high. The upside is that the good STOs are almost always capable of being future company leaders.

Inherent cross-cutting concerns

Some problems — security, design systems, data infrastructure — genuinely span multiple teams. STO needs a complementary model (often a thin platform layer) to handle these.

Discipline in prioritisation

Not every initiative merits a dedicated team. Organisations must be rigorous about which outcomes are important enough to warrant single-threaded investment. The STOmodel brings the contention for resources to the start of team formation rather than letting it happen task-by-task in most other models.

Conclusion: STO is Sharper & Faster

The case for single-threaded ownership is not that it’s easy or that it’s free of tradeoffs. The case is that it is the organisational model most aligned with what we know about how coordination costs scale, how human attention works, how incentives shape behaviour, how software architecture emerges, and how human groups form identity.

A Lesson in Velocity from Trimble Transportation

Changes made in 2025 brought most engineers in Trimble Transportation (where I work) to a state of Vibe Coding. With the rollout of our in-house developed engineering AI, we'll move this year to Unsupervised Coding. Vibe coding has resulted in 35% of product code committed and merged to master branches to be wholly written by AI, at a cost increase of about 1.5% to our engineering expenses. Unsupervised Coding should at least double the output, i.e. take us to >70% of code going into production being entirely written by AI (obviously still with oversight from humans). Unlike vibe coding, where market tools exist, Unsupervised Coding is something we built in-house and where the IP for how to do so seems to be unmatched by competitors (for now). This gives us a chance to contemplate its impacts prior to most of the market.

What is Unsupervised Coding?

Unsupervised Coding is characterised by the assignment of tickets or stories to AI such that the AI goes and works on it for a long period of time, commits its code into a new branch, and submits the code branch for a merge review. The AI works at the direction of an engineer who perhaps previously would have authored the code but now acts as a boss of the AI and merely assigns it work and subsequently reviews the code. Rejections are rare, AI workers can be spun up on demand, and the AI takes hours to write the code. These, together, mean the human engineer can switch tasks between parallel AI workers resulting in a significant increase in velocity. Repos and engineering staff who work in or near this manner today see nearly all code writing done by AI already, and this is a leading indicator of what to expect for all of Trimble Transportation by end of 2026.

Implications of Unsupervised Coding

The two most consequential outcomes from Unsupervised Coding are on the engineering career itself and the impact of code abundance & velocity on the software business as a whole. I’ll address each in turn.

The End of Authorship: How Unsupervised Coding Changes Engineering

Unsupervised Coding shifts engineer working time towards validating code written by AI rather than authoring code with the help of AI. The result is the weekly working hours concentrate on the pre-coding steps of agreeing what, actually, should be created, as well as verifying the resulting code does what was expected.

This shift to the before & after of code writing is a key experiential change for engineers. Code reviews may become the single biggest time investment, which leads to changes in the ergonomics of code reviews (more on that below).

We ask engineers to review AI code mostly because, as a society, removing a human from the loop is deemed unacceptably risky. The ability of humans to best identify and correct issues is debatable now, and unbelievable in the long term as further progress occurs. But they act as a moral crumple zone of a car in that failures of AI code are seen as the responsibility still of a named engineer rather than an unaccountable “system”.

Perhaps more interesting is the focus of engineers in the pre-coding phase, which shifts engineers towards the kind of decisions once reserved for the “architects” or very senior engineers in their team. This is not to say that the engineer replaces the product manager, rather that more engineers will be deciding architectural questions which then frame the unsupervised coding.

With less time spent coding, ergonomics of code writing are deprioritised. Which segues to the next topic…

Safety by Design: Why AI Prefers Rust and Go

In the AI era, the best languages are those where most incorrect programs cannot exist, and correct programs are simple. That describes Go (simple by design) and Rust (correct by force). The implication is that most engineers will want to retrain away from C++, C#, Java, Python, or Typescript towards Go or Rust.

How programming languages evolve

New languages gain adherence because they improve developer ergonomics and safety in response to concrete pain points of dominant languages. Languages rarely replace predecessors outright. They capture new domains (mobile, cloud, safety-critical, scripting) and then expand. We can expect a similar outcome with AI age applications which, in my estimation, will tend to be built in Go and Rust. The meta-pattern is:

1. A language becomes dominant for a domain

2. Scale reveals hidden costs (safety, concurrency, maintainability)

3. New language reframes tradeoffs. Ergonomics first, performance later

4. Tooling and ecosystem accelerate adoption and lock in the language.

Previous, canonical examples:

C → C++ / Objective-C

Abstraction without abandoning native performance

Failure:

• Manual memory management

• No abstraction mechanisms beyond functions/structs

• Poor large-system composability

Response:

• C++: RAII, classes, templates (zero-cost abstractions)

• Objective-C: Message passing, late binding (for UI-heavy systems)

C / C++ → Java

Predictability and safety over maximal control

Failure:

• Memory safety bugs (buffer overflows, use-after-free)

• Undefined behavior

• Painful cross-platform deployment

Response:

• Garbage collection

• Stronger type safety

• JVM “write once, run anywhere”

Java → C#

Productivity via language-tooling co-design

Failure:

• Verbosity

• Weak native/OS integration

• Slow language evolution

Response:

• Properties, events, LINQ

• First-class tooling (Visual Studio)

• Faster iteration via .NET ecosystem

Java / C# → Python / Ruby

Cognitive load reduction and flow

Failure:

• High ceremony to task ratio

• Poor scripting experience

Response:

• Minimal syntax

• Dynamic typing

• REPL-first workflows

Python / Ruby → Go

Operational simplicity at scale

Failure:

• Poor concurrency models

• Slow startup and deployment complexity

• Performance unpredictability

Response:

• Goroutines + channels

• Fast compile times

• Static binaries

C / C++ / Java → Rust

Making illegal states unrepresentable

Failure:

• Memory safety (C/C++)

• GC latency and lack of control (Java)

• Concurrency bugs

Response:

• Ownership and borrowing

• Compile-time safety guarantees

• No GC

JavaScript → TypeScript

Scalability without ecosystem fracture

Failure:

• Large-scale JS codebases fragile

• Refactoring unsafe

• Tooling limitations

Response:

• Gradual typing

• Structural types

• Zero-runtime-cost abstraction

Go and Rust are best suited for the AI age

Unsupervised Coding with AI produces large volumes of syntactically valid code, shifting human engineering time from authorship to verification (i.e. code review). The human review must address the fact that AI is good at generating plausible solutions, not necessarily correct ones.

The bottleneck on code review is therefore reasoning and trust: can the human reviewer reason their way through the code to independently confirm “what it does”, or can they trust in some other mechanism to ensure the code without doing their own reasoning?

1. On the ease of reasoning, Go is a small language of explicit logic and minimal automation. It reads quickly. Rust has compiler-enforced invariants and therefore fewer states to reason about.

2. On the ability to trust-without-verifying, languages that constrain AI output outperform those that rely on human discipline. Go constrains AI output with straightforward runtime behaviour, few abstraction, and limited ways to do things. Rust’s ownership, lifetimes, and borrowing prevent whole classes of bugs. The Rust “correctness by construction” seems perfect for probabilistic code generation. Finally, in an AI workflow the compiler is not just a build step—it’s a first reviewer. Go offers extremely clear error messages and a fast edit–compile–fix loop suitable for AI-assisted iteration. Rust’s compiler encodes deep semantic rules that in other languages would be left to disciplined human review.

Finally, the pure speed and scale of AI code generation mean that we need languages that offer operational stability, predictably low maintenance costs, and ease of context-switching (since most humans won’t see the code base beyond code reviews, i.e. they won’t build deep mental models of the code through repeated exposure). We see these qualities already in areas favoured by Go and Rust:

• Go: cloud control planes, networking, internal services

• Rust: databases, crypto, safety-critical infrastructure

AI amplifies rationales already well understood for picking Go and Rust.

The Death of “Build Once, Sell Forever”: Software Strategy in an Era of Abundance

Traditionally, software businesses (like Trimble Transportation) are anchored to the difficulty of coding in a way that is hard to overstate. Modern software companies invest a lot to make a code base and then race for maximum distribution because the incremental cost of a new customer on the same code base is vanishingly small compared to the value they can create & therefore share for the customer. It most closely resembles a media business where a piece of creative content is produced (such as a movie) and then sold over and over and over. The decoupling of the cost to create vs the cost to deliver is the seat of these two business models.

As coding becomes easier, thanks to Unsupervised Coding, the safe harbours from commoditization are shifting. I’ve written previously that cornered data, network effects, and brand are viable safe harbours for established logistics software companies. What I’d like to propose today is that the entire paradigm of software businesses could head in a new direction. I’ll propose three models that may hold clues for the future, though what emerges is likely not whole-sale foreseen by them.

Hospitality

When we say “Software as a Service” we really mean that its costs sit in operating expense instead of capital expenses. Customers buy access to our software rather than own some version of it as an asset. For the hospitality industry, the word service has a deeper and more natural meaning. Service in hospitality is about how people feel, how they have been served by other people above all. To build such businesses one creates different forms of systems and scale advantages than in software. The systems are about enabling personalisation to the customer, about creating fertile ground for bespoke moments to happen organically rather than by force. This means staff, almost all of whom are frontline, are empowered to act on their instincts and taste towards the customer. A culture of attention to detail, of taste for small gestures, compounds into a culture that values noticing and acting on all levels of experience regardless of their apparent immediate impact. Attending to quality internally, in the life of the mind, leads to curation of great experiences for customers externally.

Architecture

At first glance, the qualities of a successful architecture firm might look like those of hospitality. But the differences are telling. In architecture, we are promised bespoke outcomes, but we get there through methodologies that tailor solutions. Hospitality offers the bespoke through frameworks that prepare for but still yield maximum autonomy in the moment. Architecture centers on interaction between the customer and the architect’s team. The customer doesn’t just value the work product’s result (a design) but experiences craft elevated by creativity of a small team, even perhaps one person. Most crucially, they experience the architecture as a member of that team and therefore the resulting design is also a story of the act of creation in which they are author not consumer. This explains why architectural firms mostly don’t scale: the magic is in the client co-design sessions and these grow linear in input and outcome.

Luxury

Pivoting again from architecture, we come to luxury. Like architecture it centers on story and brand. Like hospitality it is also a services business (even if there is a good being bought), and attention to detail is paramount. Where luxury differs is that its personalisation is extreme while never quite placing the customer at the center of the business. Customers participate in the luxury brand but, in the final analysis, must qualify for it rather than the reverse. Experiences are tailored (like hospitality) but rare and intentionally exclusive: designed to make customers feel uniquely valued, part of a privileged group, and emotionally connected to the brand narrative. Emotional resonance ties to the good purchased and therefore endures for a long time, perhaps a whole lifetime at a deeply personal level.

So, what to does this mean?

Consider the contrast of these business models:

• ⁠ ⁠Hospitality is about surprises that form lasting memories. Neither Luxury nor Architecture can anchor to surprise in this way.

• Architecture is about co-designing and therefore a narrative: how a thing was made is the story at the center of satified customers. Hospitality is ephemeral, architecture is an enduring legacy / story.

• Luxury and hospitality both emphasize emotional experience, but luxury layers in exclusivity, narrative, and status, giving clients a sense of belonging to a privileged circle.

• None of these models have the “invest once, sell copies forever” aspect of media or SaaS. They can achieve similar or higher profitability, but rarely achieve economies of scale. But we can expect software to retain business model engines of cornered data and network effects that do have economies of scale effects.

When I previously wrote or presented about brand as a defensible strategy to mitigate commoditization in the software business after AI, I realise now I was thinking of a weak version of brand effect. I was thinking of the brand halo of “trusted”, i.e. we are not a start-up and you can rely on us to be here for our customers in the long term. That's fine, but compared to the brand power of luxury it is minor. In 2025, I promulgated a concept of “Build to Order” using AI to simply make the code for what our customers want on-demand as they ask for it. But, I failed to explore the potential of service in the sense that it is a cornerstone of hospitality and architecture. These businesses therefore offer important lessons on how to not just survive into the AI age where Unsupervised Coding renders software abundant and fastly produced. They offer paradigms for elevating brand (Luxury & Architecture) and service (Hospitality & Architecture) to levels not seen yet in the software business.

What I haven’t written about very explicitly is the changing nature of product management as a specific role in the age of AI. This article tries to focus in on this job and speak to how it is changing.

The PM role prior to GenAI

As part of the product manager training tracks I developed in 2023 for Transporeon, we defined two successful styles and one anti-pattern. The anti-pattern will be known to anyone who follows Marty Cagan, the other two are more of an original view of the Product Manager source of value:

1. Market Visionary

   An ability to form a unique & correct insight into market opportunity, combining valuable-for-customer with attractive-for-software-company. These product managers typically have a pre-sales, consultant, analyst, or target customer background and superior understanding of the domain they intend to serve.

2. Product Craftsman

   Their superpower is to convert abstract ideas into fine product through discreet actions or steps. These product managers typically come from design or engineering and have a deep inner drive for elegant and quality solutions and know how to achieve those goals.

3. Anti-Pattern: Coordinator

   Product managers who is de-facto a backlog groomer nor project manager. These are coordinating roles for the value adding work of other people.

Coordinator as anti-pattern

Nothing about GenAI makes me doubt that the PM should not be a team coordinator. Successful coordinators often absorb just enough of the facts about the product and competition to grasp the germaine elements, and often not even that much. GenAI reduces requisite team sizes (or, by increasing productivity, increases what a team of the same size can accomplish). Therefore coordination demand is the same or less in a GenAI world. Contrary to the view of product managers as coordinators, product management should be a haven for individual contributors who emphasize introspection, creativity, and domain taste.

Am I perhaps exaggerating the impact of the PM though? The dream of the individual PM is one that is heroic. We love that idea, we think it’s cool and exciting, even if it is hard to systematize and predict. And yet GenAI seems to orientate to the individual more than the group. In a post-scarcity era of code the anxiety sits in devising to what end to invest code-generating efforts. Extreme velocity of code creation must therefore be married to taste, abstraction, and direction of a product manager. Taste leads to a PM profile of a craftsperson. Abstraction leads to a PM profile of a visionary. Nowhere does coordination rise in importance.

A Visionary PM in the AI Age

Hallmarks

For visionaries, product strategy combines depth of purpose, faith, and holistic worldview. Their idealism enables PMs to conduct their roles with missionary vigor.

Strengths

Visionaries engender a belief that their product has a destiny to give more to the world than another example of the agreed way to do a job. This requires a distinction between those responsibilities in which their product's role is merely helpful and those to which it is indispensable. Visionary PMs, by intellectual acts of abstraction, synthesis, and systemic thinking, are more likely to derive where lies the border between these two forms of solution. Visionaries astound us with their ability to make better sense of the complete avalanche of facts, to bring them into a concise narrative in which we also have roles with agency and purpose.

Weaknesses

Even when situated in correct analysis, an error of soaring vision is its tendency to set goals that are beyond a team’s physical, intellectual, and emotional capacities. When visionary product leadership fails, either by inadequacy of execution or illegitimate thesis, the energies of the missionary righteousness turns into self-hatred, the confidence of seeing the future turns into the cynicism of nilihism, and the exhaustion of overextension into personal abdication. The failure of visionary product leadership is a deeply emotional experience in a way that craftsperson PMs avoid owing to their essential indifference about the larger questions.

There is a second weakness. Visionaries place a high premium on coherence and idealism and therefore can see competition incorrectly. In one form, competition is misrepresented as potential collaborators. Competitors are to be converted to partners via compromise as a solvent of disputes and a faith in a world devoid of irreconcilable conflict. This leads to a desire to see competitors as “ready to work with us”, making the product strategy vulnerable to deceptive competitor feints.

Alternatively, visionaries sometimes lock onto a competitor as the full embodiment of the adversary and therefore seek unlimited defeat. They miss that competitors need not always be overcome but merely survived.

A tidy world of true friends and implacable foes leaves little space for accommodations to illogical (but real) competitive dynamics. Nor does it help a team muster the patience for a stark course of action when grinding attritional marketshare battles are the right strategy. Or for a partial alliance which must, in time, break down.

Obviously, one must achieve a middle ground: neither underestimate the deep basis of competitive threat nor fall prey to the illusion that competitors can be coopted as partners. Visionaries find this middle ground hard to navigate.

A Craftsperson PM in the AI Age

One can imagine taste as a naming problem: your brain knows what it likes but can’t articulate why. Craftspeople PMs can articulate why, and therefore they have a taste advantage. For the craftsperson, product strategy is grounded in such concrete and immediate tasteful choices that it hardly exists as more than the summation of many discreet decisions. Their focus on the immediate and tangible, at levels of excellence beyond the amateur observer, is their superpower.

Strengths

Customers don’t experience a product as a whole business. They use products to get things done. If a PM over-optimizes for a systemic view of their business, they lose the customer-first sensibility that holds at its root an empathy with users. Craftspeople make decisions at small scales like they really matter: because in the end they do matter. Craftspeople make products that feel different, that embody opinions. Craftspeople pause everything in their mind and give a product decision their full attention: their presence is magnetic to those they work with. They naturally ask what should we do in places where others would have auto-completed the sentence thoughtlessly. Intentional, explicit, considered, and attentive are the qualities I most associate as the strengths of these craftsperson PMs.

For craftspeople, the competition outlook is also quite different. Their worldview is not divided between friends and antagonists, rather it shows multiple arenas for the pursuit of good solutions in which vigilant effort and tactical maneuver achieve an evolving status quo. No participant is wholly satisfied or in control. Navigating based on solution elegance and accounting for those of others can feel repugnant to visionaries, despite its extreme utility at finding immediate traction. Visionaries rarely fast-follow the good ideas of competitors, craftspeople absorb them readily.

Craftspeople are at ease with contradictory or incomplete relationships with competitors in which they see a list of point issues of varying degrees of solubility. They do not make the transformation of competitive intent a precondition to partnering, nor feel compelled to achieve total victory. Without the need to develop and preach a comprehensive theory of the domain, incremental product improvements rarely fit in competitors at all into their thinking. Indeed, superior tactical reactions come from considering competitive forces only at the exact points of tension. And craftspeople often develop piercingly accurate understandings of their competition because they need not include their aspirations or achievements within a theory of everything for their domain.

Weaknesses

But the nature of craft these PMs embrace is one of incrementalism. This subordinates long term planning to efforts to reduce specific, definable dangers or to deliver specific delights. Craftspeople win more of their present battles but also are more likely to be crushed by disruptive innovations, especially if the innovation comes from outside of a user experience (such as in the form of pricing model, distribution system, or brand identity).

In brief, craftspeople PMs are optimising on a shorter and smaller goal. Their trade-off is to leave systemic integration of all aspects of the product strategy to someone else (or to chance). When visionaries fail, the emotional sentiment can be crushing. When craftspeople fail it seems to invoke pity more than cynicism: that the PM simply did not register that the basis of their work was not speaking to the way in which success would be judged.

So, what?

Don’t be a coordinator: that is the first message to take from this article. But between a visionary product manager and a craftsperson, what is best? For now both have merit and place in a software company. Visionaries make sense of the world and chart a course for a successful business. Craftspeople prevent AI velocity from becoming product slop: they are the tasteful designer in an era where objects traditionally hand-wrought will now be mass produced.

In an adaptation of my colleague's article referring to the Product Loop of Awesomeness, I see both Visionaries and Craftspeople as working a feedback loop but doing so at a different level of abstraction. But the Craftsperson's loop is shorter and has both an internal loop (i.e. try something and evaluate for oneself) and a customer feedback loop. These shorter loops manifest in faster reaction, something I had noticed prior to seeing the visual diagram.

Where possible, a PM’s challenge is to operate on two tracks simultaneously: creating and invoking utopic rhetoric to explain the product goals while sustaining the vigor and tactics of a craftsperson whose first and last judgement of their work is worthiness for the attention of a user.

Interestingly, both of them seem to have a means to engage with the Jagged Frontier of AI.

The key concept to notice about a jagged frontier domain is that, while we may someday arrive at a clean asymptote of progress, there is significant variance in how this may occur. And businesses are path dependent. Consider this quote:

An implication is the search space of possible futures explodes: If you take this seriously, then the possible range of ways the next 5, 10, 20 years could go looks drastically wider. There are many, many different combinations of what could be developed, in what order, and how that will affect what is developed next. … the order in which things occur impacts who is affected, who has power, who is disgruntled, who is provoked, who is trying to manage the situation, who is able to manage the situation.

It is not good enough to say “by 2035 there will be AGI”, because there are many paths to AGI and most products must make path-specific bets. Craftspeople make these bets through immediate and deep reaction to events as they unfold; visionaries do so through a pre-emptive anticipation of systemic-level changes.

Why we need a logistics utopia

I’m turning 45 years old soon. For most of my career I’ve heard conference presentations and marketing collateral say “the pace of change has never been faster” without ever giving expression to what we’re progressing towards. Change without purpose is taxing. Endless sloganeering breeds cynicism. I was cynical in 2014 when I wrote:

We may be on the edge of revolutionary changes in forecasting, material handling, and collaboration. Or we may not. We might be in a rather squalid, tepid, unremarkable time period in which nothing of lasting use or interest will appear. In the thousands of years that logistics has occurred, and the likely tens of thousands of years ahead, why would 2014 merit much attention?

I am not alone in cynicism. Among other things, supply chain professionals of my age trained during the high tide of globalization. Trade and grand scale coordination are walking backwards, slowly so. Rilke said that when we succeed with small things the victory itself makes us smaller. Only by engaging with unwittingly hard tasks, which anyway often decline to let us wrestle them, do our successes have meaning. As the complexity of supply chains diminish, logistics professionals have fewer novel and epic problems to attack. In a reverse of Rilke, their professional life seems made smaller for lack of suitable problems.

To be sure, there has been progress in logistics. A good example is final-mile. New levels of inventory and transport coordination enabled next day and then same day delivery, which unleashed e-commerce demand and altered eventually even our urban and suburban infrastructure. These got us through a pandemic in reasonable comfort. But let us admit to the incrementalism at each step, unguided by an end state well removed from the status quo. We got to same day delivery through accumulated benefits of slightly faster-cheaper deliveries.

A profession needs a frontier. We need a venue where the majority of our efforts are not in competition with others but directly against what appears to be the granite walls of impossibility. In the absence of a battle with nature our daily work devolves into squabbling and status games; our triumphs are not worth describing to our spouses because they have no inherent value, only office politics point scoring.¹ We should see our work imbued with moral meaning. This is not to praise our choices, but to judge our efforts.2 Does your work absorb the best you have to offer? And, for those of us who would lead the field, have we created a sufficient direction or vision such that efforts of others can be captured fully in its sails?

Cynicism is the baggage the logistics profession brings into the AI era. It explains why logistics staff speak of AI not as an enabling tool but as a hassle, a gimmick, or a mystery. This year, 2025, is a very active time for us, full of deep concerns about the economy, the transport sector, and the spectre of technology change. We are restless because exogenous changes abound and yet, within logistics, there are no clear lines of advancement towards a significantly improved future. The current generation of logistics leaders, though talented and diligent, are unmoored from any sense of larger purpose derived from a grander project whose timeline matches or exceeds their own working life.

In brief, this is why we need an earnest vision for a logistics utopia. Such a project can reduce cynicism by calibrating progress. It can direct efforts not just with incremental and aimless optimisation but with leaps of innovation. It can give full surface area to the creative efforts of thousands of people; a place for our brightest to be proud to contribute in part because when answering “what they do at work” it has obvious societal value. A logistics utopian vision captures imagination in the same way that a humanity that is multi-planetary or cancer-free does; and no less impactful as these examples in its realisation. Finally, we need a logistics utopia vision because our adjacent domains will otherwise overwhelm us with their novelties (such as AI and robotics) or their constraints (such as trade barriers and working regulations). These external forces have no sense for what the world needs from its logistics systems and, in our passivity to set a compelling vision, they will do us little good. Only by harnessing these changes to a purpose, one promulgated and adopted from within our profession, will nearby freneticism convert to movement rather than friction.

What is the logistics utopia?

We should be defining this collectively, but here is a starting point. One of my mental hacks to boot-strap thinking about a goal is to think about its opposite. What would characterise a logistics dystopia? Logistics services would be expensive, unreliable, dangerous for those nearby, hard to engage for those afar. A dystopic logistics world would result in materials moving less overall, driven by cost prohibition, fear of loss or damages, and because the lead times mean demand for materials would be impossible to fill within the window of its need.

Logistics is ultimately the movement of materials through physical space in service of some other mission. We don’t do logistics for its own sake: it enables or executes something of inherit value and purpose. Even the at-rest aspects, like warehousing, exist to enable better pre or onward movements which are themselves in service of some final goal. For example, we bring materials closer to their final point of use so that when called upon they appear quickly. And we want the materials to appear quickly because they serve us in another way, such as blood for th surgery or toys for the birthday. Therefore, a logistics utopia amounts to a world where more materials move about, whenever wished, and that the wishing of something else invokes material movement without having to make concessions to the challenges of logistics. And that arises because the cost to reposition materials is insignificant, the invoking of material movement is extremely easy, and the certainty that it works means it barely benefits of our attention.

The logistics utopia is here, just not evenly distributed

I’d argue we mostly have a logistics utopia today in small niches. Trash service usually feels this way. It is cheap to the point that we are almost offended if asked to pay for disposal of trash. It happens fast enough we never have to plan around it, for example when walking down the street or in a hallway of an office building we never plan ahead of where and when to throw away an item. When we are done with our banana peel, or chewing gum wrapper, a trashcan will be nearby and emptied frequently enough we need not think up fallback plans. Water service is a lot like trash: it’s ubiquitous, reliable, and cheap. Few developed places lack drinking water, nor struggle with water disposal. Again, we almost instinctively recoil when told getting or getting rid of water will cost us. These two examples show what a logistics utopia will feel like: effective, ubiquitous, immaterial in cost, and invisible to our consciousness because it need never be planned around.

The frontiers of logistics utopia

For materials move around at our whim, and with essentially no cost or risk, some things must change. That is the frontier upon which logistics progress should be pressing. I’ll lay out a few vectors of importance but want to emphasize that a benefit of having the utopic vision in mind is that it permits leaps of innovation that get to the destination in non-obvious ways. Incremental progress on the following vectors will happen, but that’s not going to be the whole story.

Planning

Materials don’t lift of their own accord, wrapped in protective force fields, and follow a great arc to their destination. Materials must be packaged, loaded into transport assets, moved on indirect routes, held in intermediary locations, and often split or combined in format before their logistics mission is over. These are acts which must be planned. The plans consider both goals and constraints, and they establish the ceiling on subsequent logistics outcomes. In a utopic logistics era, the inputs to planning would need to be of high quality: complete, timely, and reliable. The outputs of planning would get to their executing parties without degradation or latency. Unforeseeable aspects would be either scenario-planned and available during execution or would trigger new planning cycles of sufficient speed and optimal scope. This is a domain where intelligence, particularly of the deductive sort, yields outsized returns. AI is an obvious fit, but it may also play a role in enabling steps such as negotiating positive-sum sharing of information, risk, execution capabilities, and so forth.

Coordination

Logistics actions nearly always entail multiple parties, as seen in our domain’s terminology including INCO terms, shipper, recipient, agent, transporter, owner, seller, and so forth. These are independent actors. Even if full data sharing occurred, they remain agents of their own decision making and therefore must coordinate decisions to achieve their goals. A logistics utopia would include extremely effective coordination such that failures of aligned actions never occur. The roots of those failures today include incomplete alignment of interests, sloppy execution on commitments, failures to convey or to comprehend their needs to other parties, and differing data leading to divergent understandings of a situation. All of these seem tractable as problems. Again, AI has a serious role to play. For example, in areas of conflicts of interest a barrier to negotiated alignments is often an inability to ensure execution of the agreement. AI is a way to introduce an intelligent actor, one who may have authority and ability to use tools such that they in effect are the decision maker about executing an agreement. And what instructions or goals animate the AI decision making can be locked, unlike for human staff. In other ways we should expect AI to improve coordination: it is fast and has near perfect memory and can work in parallel. These should overcome many failings of our current human-based coordination.

Visibility

Part of what makes coordination and visibility fail is a misreading of facts. Since logistics is about the repositioning of materials, we often need to know the state of materials. Where are they, what condition are they in, who has control of them, what are their plans for them, and so forth. In 2025, supply chain visibility can feel a bit commoditized and solved as a domain. But that is far from true in the deeper sense. Consider the MIT Auto‑ID Center (founded in 1999) best known for developing the architecture for RFID tags to identify individual items in the supply chain, positioned as a successor to the barcode, and later coined the term “internet of things”. Their vision was for a world in which every object was uniquely addressable. That means every discreet item would have to exist in a namespace of all material objects, that those objects are also locatable in real physical space, and finally that the catalogue is broadly shared enough that one either need not translate namespaces or could do so with ease. This is a necessary but incomplete state of visibility needed for a logistics utopia. It is necessary because any attempt to coordinate or plan logistics must be able to speak definitively of the things receiving logistics services as well as the things they interact with. But it is insufficient as a utopic state of visibility because we often care about attributes of materials beyond their identity and location. We care for example about their temperature, the pressure upon them, their exposure to light or shaking, and so forth. Logistics visibility entails a deep sensing of the physical world, ultimately a complete one that is nearly infallible.

Energy

To move materials entails consuming energy. The cost and availability of energy is therefore a major concern of logistics. A utopic logistics vision would require efficient usage of energy (through planning, through superior infrastructure, through superior machinery to transport or handle materials). But efficiency only gets us so far. Ultimately, logistics utopia needs abundant energy and ubiquitous energy. Surelyothers will work on energy creation and maybe distribution, but logistics professional are needed for ensuring it finally meets logistics needs.

Material Handling

NASA once described humans as the best multi-purpose robot available for $50k USD per year and mass produced. Though we have machines, a lot of the material handling in logistics is done by humans or with simple levers on our own strength. Boxes are picked up, stacked, shrink wrapped, unwrapped, opened, sorted, counted, re-boxed, loaded, and so forth. These tasks are myriad. They are dull to perform, yet tricky to describe in words, and prove impossible for robots as of yet. If we are ever to arrive at a logistics utopia we’ll need to transfer the entirety of the endeavour to handle materials over to robotics. The robots will need quite generalised spatial skills: awareness, planning, and many surprising adjacent skills. For example, when robots see “caution slippery floor” they need to be able to read, to discern if the situation is true, and to adjust plans accordingly. These are adjacent to picking up a delicate object like a raspberry, or an object robust but which must remain orientated such as a glass of water.

Procurement & Settlement

Logistics services occur between parties, as described above. They must therefore agree to work together and there comes eventually an end to each service that must be settled. Mostly this is financial: we agree on the cost of a service and then you pay me for what I have done. But settlement also entails legal transfers of ownership, responsibility, or simply an acknowledgment that a planned process is at a permanent closure. And dealmaking can range from transactional small scale services to far reaching infrastructure and staff build-out commitments. These acts join the logistics world into others, such as those of real estate, labour, and finance. In a utopic logistics era these aspects would need to be effortless, i.e. fully autonomous. AI has much to contribute here because it can act with speed and fidelity to the goals of each part along with constraining legalities. But it may be that regulation itself needs to evolve, for example to remove steps that insert human effort as a mandatory act in any dealmaking or settlement.

In conclusion:

Logistics professionals don’t need to be convinced that we are in a time of great change: that is obvious. They instead need to be convinced these changes are purposeful; that we are going somewhere we want. They need to believe that working in logistics will lead to contributions to society they can be proud of and that anyone would understand. I know in choosing to describe this as a Logistics Utopia I am invoking thoughts of fiction. But changing endings is what fiction is for, and the reason to set a goal of a logistics utopia is to make it happen, to change not just the ending of the field but more importantly the ending we will have for our personal careers. I advocate for the future, in conflict with the present. Not because our present is so lackluster, but because I see the extent to which we have left to progress. And that requires having a clear vision of where we want to go.

Footnotes

In April 2023, I began to conceptualise building agents using generative AI (GenAI) that would displace rather than assist roles within my company as a waypoint on to a new generation AI-centered products. The approach was meant to doggfood, i.e. to “eat our own dogfood”, AI as workers before moving on to building agents that we bring to our customers and thereby transform the transportation sector's back office. This was a radical approach at the time, perhaps less so now. The rest of the article goes over the highlights of the journey such as can be shared. I've tried to segment the discussion into two topics: Technical Feasibility and Organisational Design.

#1: Technical Feasibility

Are agents even possible?

The key risk was pretty obvious: maybe it cannot be created. In product management you call this feasibility risk. The other risks we care most about include desirability (do people want it even if we can make it), and viability (can we make enough money back to justify the investment, including compared to other uses of capital). If you can make an infinitely duplicatable worker that costs ~$5k per year but does the work of a 26 year old with 3 years experience in one of a dozen professions, that sounds pretty desirable and feasible. But who knew if we can build it: time machines also sound awesome but just aren't technically possible.

A year later, we are past technical feasibility. Creating AI agents is indeed very hard engineering: it is not impossible engineering. One odd aspect of being past extreme technical risk is that no one seems to have internalised it. I find nearly every initial conversation I join on this topic begins with a kind of parade of denialism, i.e.

1. Sure, we can automate a task (like writing a bug ticket or summarizing a customer support ticket). But the whole job is more than the sum of the tasks. → No, we are referring to the whole role not the tasks.

2. Okay, we will be able to automate a role with low creativity (such as customer support) but not a job like engineering or product management. → No, we are displacing creative roles as much as execution-only roles.

This begins to sound like the early days of cloud computing. Remember when people said the cloud was not safe for business applications or data. Then it was okay for business applications, but just BI or similar non-critical applications. Then later it was okay to use for critical applications but only in an ASP-style deployment in which no data was shared. Now multi-tenant single-instance is the norm. Attitudes lagged the technical feasibility at every step.

Agentic Architectures

Ironically, while we were building our Agents there was the rocketing up of the terminology of Agentic or Agentic Architecture. I suspect this is burning out and will be over soon (to be replaced with synthetic data as the hot technique), but its worth taking a moment to situate the work I'm describing within this popularisation of the term. Agentic architectures emerged as a way to improve single-shot prompting to Large Language Models (LLMs) in three ways:

1. Fine-grain control over the LLM chain of thought. For example, instead of saying “plan a trip to the ski town Aspen, Colorado” one can slice this into the desired chain of thought one expects and have the LLM address them sequentially while feeding the result sfrom earlier steps into later ones. Example: “Research the weather, slope opening, and crowdedness of Aspen Colorado and suggest the best weekend of 2025 to go on a ski trip. The results should be a start and end date.” → “For this weekend in Aspen Colorado, find any ski pass coupons at top ranked resorts. Suggest a resort that has availability, returning the name of the resort and the price” → “For this Aspen ski resort and dates of stay, define a day-by-day agenda for the weekend. What time we should wake up, have breakfast, catch a lift, and which slopes are best for intermediate skiers. Output a clear agenda in a printable format”.

2. Tool use. Agentic architectures allow for invoking tools as a step in the LLM response. In the example above I'm clearly expecting the LLM to search the internet in specific ways. But in most of 2023 LLMs didn't do this: one needed to build an agentic architecture that split apart the “send/ receive” of text to a LLM from the tool use (search internet, update a document, etc).

3. Run-Time Compute. This is an odd one for non-technical folks. Did you notice that when ChatGPT came out it would answer a question in a second or two, but (unlike a person) you couldn't say “hey, this is important, take your time" and get a better result? LLMs were all instinctive reaction and no reflection. One use of agentic architectures was the introduction of reflection, especially in cyclical forms in which the output of a LLM is then fed to some form of reflection in an LLM again, i.e. the first LLM may be asked “write a welcome letter for a new hire joining my team” and then the output is sent to the same LLM again but this time with a reflection prompt like “review this letter before I send it to a new hire in my team. I want to balance warmth with setting high expectations. Tell me “no” if it would be insufficient for someone joining a once-in-a-lifetime team, such as a crewed trip to Mars. Then list one specific improvement to make”. The output of the second LLM interaction is evaluated and, if it was “no”, then is sent a third time to the same LLM with the prompt “this letter draft is for a new hire but has the following improvement to make. Please re-write it". The output loops back to the first step. The effect of this is that a cycle is introduced and this cycle can take as long as it needs to in order to achieve the target quality.

Okay, all of these were useful in 2023. But during 2023 the LLMs themselves incorporated agentic architecture. Now in April 2024, when you ask Gemini or Grok, or Claude for something it will use run-time compute to plan its approach to answering the question and then likely search the internet and then answer your question and then to critique itself and polish its answers. The agentic architecture is partially coming by default, and so agentic architectures can easily be redundant if not engineered carefully. For this reason, and because the term agent has become as diluted of a concept as AI ever was, I suspect the public buzz of agentic architectures is past its peak.

Agency Ladder

It is worth discussing how we get to human-equivalent agency. This word is so similar to agentic that its bound to cause confusion. But they are different: agentic is about the technical architecture inside an AI application, namely that there are specific node or steps it goes through and these can have cycles. In contrast, agency means the AI has the privilege to act on its own volition and will take actions we may not have pre-programmed nor expected. AI is not programmed so much as trained like a dog. Agency describes the degree to which the dog is off the leash and therefore able to take actions we cannot directly control.

In our work we settled on two ladders to get from nothing to an AI with full agency. I think of these as full scale, incremental agency. The first one envisions an AI that is doing all of a given role's scope but begins with making minimal impact and then increases. As a thought experiment, imagine an AI intended to become a manager². If we use the first approach the AI begins by joining every 1-on-1 call between a manager and a direct report, but all it does is take notes. Incrementally that note taking grows into organising the agenda, then reminding them to stay on the agenda, then providing its own suggestions for a topic, and eventually taking the lead while the manager watches (and interferes if needed) and ending with the manager no longer existing as a staffed human role. This pathway is notable for appearing like assistance at first and being ubiquitous (i.e. all 1-1s have the AI in them even at the first step).

In the second approach, we would begin with an AI that takes over the entire management function, i.e. immediately removing some human managers in the first step. But rather than this applying to all managers, it begins with a minimal scope such as only replacing one manager in the simplest possible situation. Over time the AI manager is improved so it can handle more diverse or challenging manager situations and thereby replace all the managers eventually, like in the first approach. But the pathway is the reverse: it begins like a displacement but for the simplest version of the job role. Only with incremental improvement could it eventually handle all management roles.

Why does this matter? These two approaches provide a kind of working backwards model for thinking about the pathway between nothing and complete displacement of a role. Neither is inherently more effective. In self driving cars, for example, Tesla is taking the first approach: their cars can be placed into autonomous driving on any road in the USA but their depth of autonomy is only SAE level 3. Waymo is using the second approach: their cars operate at SAE Level 4, enabling them to drive without human intervention but only in specific roads of specific cities. But both companies expect to get to SAE level 5 autonomy in the same time horizon.

Thinking in Spans of Control

The key is not “can an AI do what a human does” but rather “for how long can the AI do what a human does without needing intervention". Apart from tool use, this is why I think agentic architecture are of use: they expand the span of time during which AI works autonomously.

But in order to discuss the span of autonomy duration for AI, we have to start with the span of task completion for humans. I'll connect those dots further below, for now just let me give a few examples³ of how long it takes a human to do tasks which we have also tested on AI. The testing time assumes a human with several years of experience doing the kind of task in question (machine learning coding in these examples).

Now, here are a few charts to show how AI is coming along in completing these tasks.

On the vertical access of the chart below is the time it takes a typical human to complete a task. On the horizontal axis is plotted various LLMs and where they succeed 50% of the time on the task. What you notice from this chart is that LLMs are doubling the task time length every 7 months.

Next we have a chart with the vertical axis indicating probability of an LLM to succeed at a task, and on the horizontal axis we show the time it takes an expert human to do the task. The coloring indicates the LLM release date. The take-away for this chart is that the April 2025 as-is LLMs are >80% reliable for a broad range of tasks that take human experts ~15 minutes. By end of the year this will be true for tasks that take >30 minutes (i.e. 7 month doubling time).

The next chart⁴ plots specifically the 80% chance of success showing a fit curve for the best model by year. It looks only at software coding tasks, whereas those above also covered general thinking tasks. But it also speculates as to how this will progress. A key observation of the authors (that I happen to agree with) is that it will get easier rather than harder for AIs as they pass the one week duration. This draws on the observation that the increases through seconds, minutes, hour and up to week involve significantly more complex tasks. But from one week to a month to a year it seems these may just repeat or join tasks of complexity already covered. This matches with my intuition. As a thought experiment: is a random 5 second recording of your day indicative of your job entails? Nope. Is a random 1 week recording indicative of the other 51 weeks of your job? Yeah, pretty likely. I suspect things like onboarding periods or job interview formats are unconsciously optimised for understanding how much sample time is needed to assume we have a useful judgement of a person's performance. And they both tell me that an AI that can succeed at tasks for 8 to 40 hours is probably going to be able to handle the whole job.

It is worth pausing and calling out that LLMs are currently underperforming on especially “messy”⁵ tasks. Task messiness is like task duration for a human: LLMs succeed only at low messiness tasks but they are growing in abilities at a rapid pace.

All of the above charts were about the time it takes humans to do a task compared to how successful a LLM is out of the box at doing it. What I promised to connect this to is the length of time an AI can be autonomous, and why it is important. Here we go…

Think for a moment about what it feels like when you use an LLM and its doing tasks that we associated with a few seconds of human effort to get right. We call that a conversation, because in practical terms that's the main time you would have a rapid flow of tasks that take a few seconds in a knowledge working setting. We already know that LLMs are good at conversation: it is the main paradigm that we have for interacting with them. Now, what about tasks that take a few minutes? These are often tasks one does alone as a knowledge worker: find and respond to an email, update a file with new information, clear my to-do list in Workday, and so forth. This is the ping-pong of small-scale stuff to do that is the life of the mind of most office workers. When AI does this work it feels like an assistance and automation: it evaporates work for us so we can focus on bigger topics.

But things change when we talk about tasks that humans would normally need eight hours or more to accomplish. My current experiences tell me that workloads that take a human two workdays end up taking run-time of AI of max 30 minutes. When you use an LLM for this the paradigm changes from using a tool to managing a colleague. This happens for multiple reasons. One is that we are simply used to these work volumes being done by a person, and whoever is overseeing them will be responsible for output more akin to a team of humans rather than what they would do as an individual contributor (IC). What I'm pointing to here is the mental maturity and alignment to company goals that is expected of managers will be needed even from ICs if they are overseeing AI agents that accomplished unaided what would normally takes an expert human more than a day. Second, we must understand that an AI capable of doing a day or more of expert work successfully and without intervention is also going to take similar style of management. ICs will in effect hold 1-on-1s with AI in which they collect information, set goals, performance-manage output, role model correct thinking & trade-offs as would be ideal for the field and company, and gives framing context for how the AI's work fit into the larger picture of all work being done at the company. In short, ICs who “use” AI of this power are de-facto managers in mindset if not de-jure managers in a legal sense. Their days will feel like oversight of multiple AI Agents (or one agent that can work in poarallel on multiple workstreams) in which the AI is being managed in a quite active way, such as a daily 1-on-1 meeting or equivelant.

#2: Organisation Design

The Goal of Displacement

At the onset, the goal was a clear displacement of humans from specific job roles. For example, the displacement of engineers with less than three years of experience (specifically, our junior and standard level job codes). The AI agents would displace humans from specific roles because they meet or exceed the same envelope of output type, volume, speed, and quality at substantially lower cost. The mission succeeds if they can replace staff, as opposed to success meaning staff become “more efficient”. That doesn't mean the staff are terminated, just that they are freed to do other work. Although we didn't realise it at the time, in practice this means many of the staff get accelerated promotions because of the learning curve experienced during the process of building, testing, and rolling out such agents.

Why displace people at all, why not assist them? Obviously, a goal of assisting people would be better received by people because it seems to hold no threat to their employment. History is full of examples of people going ape-shit angry over the latest thing that seems to threaten their job. Scribes complained about the printing press. Printing companies complained about laser printers & photocopiers. Photographers & film vendors were horrified by digital cameras. Weavers tore down multiple generations of looms. I assume Clovis culture workers had similar reactions when someone figured out a new pattern for making nice arrows and spearheads.

But, I wasn't (and am still not) optimising for minimizing change. If I built AI to assist humans (rather than displace them), then I'm building a tool. Tools take volition to maximize their utility. It bottlenecks the power of tech behind the pain of changing attitudes. At the time when this strategy was being formulated (around April 2023), a lot of the focus on AI use, especially in the corporate world, was shallow automation - viewing AI primarily as a tool for speeding up existing workflows like email management and meeting transcription. This perspective is like evaluating a smartphone solely on its ability to make phone calls: shortsided about the 2nd and 3rd order impacts and potentials. Those bigger effects are multi-faceted, but for me the key insight was that AI was going to become labour not just productivity.

Targeting

Not every role has the same marginal returns to intelligence (human or artificial). There were multiple plausible strategies for where to direct the first agents. We could have focused on the hardest-to-fill roles. Or the roles with the most staff (so as to save the most money if they were displaced). What I decided to pursue was a recursive improvement loop: build agents that make software, so these agents can help us make better/ more software agents. Because the creation of agents involves multiple functional areas (design, engineering, product management, etc) the speed of one agent within a multidisciplinary team would always be bottlenecked by the rest of the rest of the team. So the true target was the creation of AI agent teams rather than just roles. This is not to say that I expect human-free teams as a result, but rather that each role in a multi-disciplinary team has an Agent and also human oversight. Imagine several principle engineers (human individual contributors of significant skill) overseeing an AI engineering agent (or duplicates of an AI engineer template) that complete user requests or bug tickets at 100x the pace of normal human engineers. This is awesome, but would quickly run out of things to do unless the product management function is likewise working at 100x the normal pace. Likewise, if the product management and engineering is happening at 100x the normal pace then we should see a release every week that contains approximately two years worth of development at the 2024 pace. That sounds like a lot for customer care, product marketing, sales enablement, and even customers & users to absorb unless they too have similar AI agents to help them. This is how I came to target teams as the right unit. And in part it also reinforced the decision to build for internal agents before attempting to build agents for our customers. We can absorb the agent output, for example if it was directed to internal-only tasks such as code base refactoring or building more agents. These missions wouldn't require sales enablement and marketing.

Staffing Whitespace

It turns out that the biggest use case for AI as colleagues is not to displace humans who already work at a company but to fill the myriad roles that a company needs done but lacks budget to fill with anyone today. What I man is that every department of every company has some work that is of low enough value they cannot justify hiring staff for it, but it nonetheless is of some value and so it gets either done as overtime by the existing workers or frustrates everyone by its absence. As an example, let's say your company has a minor office with 30 people (out of thousands in the whole company). Everyone agrees this office should have some form of organised parties or social events, and yet organising them is neither a full time job nor valuable enough to justify employing someone for it. The parties either get organised by someone in addition to their normal job, or they are skipped to the chagrin of the staff. This is the unstaffed whitespace of every company and it is huge. I note that this kind of unstaffed role is larger or smaller depending on the local labour regulations. In India you have roles like the chaiwalla, peons, drivers, and other support staff who just do stuff for the higher paid workers. On the other end of the spectrum there are places like Sweden where strictly enforced union or regulatory rules avoid hiring staff unless they can be paid high wages, and as a result all the helper labour is just missing. As a business operating mostly in Europe and the USA, my company has perhaps one unstaffed helper role for every one to two actually staffed human roles. These helper roles are a major focus of my mind now as they create significant business value, are rather simple (though diverse) in their tasks, and are ebraced happily by staff rather than with suspicion.

Enough about agents, what about humans?

The zeitgeist of 2025 is to speculate about the future of office work. I'm not convinced that the future of AI has limits that are relevant for humans: in enough time I suspect it will be be superior to all but the virtuoso levels of cognitive tasks. The key word though is eventually. For a while its nowhere near our best human capabilities in fields necessary for a company to thrive. The speed and pathway in which these two realities come together is the paramount question. For example, if it takes a decade for AI agents to be superior to all 50th percentile humans at cognitive tasks in 2025, that period likely unleashes AI training or coaching that enables a median human to lift their performance. In other words, that means a 2035 median inside sales rep is performing at 70th percentile of the same role in 2025. In brief, AI may help us humans “amplify and distill” expertise in things we still can or want to contribute to our societies.

AI driven training will help in the transition, but we must contend with a reality in which AI agents do outperform most humans at most cognitive work. How will that feel in practice? We can draw contradicting conclusions from corollary situations. For example:

• Teenagers are much less skilled or trustworthy compared to adults and yet they generally can find paying jobs in the economy. Maybe even if we had an abundance of agents we would employ people as well.

• That said, many adults with outdated skills or severe mental limitations struggle to stay employed. Maybe infinitely duplicatable agents, with their 1000 times lower cost and greater speed, will outcompete normal adult humans for all jobs. This seems especially likely given how resistant adults are to the idea they must adapt to the labour market rather than the reverse.

• Maybe humans will shift to other roles primarily to act as a moral or liability crumple zone that allows us to prove we take risks seriously and wouldn't seek maximum efficiency by taking out all humans. In other words, GenAI will make products and humans will only provide safety.

Those are neat thought experiments. But here is my actual prediction:

Intelligence, a moral sense, aesthetic appreciation, motivation, and many other factors mean some humans are better than other humans at any given role. Even extremely flawed or limited human beings can still have much to contribute to society because of the fluidity of our labor markets and the laws & norms that allow for value chain specialization. This tendency towards division of labour may simply accelerate as AI workers join human ones. In a world of abundance there may be increased inequality of value creation that nonetheless lifts the bottom tranche of human wellbeing directly (or maybe even more owing to distortions and reallocations imposed by social policies in law). If I had to guess, I would say humans will experience a specialisation towards work they are best suited for and which they find more fulfilling. There will be dignity through work for a long time to come.

In closing, this is fun

Magic is coming out of OpenAI, Anthropic, Grok, DeepSeek, and Gemini. Like the spells of old, reciting the correct words to these LLMs makes amazing things happen. And yet how will this come to help the transportation domain, an area I've spent decades of my life trying to solve hard problems? It must be ported to each domain by those able and willing to bridge it. Expertise clearly matters in a world of creating things with words.

I don't usually hype a tech trend. Look at what I wrote in 2014 in response to endless “the pace of change has never been faster” comments at conferences:

We may be on the edge of revolutionary changes in forecasting, material handling, and collaboration. Or we may not. We might be in a rather squalid, tepid, unremarkable time period in which nothing of lasting use or interest will appear. In the thousands of years that logistics has occurred, and the likely tens of thousands of years ahead, why would 2014 merit much attention?

And yet it seems 2025 does merit this kind of consideration. And by sheer chance, I feel a special fitness for this moment in time in terms that Paul Graham describes as the Great Work. My lifelong interest in AI, in science fiction (which prepares the mind for potential futures), in writing culture (LLMs are mostly accessible through writing), and a dozen other seemingly unconnected things has combined with my willingness to think non-conformingly about questions such as should we assist or displace staff. I feel intensely drawn to and productive on the topic. Surely people are feeling the same in many domains. I'm happy to be doing so for logistics.

Footnotes

1. The title can be read as a reference to Marvell's, To His Coy Mistress and that poem's contrast between limitless possibility with mortal urgency. This encapsulates how I feel when I think about the progress that is happening and about to happen as a result of AI. But for a science fiction take, check out Looking for Kelly Dahl from Worlds Enough & Time: Five Tales of Speculative Fiction by Dan Simmons. A lovely short story and it takes place near my new home in Colorado.

2. I assume we'd name this agent “Overlord”, and its development would be done by a graduate student intern. This scenario happens to be directly illegal under the EU AI act. Europeans will have to settle for inferior-but-human managers for a while.

3. This table draws on a paper published by METR: https://arxiv.org/abs/2503.14499

4. For a deeper dive into this forecast, check out: https://ai-2027.com/

5. Here is an incomplete selection of aspects the researchers used to assess task messiness (as opposed to how long they take for humans to do). These are the kind of factors LLM currently fail at, compared to humans.

   

The Problem

An example to begin. You are asked by a colleague when your team will complete a key project so as to make their own timeline commitment. Your project depends on a 3rd colleague that will be dismissed today, but the dismissal is confidential. The dismissal is important to making an accurate timeline estimate, and yet the fact of the dismissal must not be shared. How do you proceed¹?

For GenAI agents, the discretion problem refers to the careful control of what information is revealed, to whom, and when. In everyday working communication, discretion is normal. In sensitive contexts it may also be legally required. The hallmarks of this problem for GenAI agents include:

1. The presence of counterparties with distinct information sets

2. Goals or constraints that make revealing new information a consequential choice

3. GenAI agents that either have their own distinct information set or adopt the information set of a human but deal with other humans

I’ll just briefly explain why each hallmark matters. First, discretion would be unneeded if all people with whom the agent engaged had the same information set (i.e. “knew the same things”); there would be nothing to reveal. Second, an agent needs a strategy only if revealing information would go on to different outcomes in some important dimension. This can come from constraints (i.e. a commitment to always protect confidential information) or from instrumental behaviour to achieve goals (i.e. revealing information may hinder or advance the agent in whatever it wanted out of the interaction). Finally, agents enter this problem when either they know things different from the single human they communicate with (such as having broader data rights when the human does not) or when they have the same information as one human but must then speak to another counterparty (for example, if someone has a personal assistant agent who is then being asked why that person is in the office today).

This topic has gotten little attention from people designing agents. And yet, for reasons that seem obvious to me, discretion matters a great deal when designing GenAI agents as colleagues, and especially when their role is disproportionately about information gathering, processing, and dispersion. While this is a sub-domain of planning, I believe it is a kind of planning that merits special attention because any interaction at all with human social groups will force GenAI agents to have a robust strategy of discretion. Even a single-answer AI, without use for multi-step planning for tool use etc, would face discretion as a problem.

The anatomy of being discreet

Imagine now a game called “office gossip” in which each turn has two phases. In the first phase one must diagnose what makes for novel information to a counterparty (does she know that the project is cancelled). Second, one must decide how to behave with this assumption (I’ll emphasize the riskiness of the funding and see if she says she heard it’s cancelled).

The modelling of a counterparty’s knowledge is the first step. There are several meta-assumptions one could use, which I sort by their value in achieving goals from interactions.

1. No secrets: assume the counterparty knows everything.

2. Take no chances: assume counterparties have only public or company-wide information, or information they have previously disclosed.

3. Federated clearance: ask another source of truth to verify what the counterparty knows².

4. Constructed worldview: make a probabilistic estimate of the novelty of any specific fact in the eyes of the counterparty.

5. Gamesmanship: make a probabilistic estimate of the novelty of any specific fact in the eyes of the counterparty, but also that they behave strategically in how they acquire & use information. They probe for & bluff about a non-zero percentage of the facts in the interaction.

Now, let’s say that one has constructed an assumption about the counterparty’s information and concluded there is something they miss and could be revealed. If we are clever this is in mode #5 so it includes strategic aspects such as “how likely are they to mislead me” or “of what value is this information to them”. Now, we must decide how to behave. Again, here are several meta-strategies which I sort by their utility to achieve goals.

1. Self-delusion: seeing the counterparty lacks information, remove that information from one’s own considerations³.

2. Indiscretion: simply behave without regard to the possibility of exposing novel information⁴.

3. Probe rather than disclose: construct statements that enable the counterparty to reveal they know key information.

4. Revealed Secrecy: reveal that novel information exists but do not reveal the information⁵.

5. Negotiate a disclosure: signal a willingness to reveal information but then negotiate the terms to reveal it⁶.

6. Manipulate for good: without revealing the information, behave in ways that lead the counterparty to a planned outcome that they would feel are logical and yet would make even more sense if they knew what has been withheld.

Humans adopt behaviours 3 to 6 regularly. Examples:

• Probing: “do you think Joe really would quit over this” … knowing Joe already resigned.

• Revealed Secrecy: “the promotion list is finalized but I’m not allowed to share it, I’m sorry.”

• Negotiated disclosure: “if I tell you this you have to swear it stays between us”.

• Manipulate for good: “there is always a chance the funding is cancelled, let’s play it safe” … knowing full well that the funding is already cancelled.

Humans do a poor job of quantitatively assessing these behaviours but we have three advantages to counteract that handicap. First, we have evolved brains that are constantly attentive to social relationships in which discretion is a key influence. Second, we have different relationships with our social groups: they give us humans more leeway than an AI agent and also we can change the social group (i.e. quit our jobs and start elsewhere). Third, until now we’ve been behaving in a world devoid of ground truth. Imagine human comportment if your every interaction, perhaps even your internal train of thought, was under constant monitoring and its choice recorded. Humans can be indiscreet largely because we lack oversight.

Teaching discretion

For agents, both the assumption about counterparty knowledge and the choice between behaviours is an extremely challenging optimisation problem. On the assumption side, anything short of level 5 would handicap the agent with either caution or naivety. For the behaviours, each of their utility requires fixing a time horizon and making judgements about the future interactions with this counterparty and how all counterparties will update their reputation of the agent if the behaviour is discovered. Of incredible importance is handling the time horizon, since after all most forms of manipulation or indiscretion are detected only after the conclusion of an interaction. Likewise, the agent’s reflection on past behaviour is pivotal to constructing correct worldviews of their counterparties.

Without memory and reflection they would fail to account for factual knowledge and miss telltales of motivation or character, all of which are needed if one is to to negotiate for information to be revealed. We’ve seen deep counterparty modelling like this in games like Poker⁷ and Diplomacy⁸. But all dimensions of these AIs are better constrained than what a typical office gossip exchange would require. Games have fixed time horizons, minimal discrete options per turn, a singular score to optimize, and so forth.

Okay, but is this really necessary?

I realise readers may be tempted to treat this discussion as philosophical rather than of practical concern. As of March 2025, every AI agent in the workplace that I know of operates in assumption #2 : they take no chances and are indiscreet. Humans continuously operate in assumption #5 and adopt behaviours 3 to 6 to best achieve their goals: they are strategic about information. This discrepancy has huge implications for AI colleagues joining human teams.

It is also no solution to simply constrain the agents to “not reveal information”⁹. First, all interaction reveals information. It is very often the goal of the interaction to inform the counterparty something they didn;t know beforehand. Second, most judgements of discretion will involve information that is new but not restricted. Even the decision to remind a counterparty of a previous choice is an act of discretion: one is making the assumption that the reminder is in fact framing their decision in light of new information and not just wasting everyone’s time by repeating a statement. Finally, and not least in importance, discretion is a crucial aspect of human interactions. To lack this skill might not hinder an AI’s intelligence, but it would limit its effectiveness when working with humans. And for the next few years working with humans is sort of their mission. Just as we attend to an agent’s ability to plan, remember, use tools, behave with a consistent profile, reflect and learn from their history, and follow policies; so too should we endeavor to build discretion into their architectures.

Footnotes

1. Discretion problems range from mundane to hardcore ethical ones. I tried to choose hairy but not moralistic examples.

2. I can imagine an abstracted service like this within a company for many key facts, such as “does Jonah have access to our full-company profit & loss data prior to public reporting”. But I struggle to see how this can handle all information that would need to be evaluated in the act of discretion.

3. I believe humans are incapable of behaviour #1 (self-delusion to match the counterparty’s information) though agents could do it easily.

4. We abhor behaviour #2 (indiscretion) not just because it is a base behaviour that identifies poor character. It is also simply unwise in a strictly utilitarian analysis. A reputation for indiscretion limits future options drastically.

5. But use with caution: “Whoever wishes to keep a secret must hide the fact that he possesses one.”

   – Johann Wolfgang von Goethe, Maxims and Reflections (1833)

6. “Three may keep a secret, if two of them are dead.”

7. See for example: Pluribus and ReBel.

8. See for example: Cicero

9. And discretion conflicts with honesty. If a user pointedly asks an AI something that the AI “knows” but shouldn’t reveal, withholding information would undermine trust, yet telling the truth violates confidentiality.

But Generative AI does this at a scale and speed that is hard to overstate. I could say simply that Generative AI is thought and since thought permeates all software (and most back office work of any sort) its impact will be nearly a total revolution. But I think it's worth going into the specifics of how GenAI changes the business of software (this article), and from that groundwork I'll later write about how the logistics software space itself will change, and finally how such a change will permeate actual logistics operations. I'll push today's article forward through three opinions:

1. Software development faces three key challenges: accidental complexities of coding, coordination overhead with large teams, and the essential difficulty of forming good product opinions. Generative AI relaxes all three by: enabling natural language programming, reducing team sizes needed for large projects, and enhancing product opinion validation.

2. The cost structure of software development will shift from fixed human labor costs to variable & significantly lower costs. This changes the engine of profitability for SaaS companies and also the likelihood that enterprises just build their own software.

3. These forces together are shifting SaaS towards different business models than those prevailing today.

What makes software hard to develop?

In the seminal engineering article (later book) Mythical Man Month, Frederick P. Brooks Jr. outlined three hindrances to software development. Software is hard for essential reasons, for reasons that are accidental to the current ways & means, and because large teams are needed to implement large ideas. I believe Generative AI radically reduces each, as I'll explain in turn.

The accidental

Accidents are those difficulties in software writing that we face today but which need not exist forever. Chief among these accidental difficulties is precise coding. Humans are not accustomed to perfection, and machines are intolerant of errors. But notice that the degree to which software development demands inhuman perfection has changed over time, i.e. at any given moment the cumbersomeness of software writing is accidental rather than inherent. Punch card instruction entry, for example, was just the easiest way we had available for engineers of a certain period.This is why we call these sorts of difficulties the accidental. They need not have existed at all and could be eradicated at any time by sustaining innovations.

Generative AI is already eroding the biggest accidental aspect of software development: that it occurs in “code” at all rather than natural human languages. It should be clear that any software can be expressed as human natural language. The design for software almost always passes through a human natural language phase, and any software code could be restated into natural language. A natural language version would be much more verbose. But the conciseness of code is desirable largely because code is itself challenging to read, write, and maintain. With such a challenging medium, the less the better.

Since 2023, we've seen the emergence of software written “in english”. As someone near the frontline of this technology wave I think the cutting edge (as of March 2025) is not to escape code entirely and especially not for complex software. But there is a radical shift from code-then-review towards review-only, because generation of code is within sight for many use cases.

The coordination

In the software start-up scene one continually hears someone assert that they favor “talent density”, i.e. they prefer a small team of first-class engineers, rather than a much larger team of median-talent. So would we all. The best team is a team of one: constrained only by that person's intellect and stamina. And yet, how does a small team pursue software projects of considerable size? Facebook, Google, SAP, or any other large software company employs their thousands of engineers not because they are naive to the benefits of small teams with talent density but because the scale of their desired code is not achievable by them. And large programming projects suffer problems different in kind from small ones, due to the coordination of labor.

Coordination makes software development hard for two reasons. The first, a minor one, is that coordination taxes the available time of the team. Software developed with 100 engineers will already set aside perhaps a third of its time in some form of coordination (stand-ups, weekly's, sprint planning, retrospective, 1-1s, architectural reviews, and so forth). These coordination time taxes grow super-linear to headcount unless the leadership applies astute org design principles such as Team Topologies, async collaboration and so forth.

But the second, and much more serious, issue with coordinating larger teams is conceptual integrity. The most pernicious and subtle bugs are born from mismatched assumptions of what the software ought to be. Many software development failures concern exactly those aspects that were never quite specified, and hence rely on each engineer's concept of the product.

Software embodies interlocking concepts: data points and their relationships, priorities, permissions, identity, algorithms, and so forth. This remains always abstract, in that the conceptual construct is the same under many different implementations (i.e. a database write is conceptually identical even when done through different tech stacks). And that complexity of concepts cannot be compressed: the best way to explain code is the code itself. Anything else imposes trade-offs. One can explain code in natural language more verbosely but with less precision and more effort to keep track of the details. Even with such trade-offs we simply cannot compress software descriptions enough for them to be retold in normal human interactions (such as a 60 minute meeting), in the same way that we cannot convey a large novel in order to discuss it. Those who would discuss must first have internalised the material and then refer to it more or less obliquely, hoping their reference was clear.

From this irreducible complexity derives the challenge of coordination. Conceptual errors of one author are hard enough to eliminate, but large teams must maintain a shared conceptual understanding of immensely complex concepts. This creates ceilings beyond which team sizes simply cease to make sense, even when using the best org design and architectural practices to minimise need for coordination.

Generative AI attacks this problem in the most direct way: it reduces the headcount needed to achieve a given level of software. In examples in my team we find that it delivers something like 100x the velocity of a human. While people are still teamed-up to create software alongside such Generative AI that 100x velocity may be reduced. But the scale of software a team of seven can produce is surely an order of magnitude larger with GenAI than without. Generative AI also can be dedicated to the second order aspects of conceptual integrity, such as checking all work for issues, seeking and eliminating unstated assumptions or vague designs, tutoring new team members until their concept sufficiently reflects the intended concept, and so forth. This suggests to me that Generative AI both reduces the count of humans to coordinate (for a given size of software development) but also improves the likelihood of conceptual integrity between them.

The essential

I believe that great software takes a problem of the world, develops a theory of how to best tackle it, and then embodies that theory into a thing one can get buy and use with ease. For a software creator this model has an obvious challenge: the incompleteness & inconsistencies of our ideas. Nor are our opinions often very good.

Since the 2010s the field of product management emerged to address this risky business of forming an opinion. In the tradition of thinkers like Marty Cagan, product managers concern themselves with three major risks of their opinions as they harden into product: is this product concept desirable to its intended audience, is the cost & revenue structure economically viable, and does it comply with company policies and laws?

Generative AI can improve on nearly all product management techniques. It can be tuned to embody taste, even surprisingly good taste. It can listen attentively to customer interviews and run them at a limitless scale. And it can simulate A/B tests for many products or help plan them for others. Compared to the other aspects that make software hardware I suspect the essential difficulty of forming a good and coherent opinion to embody as software will remain the domain of the best creative humans. But they will be massively assisted by Generative AI, like a general with a support staff to handle preparation and follow-through.

What typifies SaaS business models?

Software is expensive to develop

Software may be difficult to develop, but that does not necessarily mean it would also be expensive to create. But in truth the causality works exactly like that: humans find it hard to make software and humans are most of the cost to make it. By the year 2000, labor costs accounted for at least 80% of total software creation costs, with the rest divided between hardware, infrastructure, real estate, and related machine costs. Cloud computing drove down the non-labor costs so that today labor typically exceeds 90% of software costs and very nearly 100% of costs during the initial R&D phase.

We should expect these cost drivers to change drastically as Generative AI comes into software development for two reasons:

1. Generative AI can displace much of the work done by humans in software development & serving. In effect, software development requires thought and machines, and until now only humans could deliver the thinking. Non-human thinking is becoming available.

2. Generative AI's costs are not just lower than humans but also differ structurally in important ways.

In terms of human work displacement, I believe we are already at the level where Generative AI (once correctly structured and harnessed) can replace the junior-to-mid level designers, developers, Cloud Ops, Dev Ops, product managers, and various other roles needed to create software. To be clear, I do not mean basic chatting or in-application assistance available already from all major software vendors (Gemini, Copilots, etc). These provide ~10% productivity gains in the task they relate to but make no improvement to the inter-task aspects of a worker's day nor do they radically change the mechanics of how a human works. They are a form of advanced auto-complete, itself useful but not revolutionary. Instead, I'm talking here about complex software that includes Generative AI and intends to displace humans from a role entirely, not just from a task within the role. In the world of cruise control I'm referring to full self driving. This level of displacement can exist already, it just isn’t available off the shelf. And I believe such AI workers are able to deliver above-median performance in the software development roles when compared to humans with less than two years experience. They likely outperform the 90th percentile of humans with less than a year's experience. I believe in time the AI workers will overtake nearly all median-performing humans in software creation, regardless of experience. Whether AI workers can outperform virtuoso-level humans in software creation (the top 2% for example) is unclear to me, but by definition most companies simply do not have such people to be displaced anyway.

Perhaps you disagree that humans can now or in the future be displaced entirely from software creating roles. In another article I'll explain why I am convinced, but for now just humor me. AI workers that displace human workers bring with them an awesomely different cost structure. Human workers are a fixed cost: they are hired on salaries, paid whether they work or not on a given day, and often difficult to scale up or down. AI workers are a variable cost: they offer a coin-operated black box of thought-work. If we want double the code written, we pay about twice as much, and so forth. The moment code writing stops, costs also stop. It also must be said that AI workers costs are substantially lower than human workers. Based on the work I am a part of, I believe this tends towards 1%, i.e. a software creation task that would require $100,000 in the past will cost $1,000 in the coming years. To be clear, I mean not just coding but the entirety of software creation labor: meeting with prospective customers, evaluating markets, designing user experiences, evaluating compliance expectations, and so forth.

Not only are AI workers less expensive and variable in their costs, they are also parallelizable. Even the leading technology companies such as Apple understand what a rare resource their top humans are. Steve Jobs once remarked to Marc Benioff that they do one real innovative product at a time and the A team (including Steve of course) focus on it. With AI workers there simply is no difference between one instantiation vs another. This combines with their lower costs to lead to a different style of software development. I would imagine software development to look much more like combinatorial optimization, meaning for any given mission we generate not one solution but dozens or hundreds of them in the understanding that some trial-and-error will help us uncover improvements. The degree to which this happens likely depends on the riskiness and portfolio of unconfirmed assumptions. But it again has implications for software creation cost structures because it provides a means to fluidly trade costs against risk of failure. Today, software development is expensive in part because successful developments must payback investments in failed software projects. Even conservative software development teams (such as a small team within a company doing minor adjustments to business systems) experience total write-offs of their work occasionally. This should happen less in the future because of the ability to generate variations in software that permute on key assumptions rather than gambling on the assumption being correct in the only version of software actually created.

Taken together this leads us to a new paradigm: myriad versions of software produced on the fly by ultra-cheap AI workers. It addresses the two key drivers for why software is expensive to build today: people and risk of failure.

SaaS is profitable

Even if software is expensive to build, it is a great business to be in: SaaS companies are highly profitable. But why should they be especially profitable? Unlike most business models, software achieves economies of scale very quickly. This was true with license & ship software, because each copy of the installable CD was nearly free to make. It was true of single-instance single-tenant software because now in addition to code the vendor could share some of the infrastructure & data center staff. And it really comes to the forefront in single-instance multi-tenant SaaS because everything about the software is shared: code, infrastructure, data, etc.

These “economies of share” create a compass for the SaaS leadership: get as many customers as possible on the smallest code base possible.

And yet, in B2B software there are always demands to adapt to the needs of large customers. SaaS vendors don’t want to screw up the magic and add custom code for these customers, and yet something must be done to meet their diverse needs. This is where configuration and professional services enter the picture. Configurations make the software more complex but keep that complexity above the level of code and in the realm of non-technical staff to invoke or adjust. Professional services either convince the customer to use less exotic configurations or design & test these exotic configurations to ensure they work. Configurations like this are the bane of SaaS companies: they slow down sales, they increase cost of sale, and they enlarge the code base.

SaaS with configurations makes good sense in a world where making code is more expensive than cost of sale. And until now that was always true. Engineers, product managers, and designers were a fixed cost resource. Software was arduous and expensive to build. But what if software creation becomes lower than cost of sale? What if a company was selling a CRM and the cost to make the CRM was $1k while the cost of sale was $10k? Wouldn’t we shift to a world where the vendor simply engineers-to-order the software rather than tries to fit requirements into configurations or convince the prospective customer to change their requirements? This trades the cost to create software for cost of sale, i.e. sell by saying “yes” to requests and just make the software as requested. This, in brief, is how I see generative AI cost reduction playing out in software markets. It's not that B2B SaaS vendors will make more or better products and then sell them like today. Instead they will return to a model like (though not the same as) the 1980s where all software was custom built while still leveraging shared data, network, and virtualized infrastructure. Something like Custom Software as a Service (CSaaS?) is the new business model to watch for.

Most enterprises buy vs. build, for now

In the USA, there is a trend for software to split into components served by specialist companies. For example, virtually no software development team would make its own authentication service (i.e. how a user logs in to the application). This has been abstracted out into a component that one buys off-the-shelf from a specialist service provider. Why so? I suspect labor cost is the driver. US engineers are among the most expensive labor one can buy, and as a result the software market has embraced division of labor and specialization as a way to bring economies of scale to counter such costs. Why spend $100k to build an authentication component when it is available as a service for $25 per month, for example.

Europe has less of this, and I believe it's no surprise that Europe has lower labor costs by about 1/3 to 1/2. In such a world it still makes sense to use instead of build, but the search and evaluation costs start to look more significant. The illiquid labor market also plays a role, i.e. staff who are hired cannot be let go easily so they will be kept busy.

China has a minimal component software development culture, and I believe this is directly because of low engineer costs. There may be contributions from a lower trust culture or rule of law in disputes.

Why I raise this is that one should expect that rapidly falling engineering costs lead to more inhouse development, rather than usage of specialised components. The search for a supplier, testing, and contracting will look heavy and slow in comparison to just building what one needs. Especially in light of costs falling to levels that simply mean little to the buyer.

What is the future of SaaS?

I've tried here to map from the seemingly narrow technical advancements in next-word prediction (i.e. what we call Large Language Models) to far reaching second order impacts on the SaaS business model. I outline them as follows:

1. Software is expensive because it is hard for humans to create.

2. Software is hard to create for three reasons: coding demands inhuman precision, there is a paucity of superior opinions about how to solve key problems, and big software requires coordinated actions & concepts among a large group of people. All three are being radically eased by the introduction of Generative AI.

3. Despite its cost, software creation was profitable for SaaS companies because they achieve high operating leverage. To avoid code bloating that would ruin the profitability, B2B SaaS companies added configurability and also fielded solution consultants to either (a) convince prospects the SaaS configurability meets their needs, or (b) convinced prospects to adapt to the software rather than the reverse. At the heart of this approach is the fact that R&D is much higher than cost of sale for a single account. If R&D costs fell well below cost of sale we would expect an approach where sales staff just asked what the prospect needed and that software was created bespoke for them.

4. SaaS companies will not be alone in being able to generate software at a thousandth of the current costs. As these costs fall, enterprises will increasingly see the sourcing & procurement, supplier management, and supply chain risk associated with SaaS as heavy relative to the cost of making their own software inhouse.

So, what does the future hold for SaaS as a business? A few safe harbours come to my mind for the next generation of SaaS leaders.

Process mastery

TSMC altered the chip industry by decoupling design from production, and achieved both economies of scale and process power in their domain. I suspect something like this will occur in software development, i.e. we will see a value-chain split between design and production in a way that has not been popular so far in software. In such an outcome there could emerge one or several significant software companies whose specialty is to make what you asked for rather than to sell what we dreamed up.

Brand

Just because great software can be created by a start-up in a garage doesn’t mean enterprises want them as critical suppliers. Brand, particularly where it indicates reliability, seems likely to grow in importance in a world flooded by new offerings.

Data

Even if you can generate any software you want, some solutions depend on knowing real data about the world. Not only would a SaaS vendor with such data be able to differentiate, the principle of Commoditize the Complement tells us it may be one of the only places where differentiated value can sustain.

Improved visibility is a longstanding wish among supply chain managers. Visibility can mean many things: inventory at rest visibility, in-transit visibility, work-in-progress visibility at suppliers, demand visibility at points of sale, and so forth. But don't take these wishes at face value. The unsatisfied but everpresent demand is a red flag; a paradox that proves we got some definitions wrong. Do supply chain managers really value visibility? Is it really a hard problem to solve? In this article I'm explaining my contrarian perspective that supply chain visibility is going to have a chaotic reset as two realities come together: most software vendors are VC-backed companies that thought they'd build unicorns and give huge payouts to their investors, while supply chain managers are realising visibility is a commoditized feature rather than a category to be bought for a premium. My concrete prediction is that at least the three largest VC backed vendors will have to settle with this reality by being acquired and dismantled by another category leader (for example, by a major TMS vendor) or by cutting valuation and pivoting their product scope towards a category that will survive.

I'll push this argument forward in three steps:

1. The visibility problem statement hasn't changed in ten years, and vendors have converged to the same solutions. There is no significant solution differentiation.

2. The TAM analysis of VC-backed startups overestimated the actual market size and willingness to buy. This is especially true for spending more to achieve better visibility compared to “good enough” visibility.

3. The VC backed vendors like Shippeo, Project 44, and FourKites won't be able to deliver the right financials from visibility and retain independence. Either their name survives and they pivot to a new category, or they fail at independence and become someone else's visibility feature.

Let me explain them in turn.

Let's Not Over Complicate It

When I was under Mac McGary at GT Nexus he used to frame the sales efforts as “make the simple complex; make the complex simple". The point was that some enterprise software was deep and technical and complicated. In those situations the art of the sale was to keep the dialogue above the weeds and sell to authority with a clarifying message. In other cases the solution was so simple the buyer tended to bake-off vendors on price alone. In these cases the art of the sale was to convince a buyer that this wasn't so simple of a decision and to look at the details to see why we are better.

Without a doubt supply chain visibility is an example of the simple: a shipper wants to know information about something they would not usually be able to. Visibility gives it to them. The kinds of information supply chain managers want and the sources of that data have changed very little since I wrote a textbook about supply chain visibility in 2012. Smartphones, truck telematics, ocean carrier status feeds, web scraping to get data not available via API, devices on containers-pallets-or-cartons to monitor temperature and physical shocks… all of these existed in 2012. The principal difference today is that incremental improvements and competition have lowered their price and improved their reliability, i.e. a buyer mostly sees the same solutions to the same problems with falling price to achieve a given level of visibility. I think this is a good thing for supply chain managers.

And yet, this is not how the pure-play supply chain visibility vendors need the narrative to go. In order to deserve the attention of leaders and to justify IT spend, the visibility problems need to be increasingly urgent or novel. Their sales efforts need to make visibility more complicated than it really is. And I don't think the supply chain management community buys that narrative anymore.

Racing to the Bottom Price

In theory, simple visibility solutions might still be differentiated. In theory, one vendor might have a proprietary data sourcing strategy like Wal-Mart building a private satellite configuration in the 1980s to sync data with their stores before anyone other retailer could do so. But in practice visibility solutions are the same to customers in all meaningful ways. They aggregate data from the same sources. They calculate the same sort of KPIs, alerts, and recommendations. Their differences strike me as akin to countries driving on the left vs. right side of the road: visually striking but ultimately arbitrary.

When a buyer has at their disposal multiple perfectly suitable software solutions they naturally turn to non-functional considerations. Is this vendor easy to work with? Will they still exist in five years? Do they invite me onto yachts for parties? But by far the most important factor is cost. Buyers want to minimize cost, not maximize visibility coverage.

Why would buyers not pay a premium for more complete data coverage, better data accuracy, or covering all modes & regions in one tool? Because visibility has a paucity of proven business cases. We absolutely see robust business cases (and therefore investment in premium visibility) in sectors like pharmaceuticals where primary and secondary packaging must have a provable chain of custody. But most physical supply chains don't need that kind of “no sparrow shall fall without us knowing” level of visibility.

Given that the marginal returns on visibility just don't matter to most businesses, bundling a basic version of visibility with other services turns out to be the market-share winning move. It reduces IT vendor count for the buyer, brings cost of ownership down, and avoids integration risks. Most shippers get their visibility via core systems or as a perk from their business partners. Those that don't would usually prefer to do so if offered.

A Financial Reckoning is Coming

The three VC-backed visibility vendors were all formed in 2014. Since then, Project44 has burned through about $900 million in funding, FourKites about $250 million, and Shippeo more than $100 million. That is $1.25 billion in funding that expects about 20% internal rate of return. To make the math simple, these companies need to be able to return at least $5 billion to investors. I believe the liquidity event is supposed to look like this:

But that isn’t going to happen.

At these levels of enterprise value only the largest private equity or public markets are possible routes to liquidity, and both would expect to see at least $400 million in revenue under normal SaaS margins. I doubt that these companies have between them more than $300m in revenue, and they are loss-giving rather than highly profitable.

While venture capital understands risks and winner-take-most dynamics, even a single winner wouldn't give the necessary payback. Although it sounded good in 2014 to pitch the “you have visibility to your Amazon order and Domino's pizza, so why not your truckload of FMCG products?", the TAM calculations simply were wrong. De-industrialisation and de-globalisation played their part. Material supply chains are an ever smaller role in the economy (compared to services) and international trade peaked in 2011, declined subsequently, and is expected to deeply retract under the second Trump administration. But the major theme is an inverse of John Maynard Keynes's famous statement: the market is staying rational longer than the VC backed providers can stay solvent. In order for someone to cash out the investors from Project44, for example, they have to bet on increasingly unrealistic revenue growth.

I actually feel deep resonance on this topic in comparison to an article I wrote back in 2020 about the Ponzi scheme of Convoy and UberFreight. At that time I noted that the biggest value these companies gave the trucking sector was to take VC investment and essentially hand the cash over to carriers or shippers. You can get a lot of customers when you offer to sell $1 for $0.60 (and yes that is the rate at which they were subsidizing transportation in 2020). But it eventually comes to an end. In that case the clever answer from bulls on those businesses was that they could raise prices on shippers back up to market norms, slim down their inhouse costs to normal brokerage levels, and become a very large 3PL wit normal 3PL margins. My hunch was that churn would eliminate the expected gains: logistics is very price sensitive and degrading service while increasing prices is not something shippers would miss. Skip ahead some years and bingo, that was the right call. Convoy is dust and UberFreight is basically Transplace plus a lot of unprofitable noise. It doesn’t matter how mighty a company looks with big funding rounds and unicorn status. You cannot eat valuations: free cashflow is king in the world of grown up companies, and public markets cut through the self aggrandizing marketing.

So, what next? I strongly doubt any of these VC-backed visibility vendors will stay focused on that category through 2026. I'm not saying these vendors have not achieved product-market fit, I'm saying their cost structure means they already charge 25% more than my company (and others) do for the same product and yet still cannot make a profit. That's not going to get easier: prices for visibility should fall in the coming two years rather than increase. With a price-war on the revenue side, limited interest & down-rounds on the equity side, and higher cost of debt on non-dilutive funding side… something has to change. I see two ways for these vendors to exit visibility.

The first is to get acquired, dismantle the company (to cut costs), and become someone's feature. The kind of buyers who might do this include BlueYonder, SAP, and Maersk. More financially disciplined software companies like WiseTech and Descartes would probably pass on these deals even at deflated valuations.

The second option is to pivot and use the remaining runway to enter adjacent markets. Dock scheduling, for example, seems to be a likely direction. Whether these pivots work depends on the usual factors of competitive outcomes. What won’t make a difference is their visibility success. That's why I'd call these pivots not extensions. Ironically, as I was about to publish this article I saw that FourKites announced such a pivot. Good for them! I had already been rating FourKites as the most likely to navigate this situation well. Mathew Joseph Elenjickal, their CEO, has guided them for years to roughly match Project44 market share in their home turf of the USA but while burning less than 25% of the capital of Project44. I may have my doubts about the attractiveness of the category they played in but Mathew got a 4x return on invested capital against his nearest competitor and that bodes well for the pivot he is now making prior to Shippeo or Project 44.

It's worth saying explicitly that I don't wish these companies ill will and I don't get a thrill out of predicting troubles for their financial health. In the case of Mathew of FourKites, I started my last business around the same time and have had several nice interactions with him over the years. I'm principally interested in the big picture changes happening here to the industry I devoted my career to: a major software category in supply chain management is evaporating, one that took major attention thanks to $1.25 billion thrown at sales and marketing.

Is This Really About Transporeon?

I'm sure a cynical reader of this article would say it's just unattributed product marketing for my company. On the contrary, I tended to constrain myself from writing in my personal Substack or other forums about my opinions as I took over product & platform at this business. It's been over a year since I last published: I didn’t want to confound a company position with my own, as I'm neither a spokesperson nor marketer. But I think it's time to share more. And, if I can say so, I have a right to a viewpoint of my own on this visibility topic. After earning a master's degree with an emphasis in supply chain management I've been working on visibility since 2010 in projects for companies like Dick's Sporting Goods, Adidas, Build-a-Bear Workshop, HP, Syngenta, Novartis, Panalipina, DHL, Fonterra, GT Nexus, and so forth. I wrote a textbook on supply chain visibility still used in some university courses. And indeed I now lead product and engineering for one of the top visibility vendors. We (Transporeon, now a Trimble company) provide the same visibility solutions as these VC-backed vendors in ocean, air, rail, FTL, Europe, USA, etc, at 25% below their prices. Alongside Descartes we are one of the only top vendors who are profitable and therefore likely to be intact in two years. In 2021, Transporeon had already identified the germane factors I am describing for the visibility market: visibility is best provided as a feature of a larger solution, it should be good but inexpensive (free if possible), and a vendor's cost structure matters the most in the end because we need to drive to de minimis price points. That cost structural consideration was part of the reason why we didn’t enter the USA market with real-time truck and rail tracking until 2024. Only with the merger with Trimble did we have a distinct cost advantage in the data lifecycle and sales channels in the USA, something that we followed through on to win significant logos at massive undercuts to the typical price for the region. But is this article about Transporeon and Trimble? Nope. Those are the least dynamic of the vendors because they are the ones that will exist in the same form in two years. The real drama in visibility will be in those pivots and abandonments of independent visibility businesses that I predicted along with the scramble by folks like Gartner to scrap a category of Magic Quadrant that vendors no longer consider relevant before they likewise are seen as irrelevant. An increasingly challenging task in a world of bespoke deep research reports from Generative AI for a fraction of the cost of a Gartner briefing or membership. But that is the story for another article and another day.

You can still speak with people whose career included punch-card data crunching. I worked for years in a phase where software was firmly tied to the hardware that ran it. For a while we had the Application Service Provider (ASP) model in which all that was still true but you paid someone else to do it and used a crappy remote connection software like Citrix to get to the software1.

Then there was single-instance multi-tenant Software as a Service (SaaS) tightly coupled to hardware scalers (you paid per hardware usage, essentially). Now there are serverless offerings where a customer has no actual relationship to the physical layer. That’s a long way in one career: from manipulating laminated paper like a kid’s craft project to ubiquitous and hidden calculation.

As software becomes further abstracted from calculation it is worth pausing a moment and reflecting on what it is. At this point software is starting to resemble magic spells. We move our wand (mouse) and say the incantation (type something into a webform) and stuff just gets done. But SaaS isn’t magic: it is theory.

I’m not the first or only to propose that software is theory. This line of thinking has been here all along. Consider the 1985 Programming as Theory Building by Peter Naur. He posited that developing software is not about the execution of sequential build steps, but primarily about forming an insights or theory of the matter at hand of their desired product. In practical terms, if you make an app about habit tracking (for example) the engineering is less about completing a cascade of necessary steps to code it so much as forming a novel and correct insight which would organize the resulting habit-tracking experience. Peter Naur chose to describe this process as theory building, and connects it back to philosophical notions such as Karl Popper’s world three and two realized objects.

Both Peter Naur and later writers emphasized the role of the software creators (i.e. the team) as the most interesting aspect of viewing software as theory. For example, here is Baldur Bjarnason2.

Software is the insights of the development team made manifest. ... The written code is how software interacts with end users and other software systems. The insights and knowledge that exist in the minds of the developers are how software lives, changes, and grows. Without the code, it has no way to interact with the real world. Without the knowledge in the minds of the developers, it has no way to adapt and survive.

Ken Kocienda's book Creative Selection describes this approach as central to Apple's software development during his tenure there and when working on blockbuster products like iPad and iPhone. Their approach to product as theory manfests in things like a focus on taste over data. As he says when contrasting Goole and Apple:

Google factored out taste from its design process. At Apple, we never would have dreamed of doing that, and we never staged any A/B tests for any of the software on the iPhone. When it came to choosing a color, we picked one. We used our good taste—and our knowledge of how to make software accessible to people with visual difficulties related to color perception—and we moved.

To restate Peter Naur, Ken Kocienda, and Baldur Bjarnason view in brief, I believe they see the software as an incomplete manifestation of theory, noting that only the team who built it contain the full theory. They would see software products as akin to experimental results that were accurately predicted rather than the theory that predicts them. I agree with this perspective, and note some confirming facts it explains:

1. Software can be experienced without being easily duplicated. If it has a theory, that theory isn’t fully clear to the users.

2. Engineers coming to a product without a chance to speak with its originators often struggle to internalize what it does, how it works, and why it was made as it was. As per point 1, if the software has a theory it is also not obvious to later engineers who can access its code.

Probably the easier analogy to use here is music. The songs of artist like Bob Dylan or Taylor Swift manifest their theory about music, but we recognise that the songs are incomplete artifacts vis-à-vis this theory: one cannot listen to a Bob Dylan album and make its natural follow-up. Bringing it back to software, this is similar to how Apple’s focus on taste results in outstanding user experience in their products which are nonetheless not imitable by competitors even when such choices have made them the most valuable tech company in the world.

Most of the proponents of this view go on to focus on the higher importance that should be placed on the team who makes products. If you believed the creation and survival of software products was akin to artistry, you’d simply behave differently as a leader of such people. It would call for different recruitment, advancement, collaboration, and retention strategies. I agree with these conclusions, but want to focus the rest of the article on something else that this view of software-as-theory leads to. I ask myself: if software creation is theory-building then what can we learn from the way scientific theory is formed, competes for domination of a field, and is eventually discarded?

How Does Theory Advance?

I’m no scholar of the history or philosophy of science. But we’ve all heard of paradigm shift as proposed by Thomas Kuhn. His book The Structure of Scientific Revolution is the most cited source in social science publishing. I’ll just quote his Wikipedia article directly:

Kuhn made several claims concerning the progress of scientific knowledge: that scientific fields undergo periodic "paradigm shifts" rather than solely progressing in a linear and continuous way, and that these paradigm shifts open up new approaches to understanding what scientists would never have considered valid before; and that the notion of scientific truth, at any given moment, cannot be established solely by objective criteria but is defined by a consensus of a scientific community. Competing paradigms are frequently incommensurable; that is, they are competing and irreconcilable accounts of reality.

There are a few key points I’d like to draw attention to.  

1. While continuous refinement does happen, real progress is infrequent, abrupt, and transformational

2. Scientific truth is in part a collective agreement among domain participants.

3. Competing theories are difficult (or perhaps just pointless) to compare in their own terms.

I think these points are incredibly germane to theory building for software products. Let’s start with the paradigm shift aspect. Successful products create discontinuities in their markets. Your phone's SMS didn’t get better a bit at a time until it was free to use around the world and could handle GIFs, videos, group chats, and provide real-time location pings. WhatsApp did those things. In product creation we call this by terms like disruption, winner-take-most, power-law distribution of success, etc. Its why VC funds flow to high-risk high-reward software start-ups, and it maps nicely to how theory advances in infrequent, abrupt, and transformational steps.

Second, Kuhn’s point about scientific truth being a consensus of the community is something I also see in software products. A great example is how software vendors and buyers self-organize around a category: its name, its minimum requirements, and the axes on which competitors should fight for market share. Gartner collects a tidy tax on this tendency by just typing it up as Magic Quadrants and other memorabilia. My point here is that the existence of a category like Transport Management System (TMS) and the basis for comparing various TMS vendors are all there by consensus of the community. There is nothing to say objectively that functionality for transport planning and execution should be together in a package, and this is exactly the sort of thing that a community believes collectively at a moment and then later changes their mind about (again, in consensus).

Third, Kuhn describes theories as difficult to compare in their own terms. He’s not saying it’s all subjective, just that it’s kind of pointless to expect theories to have meaningful perspectives on each other. This again aligns to my experience with software products, and most concretely with their teams as the full owners of the theory. Have you ever wondered why a team whose product is failing doesn’t simply attempt to fast-follow a winning product? This may be ill advised for business strategy reasons (never run your competitor’s playbook), but I think it’s more basically ruled out because the failing product’s team cannot yet see the winning product’s theoretical basis because they are trying to do so from the lens of their existing theoretical framework. For example, I have seen product teams that had a foundational belief in the primacy of the desktop user not be able to properly internalize the importance of multi-screening or mobile access. At first this can look like poor decision making driven by lax prospect research, fallacious sunk-cost thinking, a fear of the internal politics of blame, or just avoiding taking on a hard piece of workload. But a deeper reason seems to be that the worldview that leads to a decision is simply not well suited to judge other worldviews accurately.

How to Apply This to Product Creation?

Bring a theory

The most valuable tip to take from this article is the obvious one: your product should be a manifestation of a theory on the subject matter it purports to deal with. I am astounded by how few product teams realize this and act on it. Kuhn proposed a set of five points which he'd expect a new paradigm to achieve.

1. Accurate – it aligns with reality

2. Consistent – internally consistent, but also externally consistent with other theories

3. Broad – a theory's consequences should extend beyond that which it was initially designed to explain

4. Simple – adopting this new theory simplifies rather than complicates the domain

5. Fruitful – a theory should disclose new phenomena or new relationships among phenomena

I see elements of this in new products, and would adapt them to make a checklist for new products as follows:

1. Functional –  it instructs us how to do a job at hand

2. Connectable – you can use the theory well with surrounding theories / products.3

3. Big enough –  it’s a theory of a product not a feature

4. Simplifying –  it makes the customer's world simpler not more complex

5. Valuable –  it creates value for the customer by resolving current tensions as yet unaddressed or by enabling a new range of things (acts, products, services, etc) of obvious worth

How to Make Theory

How does one formulate a theory to begin with? The act of creation is hard to pin down, in a similar way that one cannot be told exactly how to craft a good song, perform well in theatre, or bring paint to canvas for a work of art. But I think I can give an overall pattern to look for and then a specific tip about how to make the most of creative insights.

I think great software products will have the following path. First, they are contrarian in a specific way. Second, their contrarian act (as manifested in the product) is insightful. It offers a perspective on “the job to be done” such that, if you agree with the contrarian view, the world is better or clearer in some meaningful way. Third, the world converges to this view via meaningful contact: it begins contrarian but ends as orthodox, and the transition happens naturally as the product’s perspective infects and converts the users. Good products win the argument with the world of customer expectations in which they began as the contrarian outsider. In product management we call this milestone “product market fit”.

The contrarian focus is directly connected to how products are a manifestation of theory. Emerging theories are, by their nature, contesting orthodox theories for their ability to best explain the world. These contests can be about the edges (i.e. refinement of earlier base theories) or at the core (a wholesale replacement). So too with products as manifestation of theory. And in both scientific theory and SaaS products the winner induces a kind of release of tension when encountered. I associate this feeling with the idea of parsimony, i.e. when someone gives me a contrarian (but superior) perspective it feels like a simplification of the world. In that act of simplification, tension I had been unknowingly holding is released.

Readers may now be wondering, what in the world does Jonah mean by a release of tension from great new products? What I am referring to here is how people in a domain are constantly exposed to anomalies in how things should work. These anomalies frustrate us, but often without a viable way to solve them we simply downplay them. Later, when a new approach to the domain is available that removes these anomalies we quickly allow the frustration at the past situation to be voiced. In effect, a tension was building and then released, and in doing so it made a return to the old situation quite negative. As Erik Hoel4 describes:

Which leads to the way that successful new products convert users to their contrarian theory. By example: you always hated taxis. They were expensive, their costs were hard to predict, they were hard to find, they were unreliable, they were opaque and impervious to customer satisfaction ratings. And yet we rarely spoke of these things until after on-demand ride hailing (Uber, and their copy-cats) emerged. And then we all collectively let ourselves see the orthodox option for all its flaws. On-demand ride hailing isn’t just better; it’s obviously better in a way that calls into question why we hadn’t thought of it previously. From origins that very often were outright illegal, nothing about on-demand ride hailing is contrarian today. It is simply the best way we know to do one-time mobility. This is an example of products as theories, and what happens when the theory wins. Contact with the product converted users to see the world from its theoretical view: and that created the consensus for a paradigm shift.

Attend to Anomalies

My last advice for product leaders seeking to create products that embody a new and better theory is to attend carefully to anomalies. Great product creators notice. Consider again the pattern I gave above: there needs to be an insight manifested in the product (i.e. available to the users not just the creators) that relieves tension because it addresses previously ignored anomalies. The best way to get there is for the product creating team to be sensitive to and documenting anomalies in the dominant products. In other words, if you are a good product visionary one of your habits would be to know what are the current best products and to be able to detect and introspect about the anomalies that exist with them. This is a rare skill. Going back to Uber: almost no one was detecting the anomalies mentioned and attending to them for a prolonged time within the focus of their inner world. Building this skill (or habit perhaps) seems possible. Ken Kocienda wrote about how an attention to experience and aesthetic was part of the core group at Apple under Steve Jobs, but also how this group was cultivating as much as selecting for these attributes in their team.

Footnotes

How to Read

Tip 1: Prioritize Reading

By far the most common defense I hear for not reading is a lack of time. I find this unbearable as an excuse. Here is the thing: we all have access to the same amount of hours in a day. If you aren't reading, you are doing something else. That makes it a prioritization question not a supply-side constraint. What is the correct amount of priority to give to reading? Given that we don’t know what we stand to learn from reading, I suspect this is some form of explore-exploit optimisation problem. Exploiting would mean riding on what you already learned, exploring means taking the risk of investing time to possibly improve your base of knowledge. I'd favor exploring based on these factors:

1. The volume of opportunities left to use new knowledge, i.e. your life expectancy.

2. The frequency at which you contact improvements on your mental models, on the assumption that lived experience is a kind of a sampling on the world in which any sign of inferior knowledge is simply the tip of the iceberg.

3. The direct loss you'd experience from foregoing the least-beneficial time usage in your agenda.

Yep, that last point is the one that hits. I'm not saying to read a book when your child is taking their first steps: I'm saying to do it instead of scrolling Facebook, watching Netflix, playing PS4, or tweeting.

Tip 2: Use Blocks and Scraps of Time

When you read for an hour straight, that is a block. When you read while you pee, that is a scrap. These two time scales lend themselves to different reading tasks, but are both usable. Reading for a block both allows and demands greater focus. Long form argumentation, highly referenced writing (i.e. with footnotes or links), or descriptions of systems are all good examples of what I think suites block reading. Narratives, short-form argumentation, current events (news articles), and spaced repetition memorization are good uses of scrap times. The worst thing you can do is to take a block of time and shred it into scraps by avoidable interruptions. When the block begins, pause the mobile phone notifications and go to a place where people won't come tell you something funny. As in all things, we battle ourselves here because the mind often wants to experience the rush of a task switch instead of the deep focus. Blocked time reading is one more way in which you gain mastery of your inner world.

Tip 3: Read for the Delta

The first book you read on business strategy will be entirely new ideas for you. You'll come away with a totally new mental model of strategy. The second book has roughly a 50% chance of having the same effect. The third book has about 33% of revolutionizing your view, and so forth. Reading more and more on a subject will have a diminishing return on what you learn. If you are astute in how you sequence your reading, it may be an incredible drop-off rather than a logarithmic curve.

This does not mean one should abandon new reading in a topic, but that one must approach it differently. In effect you begin reading for the delta, the additional lift of insights. That means skimming much of the rest.

Here is a quote from someone who tried this kind of reading style for the first time¹.

The experience was fascinating. I found myself flying through the pages, skimming whole sections, writing some off with “ok, this is covered ground, I know about this, let’s move on.” I finished the book in four hours. The experience quickly became about identifying the ideas that were novel in the book, that hadn’t been covered by the other authors I’d already read.

In other words, reading this way becomes about the delta — the contribution to existing knowledge that the book represents. You ignore everything else that you already have in your head.

If you read for the delta you should embrace some key best practices:

1. Ignore the author's chronology. Read the ending first (if its a narrative), read the table of contents, read online summaries or reviews. Your goal is to get to more delta in a fixed period of time by allowing yourself to skip or skim. Skipping or skimming doesn't just mean fast-forwarding through the reading like a VHS tape. You can jump around as well.

2. Keep your reading concentrated on a topic until you are struggling to find new delta of insights. Typically that means you are going to execute some form of a “learning spike” on a topic, and then back off in favor of some other topic.

3. The clearest gains in finding delta is to take the concept into your construction of a reading list. Sequence matters so much because some improvements will be additional and others change the foundations of your understanding of the topic. Start with the foundational texts and then go to the clarifying or nuanced extensions.

Tip 4: Cultivate Reading Relationships

It seems unlikely that surrounding oneself with those who do not read often will lead me to reading more. I won't abandon good relationships over this, of course. But friends who are avid readers are a huge boon for both motivation and for reading list recommendations. In the last year I've had many great interactions with friends like Märten Veskimäe and Nick Poels that centered on our reading. While this may be prone to serendipity, it is at least possible to attend to mentions of reading in general conversation, to follow-up when good reading is mentioned, and to make what and how one reads a valid source of connecting with those we spend time with.

How to Retain What You Read

Tip 5: Pay Attention

The current thinking in theory of mind is that our consciousness acts as a sort of workspace in which information can be placed for further consideration. Not all information coming to us is placed there. If you have ever driven a car on the highway you'll have had the experience of cruising along, your mind focused on an email or your finances, and then your heart skips as you see red brake lights ahead. Instantly you are fully concentrated on the road ahead, the pressure in your feet, the tensing of your jaw. The moment before you were driving but not conscious, the next you became conscious. Complex tasks need not occupy our minds.

If you read a lot, you may begin doing so without consciously attending to the text. This is a mistake, though in the moment it may feel efficient. Attention is to the inner world what action is to the external one. Without this attention to the content reading becomes a shallow way to kill time. Only with attention do we stand a chance to retain what has been learned (almost by definition, because we cannot retain what was not experienced).

Tip 6: Take Notes

Your mind's short-term memory is very limited. Your long-term memory is hard to write to. To not be constrained by these two limitations one should take notes while reading. These notes act as an external mind that you optimse for storing, tracking, and retrieving the information related to each thing you read.

Notes serve many purposes. For example, there is an inverse relationship between what your mind can attend to in the next sentence and what facts you are trying to retain in your short term memory. Taking notes allows you to safely release that short term memory and be in the moment to attend to the next sentence. Taking notes now enables you to be present next.

There are many note taking systems or approaches, choosing one seems like a personal decision. But note taking tends to be for three purposes², all of which may be pertinent while reading.

1. Notes to boost creativity. These will attempt to generate ideas and preserve them.

2. Notes to retain knowledge. These offload key information from our memory.

3. Notes to deepen understanding. These synthesize, recast, compare, or reason on a whole gestalt of a subject.

Reading is best retained by taking notes for any or all of the purposes above. What you do with those notes is to organize them into your personal theory of an area (see tip 7) and to memorize them (see tip 8).

Tip 7: Develop Your Own Theory for the Domain

The culmination of all this reading, I believe, is a cohesive theoretical understanding of a topic. Lived experience matters here: what we hear, what we saw, how we behaved and how others reacted to it, etc. But an astounding amount of an expert's knowledge (at least in product management in logistics tech) comes from reading. For myself, I build something akin to a private Wikipedia or other reference for the most important domains of knowledge in my life. I have them for product management, entrepreneurship, sports performance, and so forth.

These conceptual castles exist both in my mind and in my notes. In some way they remind me of architectural documents and physical buildings. The building is my mind: it bears the weight and weather, its where reality occurs. Some of my mental model must be readily and robustly available, i.e. I need to be able to make decisions without reference to my notes. But like a real building, much is hidden from view or hard to access. For these elements we have blueprints, they are complex to read and take more effort. They are also definitive, unlike our cursory check.

On a topic I care deeply about, like product management or business strategy, the mind-note system allows me to balance being quick and being complete. The key is that the theory this is containing is one of my creation. Sure, if I've done almost zero reading or reflecting then the theory must reflect that of someone else. But in time I'll collect points in a way that differs from the next person, and in the process create something both more applicable to my life and also internalized (the mind side of the system can carry more of the information because, for some reason, we're better at remembering our own conclusions than those of other people).

Tip 8: Memorize What You Read

The most direct answer to how to retain what you read is to simply memorize it. I approach this in two ways. The first is to remember where to find something. This provides very high compression on the text to remember. For example, I may read the excellent business strategy book “7 Powers” and decide that I'll not try to remember its definition of business strategy but rather that it had a good one. Therefore I simply remember “For a good definition of business strategy, go back to 7 Powers". That compresses perhaps 50 pages into one sentence. Neat right?

The downside is that to use the information I'd need to take the time to re-read the book (or my notes on it) and load them into my working memory. Essentially by remembering just the path to the information I make myself slower to be able to use the information and also less likely I can form complex relationships between it and other things. If you have ever learned a second language, this approach would be akin to telling yourself you will go look up every word in a sentence as the way to avoid memorizing vocabulary. It works fine for 1 word in a page, it slows you down if its a word per paragraph, and you'll simply be unable to proceed if it happens with every word.

Which leads to approach #2: memorize small units of text verbatim. I do this using spaced repetition, and recommend that approach as a good one. It works as follows. As I read, I note down excerpts of high value. These are made into a deck on the application Anki (an old-school open source spaced repetition tool). Then I study from Anki daily. The view below shows an example of a card that has an excerpt from High Output Management by Andy Grove.

You can see at the top a prompt, I think must answer it in my mind and when ready I reveal the bottom half. Depending on how easy I found the recall of the text I can click a button to schedule when I will next see the text. The more I have marked a text as easy, the longer out in time until I next see it. Many of my cards won't be seen again for >3 years now. This is how you can continuously build a body of memorized passages from your reading without dedicating a larger and larger amount of time. Spaced repetition pushes the reminder out in time, making the total time needed each day roughly constant. And its a great use of scrap time.

Am I saying you should go memorize text verbatim from books and articles? Yes. Do it smartly of course, but don't ignore the most direct means of retaining your reading just because it sounds effortful.

Recommended Reading: Product Management

I thought I'd close this article with an example of my suggested reading for the area of product management.

My Theory

As described above in tip 7, good reading culminates in a theory over a domain. The theory is obviously going to be too much to share in a few paragraphs. So let me just share the highlights of how I see the subject of product management.

Product management is one of the most impactful roles at a software company because it is a singular role. Whereas almost every other role is scaled in headcount, product managers need to retain a single decision making power. A lot is bet on their ability to correctly decide what is to be done with the product. Their output is mostly prioritisation, by which they attempt to capture a market opportunity via changes in the product or how the product is brought to market. Their skillset needs to be wide ranging, but includes at least:

• Market analysis & sizing

• Competitor analysis and strategy

• Financial acumen, especially in terms of value creation for solving market problems

• Product pricing

• Sales and marketing

• Software development and delivery (DevOps when selling SaaS)

If we had to boil down the art of product creation to its essentials, product management probably requires designing a business around three decisions (all of which manifest into product choices):

1. Market selection. This matters because it defines how large a product's business can become and how much competition it will face. We want to attack large, low competitive markets.

2. Value creation. All the work in product-market fit, customer satisfaction, etc, amounts to ways to ensure the product creates meaningful value for the world.

3. Value extraction. Products can be valuable without being able to share in the value created. The innovation of a business model so it earns higher margins than competitors is a separate dimension from value creation for the customers.

In brief: great product managers will find large markets, create valuable products, and erect barriers that allow them to earn higher margins than competitors for a long period of time.

My Reading List

The excerpt below is an example of how I manifest delta reading (tip 3) into notes on my theory of the domain (tip 6). For some reason Substack doesn't like a huge table in a post, so to get the full recommended reading list see my Notion page here.

What I am doing here is listing key topics a product manager will face, a small statement or two about what I consider to be the general answer to that challenge, and then references to work works where I found that principle. There is a path dependency at work here: I would make no link to it if I read a new book but find only support for what I already believe. That is why some of the titles may come across as old standards for the field: they came first chronologically for me (and the world). A good example of this is the two books Continuous Discovery Habits and Lean Startup. Lean Startup covers 90% or more of Continuous Discovery Habits. Only a few points from the later book added to my theory of the domain, hence its less referenced in this list below³.

A Note on Reading Business History

What doesn't fit into a reading list as structured above are histories, where the point isn't to have an answer to a specific problem but rather to have an awareness of what can and has happened. Nonetheless, I absolutely love reading (or recently, listening⁴) to business history. I recommend it for the following reasons:

1. You are joining a game that is already in play. By learning the history of business it will be much easier to understand both what kind of business events are possible and why certain behaviors are done today.

2. Business history is crucial because you realize how immature business really is. Things that just strike us as obvious, such as rewarding staff who produce more per unit of time, or that breaking up complex processes into steps makes them easier to staff: these things didn’t exist about 100 years ago. That's thousands of years without what, to us, looks like inventing the wheel. By learning the history of business one cannot miss the fact that we too will appear frankly stupid to those who come just some decades in the future.

3. Histories give also a context of how principles work or fail when in execution, sometimes a key lesson. This compliments learning the principles to begin with.

I take the view that if I could read the histories of the 100 most notable companies of the last 100 years, I'd be immensely better as a product leader for it even if it wouldn't add a point in my reference list of product management topics, not change my theory of the domain.

Footnotes

1. This is a good narrative of someone trying the reading style described as delta reading

2. See this great introspection on note taking

3. I get the joke that I've sometimes listed myself in the reading list. Frankly I consider this to be not so egocentric as it appears. What this tells me is that my own developed theory on the topic is what I should go back to if the question arises. It doesn't mean I'm the authority for others per se, but that a future version of Jonah should say “oh, you spent a great deal of time thinking about that already. Go refresh yourself on what you wrote at the time".

4. The podcast Acquired is essentially a catalogue of multi-hour history lessons on named companies. Amazon, Wal-Mart, Sony, TMSC, Standard Oil, Enron, and so forth.

5. Again if you missed it, my full product management recommended reading is here.

Many people are wondering how the failure of FTX, Sam Bankman-Fried, and crash of cryptocurrencies in general will impact the related domains of web 3.0 and their forays into logistics or supply chain. Well, it sure isn’t going to help. But maybe it won’t matter much either. This article will try to outline what are the related logistics or supply chain tech startups and what impact the FTX blow up will have on them.

To get a running start at assessing the impact of the FTX scandal, let me explain the kinds of logistics and supply chain tech where the base technologies comes from crypto-currencies or related concepts:

1. Ledgers of events and their related smart contracts

2. Decentralized finance, mostly for payment methods

3. Tokenization and property rights of data

Ledgers of Events

The OG ledger is the decentralized trustless proof of work blockchain that was conceived of by aliens an untraceable genius: Bitcoin. Since then many other approaches and protocols appeared, some specific to supply chains. In effect they all act as a database for supply chain members to read or write to, but with some novel qualities your usual Microsoft SQL server would provide. These can be trustless, distributed, programmable with self-executing follow-up actions when a given data pattern is received (i.e. smart contracts), immutable, or fully transparent. While I can appreciate the theoretical usefulness of these aspects, they come with some costs. The most well discussed costs are energy use (Bitcoin mining is beyond the electricity usage of a major country now), and speed (writing new facts to these kinds of databases is incredibly slow in comparison to that old Microsoft SQL server). I’ll also say they just don’t seem that useful for supply chain or logistics problems. Every attempt I’ve seen at using these blockchains in our sector has looked like a solution looking for a problem. Databases are not the bottleneck for our woes, so novel databases are unlikely to unlock anything.

Decentralized Finance

Money can act as a medium of exchange, a unit of account, and a store of value. No real supply chain wants to store its free cash as crypto-assets, or use crypto-assets in its price lists, purchase orders, or accounting book keeping. But its just conceivable that some will want to use crypto-currencies for payments. This is not a first world problem, rather a way of dealing with otherwise negative aspects of currency controls, local inflation, or lack of local payment processing. There is a >12 month backlog on FX transfers out of Nigeria. Argentina imposes mandated FX rates. Even Greece (within the EU) has enacted currency controls in recent times of political turmoil. Large corporates often won’t go to the extreme of crypto solutions, but small and medium sized suppliers absolutely do so. My sense is that novel payment solutions via decentralized finance is a place where supply chains may indeed use some of the technical innovations from the land of crypto. But two things still make me bearish on this topic. First, this isn’t really supply chain tech this is decentralized finance tech (DeFi). We’re a use case, not the home sector. It will also be used for all sorts of other payments categories and succeed or fail regardless of supply chain and logistics applications. With the retreat of globailization, supply chain may even be a less attractive area of focus. Second, this is most valuable when its most explicitly about breaking regulations. While I would unbearably angry as a business owner in a country like Turkey, Nigeria, Argentina, or Greece when these governments follow their own failures with interfering in currency flows: eventually regulation will catch up and find ways to block these mechanics like they do the main currency flows via banks. Finally, this stuff is still as risky as the players who operate it. As the FTX blow-up shows, unregulated means unregulated.

Tokenization and Data Ownership

Tokenization is the process of exchanging sensitive data for nonsensitive data called “tokens” that can be used in a database or internal system without bringing it into scope.

This direction of research that would make tokenized data scarce, like physical goods. It would allow a digital object (for example, my RFQ results for an ocean transport procurement event) to be transferred between parties or used in a way that prevents duplication in effect. This sounds odd, because the whole idea of data for the last generation was that its infinitely reproducible. I can make a billion copies of a GIF like rainbow cat and they never differ from the original, nor impact the quality of the original. Tokenization makes such images a bit like the shoes I’m wearing. I can pass them to you (but then I’m bare-foot). That’s what we mean by making the data scarce like a physical asset.

Okay, who cares? Well, there is a line of thinking that this makes classes of data more valuable, and more valuable resources tend to lead to more effort to harvest said resource. In a logistics context it may be that companies will do more to capture, quality-control, and make available data if they know that its scarcity ensures they can earn more from it. Some other use cases would center on the fact that data control ensures capturing and sharing data doesn’t risk losing it forever. Back to my Ocean RFQ data: I might lend this data to a consortium for benchmarking but in a way that they relinquish it afterwards and I’m sure it could not be simply copied. This may lead (paradoxically) to more sharing, because the risks of sharing can be controlled at finer grain than today. While all this sounds tidy in theory, it tends to break down in the real world. We already have ways of controlling use of data to some degree: contract law and threat of lawsuits. Also, mostly the supply chain problems are still with data capture and quality, not in the economics of sharing. But I can see this may eventually produce interesting solutions (maybe decades from now).

So, What's the Impact?

With those three areas of crypto-tech being explored for supply chain management, what does the FTX blow-up mean for logistics tech? I’m going to argue it doesn’t mean much, because the related technical innovations weren’t getting traction anyway in supply chain. Those companies (or big corporate pet projects) will be a bit harder to fund or market. But the appearance of cost of capital via inflation pushing up benchmark interest rates was already moving most of these things into hospice. It’s all well and good to work on the far future technologies when cost of capital is zero and a billion dollars of revenue made in 20 years is worth the same as a billion invested today. But rate hikes have made waiting for payback unacceptable again: gravity is reasserting itself and blockchain or tokenization logistics tech ideas had their days numbered. Their disappearance may be sped up by the FTX crash but I don’t think they’ll even notice.

You might see Sam Bankman-Fried as a modern Icaraus figure: endowed with an incredible gift, laid low through his ego. So I'll close with a reference to W.H. Auden and how he described bystanders watching the fall of Icarus:

everything turns away quite leisurely from the disaster; the ploughman may
Have heard the splash, the forsaken cry,
But for him it was not an important failure; the sun shone
As it had to on the white legs disappearing into the green
Water, and the expensive delicate ship that must have seen
Something amazing, a boy falling out of the sky,
Had somewhere to get to and sailed calmly on.

Background Notes

1. Maybe the easiest way to title logistics tech articles is to borrow titles from awesome Nigerian magic realism short stories.

2. Background to all this is knowing that a cryptocurrency exchange called FTX blew up in spectacular fashion, probably at fault of its creator and general crypto-spokesperson Sam Bankman-Fried, and in doing so its drained even more capital and credibility from the crypto-currency scene. If your prior beliefs centered on “crypto-currency is just toxic garbage”, this sounds pretty reinforcing. But for people who were on the fence or converted to a positive image, it hits hard because the firm had been engaging everyone’s imagination with a picture of responsibility and maturity ahead of its peers. Based on the social proof of the investor list, this was supposed to be a well-run business more or less insulated from the last half year of falling crypto-asset book value. But it wasn’t, so now social proof swings the other way.

3. This is a solid introduction or FAQ about tokenization as it relates to data control.

4. I've been writing about blockchains and the related implications for supply chain since 2014. If you are curious, checkout my early read on using blockchains for supply chain visibility, financial & physical supply chain management, and payment or goods tracking. Virtually nothing has changed about the mismatch between the tech and the industry needs in the ten years since I wrote these pieces.

5. W.H. Auden also said it best about business leaders in general: “They may be useful, but no artist is going to paint them emerging from a lake on the back of a dolphin, nude, shaded by cherubs.” Touché.

Imagine it: you’re launching a new logistics platform startup. Your LinkedIn title says that you're disrupting a trillion-dollar industry. Your company’s landing page says technology is changing the game. The about-us page explains your commitment to sustainable growth, work-life balance, team diversity, and so on in this vein. You give TED Talk style presentations to VCs, listen to the Acquired podcast for business history, read We’ll Be There Soon for logistics insights, and follow Ryan Petersen on Twitter.

Its all been whiteboards and pitching. But now the time has come to price the logistics platform. If this was normal big-ticket enterprise software, you’d use internal guidelines on pricing and negotiate the deals privately one by one. But this platform is going for large scale adoption: you are changing the world after all. That means you are tempted by the typical approach of consumer software and have some public pricing plans that the user chooses from. How to proceed?

The rest of this article is going to explore this question: how does pricing a platform differ from pricing typical enterprise software as a service (SaaS)? In my view, there are important points where they deviate because of:

1. higher potential for demand elasticity,

2. greater importance of customer count,

3. longer expected customer lifetime, and

4. the ability of pricing in one customer segment to impact the other customer segments.

I’ll address each through the lens of specific decisions to make.

Public or Private Price?

Should a logistics platform make its pricing public?

There are two ways a prospective member can pay to join your platform. The first is to check out a clear public pricing page on the website: people can buy via self-sign-up. The second is to be forced to contact a salesperson and go through enterprise sales negotiations. If you hide the price, forcing the buyer to negotiate for a specific agreement, you can execute differential pricing. This can extract maximum revenue per sale: that is the upside. The downside is that such negotiations are slow, expensive, and reduce total sign-ups. Let’s look at these deeper from a platform perspective:

1. Enterprise negotiations are slower than self-sign-up. No matter how you approach it, they add a step in the process. More often they add many steps. As a platform, the number of members impacts the attractiveness of the platform to other members. Being slow doesn’t just shift revenue to the future it lowers the likelihood of ever getting the revenue at all. Bottom line: platform network effects mean you value speed to reach N member count, and therefore should eliminate delays instead of maximizing per-customer revenue.

2. Enterprise negotiations are more expensive than self-sign-up. Not just for the vendor but also the buyer. In SaaS it wouldn’t be unusual to see >10% of first year revenue for a newly negotiated contract paid out as salesperson compensation. We can assume that something like that amount is being dispersed within the buyer to the procurement staff who made the other half of the negotiations. That’s ~20% of the first year’s revenue that was consumed because the vendor obliged a negotiation. I don’t think this amount is more impactful for platforms than for non-platforms but eliminating it would provide room to discount. And that is important because of demand elasticity, discussed later in the article.

3. As a thought experiment imagine a self-sign-up form for Netflix that has, as a middle step, a requirement to get some other person in a different location to login as well and click “approve”. We can assume this doesn’t just slow down the process: it kills conversions. Some prospects won’t want to engage someone else, others will try but fail to get their attention, and many more will intend to but then become distracted. Here is what we know for sure: forcing your potential customers to start formal negotiations will certainly lower total demand for your solution. Like point 1 above, this funnel drop-off matters more for platforms because part of what a platform offers its members is a network effect from other members. If you lose X number of members because they drop-off at the price negotiations step, you also reduce the overall attractiveness of the platform. For this reason it is better to optimize for member count instead of revenue-per-member.

I think these points suggest strongly that logistics platforms should run with public pricing, not privately negotiated enterprise deals.

Share

Will You Serve Tapwater?

What consumption metrics should drive fees for a logistics platform?

Years back when I wrote a guide to SaaS pricing it was about what the total price should be. But that leaves aside an important nuance: on what basis is that total price tallied? Just as every building has a meter tracking its water or energy usage, every SaaS will place a meter on some dimensions of its customer’s consumption so as to justify the price they charge.

We create meters on consumption of SaaS for three reasons:

1. For any business with non-zero incremental costs, fees per cost-adding increment are a defensive mechanism to avoid losses. Example: if you sell transport optimization software then some form of “solve” activity will generate computing costs. If solving doubles, the business has some compute cost doubling, and they need a way to charge fees to recoup this unless they like the calculated risk of covering it from other revenue.

2. When a customer gets more value, the vendor will try to extract more revenue as well. This is value-based pricing, and tracking some metrics of consumption is a proxy for it.

3. Demand is elastic to price model, for the reasons of risk-reward implications and also as a counter positioning to competitors. For example, a “pay if it works” pricing model makes consuming a SaaS product low risk hence it boosts demand. Likewise, if a competitor requires an upfront commit, then a price model that is per-usage brings higher demand (while perhaps not adding demand for the market overall, it gains market share for the per-usage option, i.e. it is effective counter positioning).

The downsides of price models that meter consumption are simply that they can get the tradeoffs wrong. A well-built pricing model links revenue to costs, captures increasing revenue in line with increasing value-creation, and counter-positions to competitors. But by the same token a poorly built model gives unexpected losses, leaves money on the table, and reduces demand for the product.

Logistics platforms have the same challenge to establish pricing models as other SaaS models, but with two additional nuances. First, if you want to execute value based pricing, and platforms add value through network effects, you effectively have a price model that can grow fees based on other members behaviour not the single customer's consumption. Second, platform network effects mean demand elasticity of one member “side” can impact the demand for the other sides. This has unexpected implications which matter enormously in practice. For example: it may yield higher total demand (and total revenue) to create a very attractice pricing model for one side, whose high demand then creates high demand for another membership side, and this second membership side is given a pricing model that captures enough revenue for the platform to make up for foregone revenue from the first member side.

Together, these point to developing a pricing model that is strategically cohesive across members, i.e. not a price model per member class in isolation. My suggestion is a price model creation process as follows:

1. Pick your platform's hard side. For these members:

   1. List the ways that their usage could trigger incremental costs. For each way, add a pricing model metering that charges exactly the expected cost (and no more). This results in pricing model that achieves zero contribution margin percentage. It does not cover fixed costs yet.

   2. In what way would consumption be measurable as a proxy for irreplacable value? This means value to the member of the platform that cannot be captured in some other method (i.e. some other platform, for example). For each pattern, add a pricing model metering that charges 25% of the expected irreplacable value.

   3. Inspect the resulting price model compared to the most important competitor's pricing model. Which model will be most attractive on the basis of risk-reward or time-phasing? If your model is not the winner, is there a polymorph such that the same revenue can be earned per customer but with a more attractive positioning compared to competitors?

2. Having fixed a draft pricing model for the hard side, switch to the next hardest side of members.

   1. Repeat steps 1a, 1b, and 1c above for this member class.

   2. Now, inspect how much additionally this group would pay to boost the size or usage intensity of the other platform members. Find an “willing to pay X to see other member count or usage increase by Y” formula.

   3. Add an additional pricing metering that achieves charging X for Y, and discount the other member's pricing model by X for Y.

3. Repeat step 2 for each platform member side in decreasing order of difficulty to attract to the platform.

While the process is dense to read, it offers a clear way to approximate the usual SaaS pricing but also including the multi-sided nature of platforms and their network effects impacts on pricing viability and demand elasticity. In effect from step 2 onward you have the trigger to assess to what degree one set of platform members will pay to boost the platform's overall membership, and then redistributes this value out to the other members on the basis that demand is indeed elastic to price.

Network Effects on CAC and LTV

How to balance CAC and LTV for platforms?

At its core, business success can be checked with straightforward math:

1. We spend money to get a new customer.

2. Then, we generate a certain amount of money from that customer until they leave.

3. Subtracting the cost of serving the customer, we get an aggregate contribution the customer made to the company profitability.

The first amount is referred to as Customer Acquisition Cost (CAC) and the second amount is the lifetime revenue from the customer which, when subtracting the cost to serve the customer in step 3, is referred to as Customer Lifetime Value (LTV). You want LTV > CAC, and any sane business will track their will track their LTV/CAC ratio. These form the core unit economics behind how accretive new sales will be, and when the customer's fees will overcome the cost spent on everything that went into winning them (i.e. CAC Payback, calculated as the average time needed for the contribution margin from a single customer to equal the CAC).

Whereas the pricing model design described in question #2 is about maximizing contribution margin from each member, the exercise to balance CAC vs. LTV is about optimizing cash intensity. Any LTV>CAC would result in a profitable business in the long term (assuming cost of capital is also factored). But some LTVs are in fact spread over very long time horizons, and hence the sales payback period is years: meaning the company is consuming cash intensively while it acquires customers (i.e. while it grows). Many businesses that grow quickly and have losses are cash intensive simply because the CAC Payback period is large. Uber, Peloton, Door Dash, and Blue Apron are examples of such businesses. Because of network effects, platforms need to treat these CAC, LTV, and CAC Payback metrics more carefully than a traditional SaaS business.

As an example of how platforms have it different, consider a negative LTV/CAC ratio. This would imply we spend more money to get the customer than they will ever pay us in fees. That sounds crazy and unsustainable. But this may be okay (even optimal) for platforms because, again, network effects mean changes in one member side will impact the unit economics for the other members. To estimate LTV one needs to consider the following:

1. The cost to acquire the customer

2. The cost to serve the customer

3. The price the customer pays for the service

4. What services this customer will buy in the future. For example, will they upsell or cross-sell from the current ones?

5. How long they will remain a customer.

6. How much pricing power the platform has on this customer, along with future expected pricing changes (up or down).

7. The customer's influence on all the factors above for other platform members.

Did you see that last line?!

Point 7 means that you cannot really optimise the cash intensity of a platforms business (i.e. its CAC and LTV) without intentionally assessing how the customer's usage or presence on the platform effects other customers.

Wrapping Up Pricing

I'd written years ago about how to price enterprise SaaS, and I believe in the importance of negotiations for maximum value capture in privately priced deals. But platforms seem to be a different beast, and if you are going to play the game on the field you'd be best served to notice key places where traditional enterprise SaaS diverges from an ideal logistics platform pricing strategy. In brief, I called out the following:

1. Put up public pricing and a self-sign-up option. Don't offer or entertain private negotiations: show people an easy way in and reinforce that its indeed the entrance. This is rationale because it increased demand via both lower friction and lower costs; network effects then amplifies the additional demand.

2. Price the hard-side of the platform to zero contribution margin. Then do the same for the other sides, intentionally cannabalizing their network effect demand to discount the hard side. Add a metered pricing that attempts to capture 25% of the unique value created in the platform. This approach achieves both demand maximization and value-based pricing in a complex multi-sided situation.

3. Rather than optimize the CAC against LTV on a customer segment basis, do so on a total platform basis by again engineering maximum use of network effects. Like any optimization process, it seeks minimuma and maxima, hence it will move the member segments apart in hwo they are managed.

Points 2 and 3 above lead to highly asymmetric outcomes for the platform members. I think this will be one hallmark to look for in well planned & executed logistics platforms. At its core, what it derives from is the differential negotiation leverage and desirability of one member group compared to another. These differences can be ignored with poor platform pricing (example: all accounts cost $100 per user), or maximally leveraged with nuanced pricing models.

Wrapping Up the Series

This was the last in a four part series on platforms as a business model for the logistics sector. It connects with a three hour podcast in which I discussed the same topic with my friend Märten Veskimäe. Check out the podcast at Logistics Tribe on Apple or Spotify. If you like this kind of analysis, sign-up to the newsletter.

Subscribe now

End Notes:

1. There are also factors to pricing like billing cycle (pre-pay with credit, post-pay, once per day-month-year, etc). and commit cycle (monthly vs. annual subscription, etc). I leave these out as they seem not uniquely interesting for platform models.

Sources:

1. https://mit-online.getsmarter.com/presentations/lp/mit-pricing-strategies-online-short-course/?ef_id=c:405822195545_d:m_n:g_ti:kwd-309142350858_p:_k:price elasticity_m:e_a:88207152444&gclsrc=aw.ds

2. https://en.wikipedia.org/wiki/Cross_elasticity_of_demand#Potential_strategies

3. https://en.wikipedia.org/wiki/Price_elasticity_of_demand

4. This amazing article on data business models

This is the third in a series of articles on platforms as a business model for the logistics sector. It connects with a three hour podcast in which I discussed the same topic with my friend Märten Veskimäe. Check out the podcast at Logistics Tribe on Apple or Spotify. If you like this kind of analysis, sign-up to the newsletter.

Subscribe now

Ben Thompson as the Aggregator OG

If you are discussing platform strategy often at all, eventually someone will mention aggregators in the same way we might hint to a friend they have something in their teeth. There follows a painful introspection, part of which is going to be reproduced here. An important hallmark of this process is to spend about half the time you have available trying to define these two business models. Then we can decide when to pursue one over the other.

By far the most writing on this topic is by Ben Thompson. I added footnote links for the articles I found the most compelling, but I cannot even be sure I've caught all his articles, posts, and podcasts on the theme. Hat-tip to him for both his original thoughts and the collection of previous thinking on platforms vs. aggregators. Ben's focus is purely on the consumer markets, so he draws on examples like Microsoft, Uber, Bird, Etsy, 1stDibs, LinkedIn, Google, Apple, and so forth. I'm going to end up mostly contrarian to Ben but will do the longform thinking to get us there. He never said it this way, but I believe Ben's five main hypotheses on platforms vs. aggregators goes as follows:

1. The value chain for any given market is divided into three parts: suppliers, distributors, and consumers.

2. The internet age converted previously foundational value chain activities from incremental cost to zero-incremental-cost. For example: infinite shelf space for inventory of e-commerce. This enables both aggregators and platforms. This shifted the balance towards distributors competing on scale of supply or consumer base.

3. While both models achieve supply-demand match, platforms establish means for counterparties to interact while aggregators instead capture one side and become their representative to the counterparty via intermediation. Example: Uber aggregates drivers and the rider buys transport from Uber not from the driver.

4. [Following the view of Bill Gates]: Platforms produce more value for the ecosystem than they extract for themselves, while aggregators extract more than they leave for their participants.

5. In a market where suppliers can be commoditized, the hard side for matching is the consumer. Aggregator business models will win, and in turn extract more value. And vice-versa: differentiated suppliers will avoid aggregators.

Nope. It’s Just Leverage.

Ben's points above (which, again, he makes more verbosely, and I tried to compress) seem valid per se. But I think they miss the right level of abstraction for two reasons. First, he only considered consumer businesses and therefore makes a whole theory for a sub-set of platforms, when in fact there is a more satisfying general theory of platforms. Second, he's calling out outcomes not inputs when talking about depth of intermediation, commoditized suppliers, and technology enabled zero-incremental scaling costs.

So here is my take on platform vs. aggregation in three hypotheses:

1. Platforms are intermediary businesses: they enable interactions of counterparties (i.e., the platform members).

2. Those members have different levels of leverage in their value chain, sometimes altered by the arrival of the intermediary. Leverage here can be thought of like negotiation leverage: it comes from their BATNA.

3. The optimum (or even viable) platform will manifest the leverage the members. In some cases, the leverage means no viable platform is possible or desirable.

So, let's unpack this abstraction…. The first claim is straightforward: platforms need “sides” on them, i.e., the counterparties to whatever interaction the platform helps make possible. Tinder doesn't date you: it helps the boys and the girls find each other (or whatever sexual orientation permutation you want to use).

The second hypothesis is where the fun starts. When I read Ben Thompson, I think he dances past the blindingly obvious fact that platform members will have negotiating leverage in their value chain. This is where a general theory of platforms starts to make more sense than Ben's consumer-focused one. Anyone working in B2B knows the asymmetry of leverage in value chains. I wrote in 2010 about how supply chains almost always end up coordinated by a strong anchor member rather than via federation of equally strong member companies. Twelve years later this is even more common. What Ben's focus on consumers does is to treat the demand side of the value chain as a given: a vast pool of anonymous demand in which only desires and user experience are considered, and no agent-principal conflicts can occur. That's not going to work for B2B platforms, but perhaps more importantly it won't always be true of consumers either. Technology, regulation, economic conditions, or demographics may warp how much leverage consumers have the in the value chains their anchor. By skipping them as an object of assessment, Ben's model may not even work for all B2C platforms.

The third hypothesis is where I assert a simpler explanation for the platform-aggregation dichotomy. Business models tied to intermediation will need to be accepted by the counterparties they intermediate: no one can simply force intermediation on existing markets. Although intermediation tends to alter the leverage of the existing players, there will still be variations in who has the power even post-intermediation. Owing to that leverage, to the extent that a platform's success or failure can be determined by one of its members, then that member's interests will be imposed in the resulting business model. Finally, this brings us to the crux: at the extremes of resulting leverage (post-intermediation) you have non-platforms, while in the middle you have platforms of various degrees of concessions to keep members onboard.

The image above suggests there are three zones for an intermediating business:

1. Let's call the first possibility “aggregators” to justify the fact we spend so much time on definitions. The hallmark is that the intermediator becomes a counterparty, de jure or de facto. These business models emerge when intermediation results in extreme weakness of one group of members. Because the group is so weak, the intermediating business does not have to give them concessions in the business model. The result is an intermediating business that is too directly involved and strong to make sense as a platform (where some degree of neutrality is expected). A handy example that comes to mind is Uber in ride hailing. You'd be hard pressed to say they aren't simply in the value chain as the counterparty instead of a platform helping riders and drivers find each other. Bottom line: weak members as an input means platforms just become value chain members and direct counterparties. This also leads to seizing more value as the intermediary, since doing so is possible and desirable.

2. The second possibility is that the intermediary is facing counterparties with enough leverage to command some concessions on how the business model works. A site like YouTube faces powerful members on all three sides (consumers, content creators, and advertisers). I'll talk more below about how these dynamics play out, especially in logistics (since that's ultimately what I'm focused on). But for now, let's just say that with limited leverage I think members tolerate platforms as a viable intermediary model, and would essentially block the arrival of aggregators who attempt to act as the counterparty.

3. The third possibility (and frankly the default in B2B) is that the intermediation fails because some segments of the required counterparties are powerful and can veto its arrival. Sometimes they'd block an intermediary instinctively, or out of inertia. But often it’s because everyone at the dinner must eat, and an intermediary's value just doesn't seem worth keeping them fed. As an example: discount airlines like Ryanair or EasyJet blocked flight searching websites.

The Goldilocks Zone Theory of Platforms

As said above, I think there is a viable space for intermediation by a platform when the members have some leverage, neither too little nor too much. But the zone is large enough that specific mechanics will emerge to reflect these power dynamics. Or, put another way, successful platforms optimize for member leverage differentials. I think this manifests in the choices platforms make in the following dimensions (among others, since this isn't exhaustive):

• The standards definition (what data can be shared; what actions can be taken)

• The depth of intermediation (i.e., catalogue, search, recommend, or assignment)

• Whether intermediation occurs in payments or not

• Pricing model for the platform (what's free, what's charged, how is the charging metered, etc.)

• Arbitration power for disputes

So, for example, a platform like LinkedIn is a platform for three member groups: professionals, navigators, and advertisers. Professionals seem to me to have the most leverage. Even if a small (but highly sought after) group were to abandon LinkedIn, this would endanger the platform health. That leverage manifests itself in decisions like the free-to-use commercial model, the fact that we can find each other by name search (rather than just recommends, or email lookup, for example), and dispute resolution that errors on the side of not bothering the professionals. Navigators (i.e., recruiters or salespeople who are looking for leads) have less leverage. A much larger number of them must leave before platform health declines. So, the platform optimizes a bit further away from their interests: this group pays for access, they are rate limited in the number of new contacts they can make, and they can be throttled further if they are seen as bothering the professionals. What we see here is that an optimal platform is making specific design choices about its mechanics and business model based on the leverage or power of those it’s trying to intermediate. Ignoring these factors results in worse platform adoption, lower value extraction for the platform operator, and risk of an alternative platform that better reflects the situation on the ground.

Let's Talk Logistics

The aggregator vs. platform question seems simpler to me in logistics than in other domains. Logistics has had 3PLs (also called forwarders, also called brokers) as its traditional label for aggregator. These roles are even codified in laws: someone is the party who will transport (and is licensed to do so), someone else can be licensed to arrange the transport, someone else may be licensed to clear customs. If you are an aggregator, it’s you who takes that activity and its inherent risks, however you accomplish it is a secondary question. Platforms, meanwhile, cannot take these roles. FlexPort is an aggregator from any angle you look, while GT Nexus is a platform. And as new platforms emerge or are considered, I think most of them can be assessed from a leverage perspective quickly. Let me give a few examples.

Logistics platforms will tend to deal with one of the following business processes: transportation, warehousing, customs clearance, repackaging, installation / stocking, material movement planning, material tracking, and invoice to payment. And the parties to these processes are a mix of cargo owners (sometimes split between the buyer and the seller with ownership switching during logistics events), logistics asset owners & operators, 3rd party logistics service providers, financial institutions, government agencies, and technology providers. And given logistics is physical: local variations will matter (India vs. Europe, etc.). Each of these intersections of process and parties should immediately suggest a degree of leverage in the minds of someone experienced in this area.

Above all, a dominant theme in logistics platforms and the leverage of their members will be the degree on market concentration. In simple terms: logistics is mostly a sector of small companies with tiny market share. Half of logistics expenditures are on trucking (about $1.6 trillion USD per year out of ~$3.2 trillion for all of logistics of any kind). But the largest trucking companies are tiny, say ~$4 billion in relevant revenue. In logistics $4 billion in trucking revenue sounds huge. Its half as much money as Sony made on just PlayStation hardware last year: and they were loss-leading on those devices just to sell the much more profitable games. Bottom line: in a huge market (trucking) if there are only tiny players then it indicates that no one has found a true economy of scale advantage and that platforms likely can treat the providers as having little leverage.

There are still variations of leverage. How many trucking asset operators do you need on your platform to cover 80% of world volume? Millions. How many are needed for 80% of ocean container shipping? Less than 100. And how many are needed for 80% of parcel? Less than 10. What I think this tells us is that a platform won't be likely for parcel (the parcel providers are too powerful, they could essentially veto it and will do so). A platform is possible for ocean but will have to concede some aspects to the desires of the asset operators. And a platform for direct truck operators is less likely compared to an aggregator since they are so weak (commoditized) that any intermediary business will tend towards being less neutral and more directive.

Obviously, platforms have other sides to them: the cargo owners, the technology providers, the 3PLs, etc. Each side must be assessed as above. How many (non-asset operating) 3PLs are needed to cover 80% of the world market? I guess it is under 10k. How many Transport Management System vendors? I'd guess under 20, but per regional market that's probably under 10. This would tell me that a platform that has TMS vendors on one side would find it harder to accommodate their leverage (due to concentration) as compared to a platform that had 3PLs as a side.

Once we eliminate the edges and focus on the goldilocks zone, I think logistics platforms start to enter the fine details of optimal user experience, data models, integration formats, pricing, and so forth. For example, any ocean transport platform will need to acknowledge the leverage of the ocean shipping lines (Maersk, etc.) and build around their old and clunky systems for status messaging through EDI. Its 2022: any sane person would be building to RESTful APIs or GraphQL. Nope, one side of the platform will have the leverage to insist on using 30-year-old EDI messages. The same would occur in financial flows that touch USA banks. While New Zealand and now Europe have much more cost effective, fast, and reliable routing via SWIFT you'll be forced to bow to the leverage and support stuff that was devised in the era of paper checks. These are the quid-pro-quo of bringing powerful sector participants onboard. Good product managers or business leaders at the platform operator will assess and steer the platform accordingly.

Summarizing

It is good to learn from the consumer platform space (where many, many more success stories exist than in logistics). In those discussions you'll find this “aggregator vs. platform” debate. Instead of losing days of time sleuthing around, I'd propose to cut the debate short and say that platforms must optimize for the relative negotiating leverage of their constituents. If that power is too large, platforms may not be viable because a platform is an intermediary and the powerful won't allow an intermediation in their value chain. If the power is too low the would-be platform is drawn into simply taking a direct position, in effect capturing the role and value of the weak party while making them a commodity. In the middle is a goldilocks zone where somewhat powerful members will tolerate a platform if it concedes where needed to keep them interested. All of this is abstract. But I think this is a novel and powerful theory for platforms for two reasons:

1. It helps rule out platform businesses on the grounds that the members have too little or too much leverage. Instead of platform business models, these should be aggregators or simply not pursued, respectively.

2. In the goldilocks zone, it reminds us that we're optimizing for the leverage of the platform members as much as for the total value created or extracted.

Anyone in logistics will see the negotiating power disparities of our sector's major players. This directly leads to the viable or ideal form of intermediation, and then when pertinent on to finding what a group expects as a concession in order to play ball on a new platform. That's the thing to add to your mental toolkit if you are making, investing in, competition against, or considering joining a logistics platform.

In case you missed it, check out the first two parts of this four part series on platforms for the logistics sector:

We'll Be There Soon

When Scale Matters

This is the first a series of articles on platforms as a business model for the logistics sector. It connects with a three hour podcast in which I discussed the same topic with my friend Märten Veskimäe. Check out the podcast at Logistics Tribe on Apple…

Read more

4 years ago · 4 likes · 4 comments · Jonah McIntire

We'll Be There Soon

Standards & Intermediation

This is the second in a series of articles on platforms as a business model for the logistics sector. It connects with a three hour podcast in which I discussed the same topic with my friend Märten Veskimäe. Check out the podcast at Logistics Tribe on…

Read more

4 years ago · Jonah McIntire

Sources:

https://abovethecrowd.com/2012/11/13/all-markets-are-not-created-equal-10-factors-to-consider-when-evaluating-digital-marketplaces/

https://stratechery.com/2018/the-bill-gates-line/

https://stratechery.com/2018/the-moat-map/

https://stratechery.com/2015/aggregation-theory/

https://stratechery.com/2017/defining-aggregators/

https://stratechery.com/2019/a-framework-for-regulating-competition-on-the-internet/

https://stratechery.com/2019/shopify-and-the-power-of-platforms/

https://medium.com/adventures-in-consumer-technology/threes-company-of-shopify-amazon-and-etsy-4f0388c47c91

https://medium.com/supply-chain-visibility/iron-fists-and-supply-chain-utopias-governance-and-visibility-60771452d076