Nine years ago I wrote about applying Lean Startup methodology to enterprise technology adoption. Lean startup is, at its core, a way of learning faster what works and discarding what doesn’t. It’s been adopted by countless startups to prove their business model and products. I adapted a three-phase model around it — Envision, Execute, Evaluate — to support the customer success work I was doing at the time.

I’ve referenced that post more than almost anything else I’ve written. It’s turned up in pieces on generative AI strategy choices, on systems, culture and strategy for AI adoption, and a few others since. I get a lot of traffic to the original post. It informs so much of my work to this day and I feel like it’s held up, broadly. An unflinching look at it is probably overdue though — especially now that my day job is enterprise AI adoption.

NOTE: I used AI to critique my original post and help provide points for consideration in my views below.

Then, now, and now-now

The original post drew a contrast between two eras: heavily configurable, waterfall-planned platforms that shipped once every few years, and SaaS platforms shipping quarterly — sometimes weekly — with far less customisation on offer. My argument was that the second era demanded an iterative, experimental approach to adoption rather than a big up-front plan.

That contrast needs a third column now.

AI-native platforms don’t just ship faster than SaaS did — they ship less predictably. A typical, quarterly SaaS release is a known quantity: a vendor decided what to build, could tell you what they were building and then while they built it, customers planned for it’s release.

A model update, a new agentic capability, a Copilot skill — these have a habit of doing things nobody, including the vendor, fully scoped in advance. You’re not just planning around a faster roadmap anymore. You’re planning around genuine uncertainty in what the platform can do this quarter that it couldn’t do last quarter. And this doesn’t even take into consideration the breath-taking pace of change competition is forcing in a nascent category.

None of this is a reason to abandon iteration. If anything it’s the strongest argument yet for it — you can’t plan in detail for a capability you don’t yet know exists. But the “why iterate” logic in the original post was about cadence. The 2026 version of that logic has to be about discovery.

Is Lean Startup still relevant?

It’s worth asking directly, because it’s a live argument right now, not a settled one. AI has collapsed the cost of the build step in build-measure-learn from months to days — that part isn’t controversial, I see it in my own work constantly. Some of the sharper recent writing on this makes the case that this shifts Lean Startup’s centre of gravity entirely: the scarce resource used to be the ability to build something quickly enough to test it. Now the scarce resource is the discipline to actually measure and learn from what you built, because everyone can ship fast.

I think that’s right, and it matters more for enterprises than it does for startups. A startup that skips validated learning burns its own runway. An enterprise that skips it burns a budget line and quietly joins a statistic. MIT’s Project NANDA found in 2025 that the large majority of enterprise generative AI pilots — 95% by their count — were producing no measurable return, despite tens of billions in spend. Not because the models were bad. Because most of that spend never got past looking impressive in a pilot review and into anything resembling validated learning against a real workflow.

So: not obsolete. If anything the opposite. The “measurable” leg of my original model — I described the approach as measurable, executable and iterative — was probably the one I under-wrote in 2017. It’s exactly the leg most enterprise AI programmes are still skipping.

What still holds from the original model

Genuinely, most of it:

• Use cases as the currency of success — still true, arguably more so. AI makes this harder rather than easier, because nearly everything looks like a plausible use case. Without discipline here you get scattershot pilots — exactly the pattern MIT’s research describes.
• Champion networks — still essential, and I’d argue more so now. AI adoption carries a trust and anxiety dimension a CRM rollout never did. Champions aren’t just demonstrating a feature anymore; they’re modelling that the tool is safe to rely on and how it drives impact.
• The maturity curve — the idea that adoption deepens unevenly across users and segments over time holds up completely. I picked this thread back up more recntly in Identifying Technology Transformation S Curves for Modern Work.
• The three-phase scaffold itself — Envision, Execute, Evaluate is generic and simple enough to survive the technology underneath it changing completely. That’s rather the point of it especially where simplicity is concerned. My view on this is keep complexity out of methodologies because there is more than enough of it in the technology – you don’t want to add to that.

What’s genuinely missing

Two things I’ll say the 2017 post doesn’t cover well:

Governance and trust aren’t a pre-launch checkbox anymore. In the original model, governance meant configuration, permissions, security — set once, before launch, then largely left alone. That’s nowhere near sufficient with AI. A one-time setup task wont do. It has to run as a continuous stream alongside Envision, Execute and Evaluate, not as a phase that precedes them.

Cadence needs to split in two. The original model assumed roughly one speed: quarterly use-case cycles, four times a year. AI breaks that into two distinct clocks. Capability validation — can this thing actually do the task — can now happen in days, because building a prototype costs almost nothing. Adoption — will people actually change how they work, trust the output, build it into habit — hasn’t sped up at anything like the same rate, and arguably needs more room than before, given how disorienting the change can feel. Running both on the same quarterly clock, as my original model implicitly did, understates how slow the human half of this still is.

The unflinching bit

If I’m honest, in 2017 I was optimistic about measurement in a way that’s aged the least well. It assumed that if you set KPIs and reviewed them, you’d see progress more or less by construction. What the last couple of years of enterprise AI adoption have shown, repeatedly, is that most organisations are still measuring the wrong things, like usage and calling it value, without ever closing the loop back to an actual outcome. That’s precisely the gap the Evaluate phase should now force people to confront explicitly. I have touched on this recently: What Actually Determines AI’s Value.

Where that leaves it

Lean Startup, applied properly, is more relevant to enterprise AI adoption than it was to enterprise SaaS adoption in 2017 — not less. The build side has never been easier. The discipline of validated learning has never been scarcer, or more worth protecting. If you’re revisiting your own adoption approach, I’d keep the shape of the original three-phase model and bolt two things onto it: governance as a running stream rather than a gate, and two cadences instead of one.

Nine years is a long time for a framework to still be mostly right. I’ll take it.