Act I, The Exposure
The Exposure
Over a 36-year career at ExxonMobil, a drilling engineer named Fred Dupriest reframed an entire industry with a simple question: what if the problem isn't the equipment, what if it's everything you haven't bothered to diagnose?
He developed a metric called Mechanical Specific Energy, the energy required to remove a unit volume of rock, and used it as a real-time diagnostic tool. Instead of drilling harder, he drilled smarter: measuring what the bit was actually consuming versus the theoretical minimum and identifying exactly what was wasting the difference. He called the constraint governing your ceiling the delimiter. The operational factor preventing you from reaching it, the limiter. Find one, remove the other, find the next pair. His results, published across multiple SPE papers beginning in 2000, were staggering: ExxonMobil's Fast Drill Process produced ROP improvements of 100–400% and footage-per-day gains of 30–100%, across soft and hard formations, every rig type.
On January 30th, 2026, Anthropic posted 11 open-source plugins to GitHub. Two hundred lines of structured prompts doing the work of a paralegal, a Westlaw subscription, and billable hours. By Monday, $285 billion in market capitalization was gone. Thomson Reuters posted its worst single-day decline on record. LegalZoom cratered 20%. SAP lost a third of its yearly gains. Traders called it the SaaSpocalypse.
That event wasn't about AI being powerful. It was about SaaS products being exposed. The market suddenly saw that the structured workflows these companies sell can be replicated by a prompt file and an agent. The value proposition that took a decade to build was reproduced in an afternoon.
Lowman Harley's essay on the organizational speed limit names the broader dynamic: every organization has a maximum rate at which it can absorb change, and AI is accelerating past that rate. But for product teams, the speed limit isn't abstract. It's the backlog, the architecture, the sprint cadence, the approval chain, the tech debt, the sum of every structural decision that determines whether your product stays ahead of the models or falls behind them.
For most SaaS products, the delimiter has shifted and nobody updated the diagnosis. The constraint on survival is no longer feature completeness. It's the rate at which your product can evolve past what a general-purpose model can do for free. The limiters preventing your team from reaching that rate are hiding in plain sight.
Act II, The Delimiter Stack
The Delimiter Stack
Every product has a hierarchy of constraints governing how fast it can evolve. The discipline is to identify which one is dominant right now and address that specifically. GenAI just reshuffled the stack violently.
Ship velocity is the delimiter most product teams hit first. The traditional SaaS cycle, quarterly roadmaps, feature prioritization committees, six-month release trains, was designed for a competitive landscape that moved in years. GenAI moves in weeks. Anthropic's plugin architecture went from concept to market-destroying reality in less than a month. A product team whose ship cycle can't match that cadence isn't competing on features anymore. It's competing on a shrinking window before a model makes those features free.
Dupriest found an identical pattern on the rig floor. For decades, drillers applied weight to the bit slowly, conventional wisdom. His analysis revealed slow application actually caused severe bit vibration, damaging the equipment it was meant to protect. Rapid application, the opposite of standard practice, produced minimal damage and dramatically better performance. The limiter wasn't technology. It was an unexamined habit. Nobody had measured why they did it that way. They just did.
Product teams have their own version. Overbuilt approval chains where every release requires sign-off from stakeholders who haven't looked at the product in months. Engineering structured around predictability, two-week sprints, rigid ceremonies, change-averse pipelines, when the market rewards adaptability. Product managers writing PRDs for features an open-source agent will replicate before the spec is approved. These aren't best practices. They're unexamined habits that feel safe while silently destroying performance.
The actual creation might take days. The waiting takes months. This is where most product teams lose the race, not in the building, but in the 80% of delivery time that surrounds it.
But here's what makes ship velocity particularly dangerous as a delimiter: even when teams move fast, they move sequentially. Design finishes, then engineering starts. Code completes, then testing begins. Testing passes, then compliance reviews. Compliance clears, then documentation gets written. Documentation finishes, then go-to-market begins. Each phase waits on the one before it.
Value layer position becomes the delimiter once you can actually ship fast. Every SaaS product sits on an implicit assumption about where its value lives. For Thomson Reuters, it was aggregating and searching legal information. For LegalZoom, templating and filing legal documents. GenAI collapsed both in an afternoon.
The question every product team should be asking is brutally simple: which parts of our product would a well-prompted agent replicate in a day? CRUD operations, workflow orchestration, template generation, data formatting, these are the layers GenAI eats first. The delimiter is whether your product can move up to the layer that isn't replicable: outcome intelligence, contextual judgment, proprietary insight built from data no model has. Teams that can't decompose their architecture can't migrate their value layer. They're defending territory already commoditized.
Data depth emerges as the delimiter in the next layer. The SaaS products that survive this era will be the ones sitting on unique, continuously enriched datasets that make their intelligence layer smarter than anything a general-purpose model can produce. The product that learns from every customer interaction, every workflow outcome, every deployment, and feeds that learning back into its own intelligence, is building a moat that actually widens every time the base models improve. Better foundation models don't threaten a deep proprietary data layer. They make it more potent.
The limiters here are years of treating data as a byproduct rather than the product itself. Analytics bolted on after the fact rather than designed as the core architecture. Customer data siloed from the intelligence layer. Every client engagement, every deployment pattern, every edge case encountered and solved, that's the raw material for compounding intelligence. But if the architecture doesn't capture it and feed it back, each project starts from zero. The product never gets smarter. The moat never forms.
Team identity governs everything beneath it. This is the hardest delimiter because it's cultural, not technical. Most product teams still think of themselves as feature builders, the metric is tickets closed, PRDs shipped, features launched. The ones that survive will have redefined themselves as intelligence builders, teams whose primary output isn't software features, it's compounding institutional knowledge encoded into systems that get smarter with use.
That identity shift changes what you hire for, how you measure success, and what you prioritize in the backlog. Product teams that treat GenAI as a feature to bolt on, "add AI to the search bar," "integrate a chatbot", will hit this delimiter and stall. The ones that internalize it as a fundamental redefinition of what the product is will compound past it.
The Sequential Trap
There's a pattern buried in this delimiter stack that most product teams don't see, even though it governs nearly everything.
Software delivery has been sequential for so long that nobody questions it. Design, then build, then test, then secure, then document, then go to market. Each phase assumes the previous one is finished. Each handoff introduces delay, context loss, and rework. The entire process is structured around the assumption that creation is the bottleneck.
It's not. Creation, writing code, has been dramatically accelerated by Copilot and Cursor. The bottleneck has moved to everything that surrounds the code: the design that precedes it, the testing and compliance that follow it, the documentation and go-to-market that trail behind it. The 80% of delivery cost and time that teams treat as overhead is now the actual constraint on how fast a product can evolve.
And here's the compounding problem: GenAI makes the code-writing phase faster every month, which means the sequential phases around it become a larger and larger percentage of total delivery time. The faster AI writes code, the more visible the sequential trap becomes, and the more it governs your ceiling.
Product teams that solve for ship velocity by making their engineers faster are optimizing the 20% while the 80% locks them in place. The delimiter isn't engineering speed. It's the delivery architecture around engineering.
The Compounding Gap
When ExxonMobil deployed Dupriest's methodology across 270 rigs and 1,700 wells, the gains didn't flatten. They compounded. Each well taught the system something the previous one hadn't, because every limiter removed revealed a cleaner view of the next one.
Product teams follow the same curve. The team that removes its first limiter this quarter doesn't just gain speed, it gains diagnostic capability. The ability to see the next constraint more clearly and remove it faster. Over twelve months, that compounding produces a product and organization structurally different from competitors still debating their AI roadmap.
The inverse compounds too. Every month that GenAI advances and the limiters remain, the gap between what agents do for free and what the product charges for narrows. The constraint stack deepens. The architectural debt accrues interest. The team that was "planning to address AI next quarter" discovers that next quarter's models have already leapfrogged the strategy they were planning to implement.
Gartner predicts over 40% of agentic AI projects will be canceled by 2027. That prediction isn't about the technology failing. It's about product organizations that never developed the diagnostic capability to identify which limiters to remove first. They'll ship AI features. The features won't compound. The product will still be defending a value layer already commoditized.
The SaaSpocalypse wasn't a one-day event. It was the market's first honest pricing of a compounding structural problem. The next repricing is coming. The question is which side of the delimiter your product is on when it hits.
What the Solution Has to Look Like
If the diagnosis is right, if the governing delimiter for most SaaS product teams is the sequential delivery architecture around code, not the code itself, then the shape of the answer becomes clear, even before you know what it's called.
It would have to break the linear relationship between team size and output. Adding more people to a sequential process doesn't compress it. It makes the handoffs more complex.
It would have to execute phases in parallel, not in sequence. Design, build, test, compliance, and go-to-market can't keep waiting on each other. The creation and everything around it would need to move simultaneously.
It would have to orchestrate existing tools rather than replace them. Not another point solution added to the ten you already manage, but the delivery workflow itself becoming intelligent, connecting the tools you already use into a single, governed process. Zero migration. Zero lock-in.
And it would have to compound. Every deployment would need to make the next one faster, more predictable, and harder to replicate. The data from each workflow would feed back into the system's intelligence. Domain expertise, the kind that takes twenty years to accumulate, would need to be encoded into reusable templates that guide every decision. The moat wouldn't come from code. It would come from compounding knowledge.
That's not a feature. That's not a chatbot bolted onto a dashboard. That's a fundamentally different operating model for how software products get delivered.