Over the last five years, I’ve been rebuilding the Business Engineer curriculum from the ground up.
The Business Engineer, a concept I first introduced in 2018 as a spin-off of my research at FourWeekMBA, had become, in my mind, the defining discipline for the digital business person. But as AI became increasingly central to the technology landscape, another shift became impossible to ignore.
A large part of that shift was about the buyer.
During the digital era, it was possible to build highly valuable software companies by obsessing over UX, narrowing the scope of the application, and distributing software to millions of small businesses and individual users. The economics made sense: standardize the product, reduce friction, and scale distribution.
AI changes that equation.
The small business may increasingly be able to vibe-code its way through much of its own software stack, assembling and customizing applications around its specific workflows rather than buying dozens of rigid SaaS products.
The enterprise sits at the opposite end of the spectrum.
Large organizations have the budgets, complexity, proprietary data, regulatory constraints, and operational depth that make customization not merely desirable, but necessary. They are willing to pay to adapt AI systems to the core of how their businesses actually operate.
Software, once again, is changing definition. I explore that transition in greater depth in the other books in this series.
But one consequence is already clear: the enterprise buyer has moved to the center of the AI adoption race.
And that is why it deserves a book of its own.
Buying enterprise AI is difficult for a simple reason: the vendor usually has far more experience selling this kind of system than you have buying it.
Imagine an insurer evaluating an AI system for claims. The claims team may buy one serious AI platform this year. The vendor may run fifty evaluations across insurers, banks and healthcare companies. It already knows which demo gets executives excited, which objections procurement will raise, which security questions arrive late, which pilot metrics are easy to pass and how far it can move on price before the buyer walks away.
The buyer has different expertise. The claims leader knows claims. Security knows security. Procurement knows contracts. Finance knows the budget. But nobody in the room may have seen twenty claims-AI deployments go from impressive demo to messy production.
That matters because AI is unusually easy to make look good before production. Suppose the vendor demonstrates the system on twenty claims it selected itself. Eighteen are handled correctly. The demo looks excellent. But those twenty cases tell you almost nothing about what happens when a scan is missing a page, two policy clauses conflict, a claimant gives contradictory information, the retrieval source is stale, the underlying model changes next month, or the case falls into the strange five percent that consumes half of your adjusters’ time.
Traditional software was easier to inspect. If you bought a CRM, you could verify that the workflow existed, permissions worked, the integration connected and users could complete the required actions. AI behaves differently. A system can work on the vendor’s examples and fail on yours. It can change after a model upgrade. It can become expensive when power users begin using it seriously. It can also improve from the cases, corrections and decisions your own people provide.
So change the order of the purchase. Do not begin with the demo. Begin with your work.
If you are buying an AI system for claims, give every shortlisted vendor the same real claims and have your senior adjuster define what correct looks like. If you are buying an AI support agent, test it on the tickets your best support people consider difficult. If you are buying an AI contract system, include broken scans, unusual clauses, amendments, missing pages and the exceptions that actually consume lawyers’ time.
Then measure the result yourself.
The vendor should not choose the exam, write the answers and grade the paper.
Your company needs to own the exam.
The same principle applies after purchase. Imagine that after six months the claims team has produced eighty original test cases, two hundred failures found in production, hundreds of adjuster corrections, escalation rules and a record of which decisions led to successful recoveries. That material now describes how your company performs part of the work.
If it all lives inside the vendor’s system, leaving becomes expensive. If you own it in portable form, the vendor becomes much easier to replace.
Three questions should therefore sit underneath every material AI purchase:
Does it work on our cases?
What do we become dependent on?
What do we still own after a year of using it?
Everything else follows from those questions. The demo earns the right to be tested. The pilot produces evidence. The contract decides ownership and change rights. The renewal asks whether the evidence still justifies the dependency. The exit plan matters because a clause saying you may leave is useless if leaving requires six engineers and nine months of rebuilding.
Own the test. Own what the system learns from your work. Know what it would cost to leave.
For the last three years, I’ve been rebuilding the Business Engineer’s curriculum from the ground up. That curriculum has now become the foundation of a new discipline, with the entire series taking shape around it.
If you’re already a paid member, simply reply to this email, and we’ll send it your way.
