Two AI business cases walk into a budget review. The first is an eighteen-month NPV model: adoption curves, productivity multipliers, a sensitivity analysis nobody believes, and a payback date conveniently past the next reorg. The second is a proposal to prove the thing works — on your real data, in your real workflow, with your real team — in ninety days, with a number attached that either moved or didn't.
CFOs have seen a decade of the first kind. That's why the second kind wins. After enough AI line items that produced decks instead of decisions, the only business case with credibility left is the one that's falsifiable on a calendar.
Why ninety days, specifically
The number isn't arbitrary. Ninety days is long enough to reach production — real data access, real integration, real users — and short enough that nobody can hide inside the timeline. It's a forcing function. Scope that can't survive it gets cut, and the scope that gets cut first is almost always the scope that was decorative to begin with: the second dashboard, the speculative integrations, the model comparison bake-off nobody will remember.
The discipline matters more than the duration. A bounded proof commits to three things up front: which decision gets faster, what data it runs on, and what number tells us it worked. If any of the three can't be named in the first week, that's not a proof taking shape — it's a pilot, and pilots are where enterprise AI ambition goes to die quietly.
The anatomy of a bounded proof
Weeks 1–2: real data or nothing. The first fight is always access, which is why it has to be the first fight — not the week-nine surprise. If the organization can't grant governed access to production data inside two weeks, that finding alone is worth the engagement, because it means every future AI initiative pays the same tax.
Weeks 3–8: build inside the existing workflow. No new portals, no new logins. The output lands where the decision already happens — the ticket queue, the spreadsheet, the chat channel, the Monday review. Every new tool a proof introduces is another adoption bet stacked on top of the technology bet, and the adoption bets are the ones that fail.
Weeks 9–12: production, measured. Not a demo — the real loop, running on live data, with the metric that was named in week one now on a chart: insight-to-action time, cost per decision, cycle time from event to response. The proof ends with a number and a choice: scale it, or kill it with confidence. Both outcomes are wins. The only losing outcome is "let's evaluate for another quarter."
The 18-month business case
- Value modeled in a spreadsheet, realized never
- Synthetic data until "the platform is ready"
- A new portal nobody opens twice
- Success defined after the fact
- Decision deferred to the steering committee
The 90-day proof
- One decision loop, named in week one
- Production data by week two, or that's the finding
- Output lands in tools people already use
- A metric that moved, or didn't
- Scale-or-kill decision on a known date
Decision speed is the asset
Here's what the successful proofs have in common, across every domain I've built them in: the value never came from the artifact. It came from compressing the distance between something happening and someone acting on it. The dashboards, the pipelines, the agents — those are plumbing. The business case is the reallocation you make in week four that used to wait for the quarterly review. Speed of decision is the asset, and it compounds: every cycle the system runs, it gets more trustworthy, and more of the organization routes decisions through it.
How I run these
This is the shape of my engagement model on purpose. A fixed-price assessment finds the decision loops worth proving. A bounded proof takes one of them to production in ninety days with the success metric agreed in writing before the work starts. What scales afterward, scales on evidence — and what doesn't, dies cheaply. Either way, nobody spends eighteen months finding out.