At my last role at ServiceNow, I put more than twenty AI research tools in front of a field team of about fifty sellers. Every dashboard I had said it worked — account briefs that took an afternoon dropped to twenty minutes, competitor teardowns went from "if I have time" to "of course." Then I sat in on the meetings the research was supposed to sharpen. They sounded exactly like they had a year earlier.

I got the diagnosis wrong twice before I got it right. First I assumed it was an adoption problem — maybe people weren't really using the output. They were, genuinely.

Then I assumed the tools weren't good enough yet. But, they were fine.

Research was never what was limiting us. I'd made an abundant thing more abundant, and pointed a real capability at a part of the “sales machine” that already had excess capacity.

There's an idea from manufacturing, forty years old, that explains this better than anything I've read in the AI literature. Every system — a factory floor, a sales org, a hospital — has exactly one constraint: the single slowest step that sets the pace for everything downstream of it. If you speed up any other step you won’t get more output. You get a bigger pile of unfinished work in front of the same bottleneck. That's Eliyahu Goldratt's Theory of Constraints, and his sharpest line about it is almost rude in its simplicity: an hour saved anywhere except the constraint is not an hour saved. It's an illusion.

This isn't just my rollout. McKinsey's Global AI Survey (Nov 2025) found 88% of organizations now use AI in at least one function — and only 39% report any impact on EBIT. Gartner projects more than 40% of agentic AI projects will be canceled outright by the end of 2027. Real capability, competently deployed, pointed at something other than the constraint, will always fail.

Here's what I know for certain now, and I don't say that lightly: AI doesn't relocate your bottleneck. It floods your bottleneck with more waiting work. Throughput goes wherever you point it, and the constraint is a property of the system's structure, not of which tool touches it. So the fix comes before any AI conversation, not during it. Find the backlog that's already piling up — the approval that sits, the queue nobody's cleared, the handoff everyone routes around — fix that first, and only then point AI at it. After that, it stops being a project and becomes a discipline: plan, do, check, act, and go looking for the next one.

If you're on a board or exec team reviewing this kind of spend, two questions get you most of the way there. What's the existing backlog this budget is supposed to clear — and has anyone actually checked whether that's the real constraint before signing off? And are you tracking hours saved, or throughput gained? Those are different numbers, and only one of them is real.

What's still genuinely unsettled, even with the method solid: you don't find that backlog the same way twice. In a factory it's usually visible — the machine with inventory piled up in front of it is your bottleneck. In a sales org or a hospital, the constraint might be a person's calendar, an approval nobody ever wrote down as a decision point, a habit nobody would call a step at all. The method — find it, fix it, then keep cycling — is settled. Which thing you're looking at, in your specific organization, is still a live diagnostic challenge each time, and I'm suspicious of any framework that claims otherwise.

Do you think that's actually generalizable — a checklist you could hand to any org — or is it irreducibly specific to each one? I lean toward the second, but I’m open to better arguments.

— Isaac