The Caffeinated Org That Didn’t Show Up

Innovation used to be expensive. Dedicated labs, decks that sold design sprints, teams carved off to focus, off-sites with whiteboards and post-it notes. I’ve been part of them at Designit, The Ready, and IBM. I’ve run them at McKinsey, Mailchimp, and Ford.

Looking back, most of them weren’t that effective. They were stand-ins for product leadership that hadn’t brought focus — which the team then inherited — and business leadership running a product disconnected from its users. Canaries in the coal mine with a side of role validation.

Now AI dropped the cost of innovation to almost nothing. The work got democratized. Everyone’s a builder. Everyone’s having their Mary Shelley “it’s alive” moment across all three phases of work. But is any of it landing for your users, your bottom line, your team?

Andy Budd recently posted this:

“The AI transformation playbook.

Step one: Get the whole product team using AI.
Step two: Burn through your 18-month backlog in six months.
Step three: Downsize.
…
Step four: Rehire half the team once token costs explode and you realise the backlog wasn’t the hard bit.

Most teams are somewhere between steps one and two. Some skipped straight to step three. A few are already learning about step four.”

The expectation underneath: dump AI on the existing org, get a caffeinated version of it. Same structure, same workflows, same measurement, same initiatives, just 20x faster and better. That isn’t what happens. What happens is that the roles that quietly enabled quality (UXR, QA, design systems, design) get treated as overhead and cut. The remaining team is asked to absorb the work because AI will fill the gap. Then the founder notices holes in the product and inconsistencies in the experience and wonders why.

I’ve watched this happen in real time. QA hired and let go. UXR let go. Design teams cut in half. Design system teams defunded. Six months later, leadership is upset about the quality issues those roles existed to prevent.

The honest lesson, including for me: we were never that good at iterating. The pre-AI version of this work was already brittle. AI didn’t break iteration. It exposed how thin our iteration loops always were. It also exposed how flawed most product orgs really are at getting work done. SDLC V7.13 doc is not clarity. It is bureaucracy with version control. Real clarity is shared understanding of what’s being built, why, and who decides. Most orgs confuse the document for the thing.

AI didn’t break iteration. It exposed how thin our iteration loops always were.

That’s also why this is the most interesting moment in years. The teams that see it for what it is can actually fix it.

The mistake wasn’t picking the wrong phase to invest in. It was assuming AI’s speed advantage applied uniformly. Every product org runs three phases of work at the same time.

There’s production: the roadmap, the commitments, the things you told people you’d ship. There’s foundation: the infra, the eval rigs, the design system, the boring underground machinery that decides whether anything you build will hold up. And there’s innovation: the work dreamed up in lobbies at off-sites and on Miro boards in abandoned folders, where you build a thing to find out if there’s a thing.

All three are always running. They are not the same speed.

Innovation wants exploration. Production wants cadence. Foundation wants rigor.

Pre-AI, most teams made a foundation bet. A database, a framework, an architecture, a vendor. It worked when they made it. It probably won them a market. Then five years pass, the product grows, the foundation creaks, and every new feature request runs into the same answer: “that would require a rewrite.”

So the team says no. Then no again. Then they get good at saying no. The roadmap gets shaped not by what customers want but by what the foundation will tolerate. Innovation slows. Not because the team ran out of ideas, but because the answer to most ideas is we’d have to rebuild for that. The product becomes a museum of decisions you can’t unmake.

I’ve seen this kill companies that had every other ingredient. The team is sharp, the market is real, customers are still buying. But the foundation has become a cage, and nobody’s brave enough to rebuild it because the rebuild looks irresponsible from the outside. The good news, and the reason this is a hopeful piece more than a critical one: the cost of that bravery just dropped.

A few teams did the brave thing. They started before AI coding tools matured, when the rebuild still required heroic human effort. They took the risk on conviction and on people. That’s why they’re reaping the rewards now.

ClickUp spent roughly two years and hired more than 150 engineers to rebuild the platform: sharded the database, moved to service-based architecture, rewrote the WebSocket layer, redid the application code. Their CEO said publicly that no normal product company would rebuild its infrastructure four years in. They did it anyway. The performance numbers came (2x app speed, 3x task views, 5x search), but the real result was that ClickUp Brain, their AI layer, had somewhere to live. The foundation work was the precursor to the innovation.

Intercom mobilized within hours of GPT-3.5 launching. They cancelled non-AI projects. They committed $100M to replatform around AI. They reorganized product teams. They switched from per-seat pricing to outcome-based pricing, knowingly cannibalizing their own core revenue model. Eoghan McCabe described what happened next as the business beginning to violently recover. Fin now resolves millions of conversations weekly across 8,000 companies. Monthly growth went from around 4% to 37%.

Shopify went infrastructure-first by design. They built an internal LLM proxy, an MCP integration layer, a centralized tooling platform. Any team in the company can experiment with AI tools cheaply and safely. Their first version of Sidekick wasn’t widely used. They rebuilt it. The second one works because the foundation underneath was already there.

These companies didn’t get the caffeinated org by accident. They earned it. They redesigned the operational and systems layer before asking it to run at AI speed. That’s the work most orgs skipped, and it’s why “AI everywhere” hasn’t worked for them.

Foundation work is innovation work when it’s done in service of what’s next.

Most orgs aren’t going to replatform tomorrow. They probably should.

AI is starting to change what’s possible at the foundation level too. Test coverage, migration scripts, codebase translation are all genuinely cheaper than they were. The big rebuilds are more tractable than they were two years ago. And the payoff compounds. Cleaner data, better APIs, real eval rigs make AI more powerful inside your product. The features you’ve been saying no to for years are suddenly within reach. That “we’d have to rewrite for that” backlog stops being backlog. It’s the next quarter.

Innovation got cheaper too. The work that used to require a PM, two designers, two engineers, and six months can now be done by one person plus Claude in two weeks. Des Traynor at Intercom puts the unlock cleanly: AI doesn’t just make things faster, it makes it cheap to see around corners. You can stress-test five product directions before committing to one. You can prototype the controversial idea before the meeting where you’d otherwise have to defend it in slides.

The compounded effect is that ordinary orgs can now do what only ClickUp, Intercom, and Shopify could afford to do on conviction. The bar dropped. The conviction is still required.

The actionable move is to stop running everything at one speed. Separate the streams.

Let production run at production’s speed: cadence, predictability, the rhythms that let real customers depend on you. Let foundation run at foundation’s speed: deliberate, well-resourced, treated as the investment it is rather than the overhead it gets accused of being. Let innovation run at AI speed. Small team, two-week beats, prototype velocity that didn’t exist eighteen months ago, tied to a real revenue surface within roughly six months. And when there’s real clarity on direction and real validation in hand, innovation can go direct to shippable code — the prototype becomes production, no handoff phase required.

But streaming is downstream of clarity. You can’t separate work into three streams if you don’t have the organizational clarity to assign it in the first place. Without that clarity, everything defaults to production. The streams collapse into one. That’s how most orgs end up where they are. The clarity work isn’t separate from the speed work. It’s the precondition for it.

And the redesign goes deeper than streams. The structure, the workflows, the measurement, the SDLC were all built for a world where building was the expensive part. None of them survive contact with AI’s actual unlock. The roles that got treated as overhead — UXR, QA, design systems, design — weren’t overhead. They were the iteration infrastructure. AI didn’t make them redundant. It made the work they did more visible, and more necessary. New product development needs a new operating layer. Faster execution on the old one is what produced the caffeinated-org failure in the first place. The teams who actually redesign it get to do product development the old layer couldn’t support — five directions stress-tested in the time it used to take to commit to one, the rebuild and the next feature shipping in the same quarter, the prototype walking straight into production. That’s a real upgrade, and it’s available now in a way it wasn’t even eighteen months ago.

Production still needs cadence, though AI can sharpen the code work inside it. Foundation still needs rigor, probably more of it now. Infra, design systems, content strategy are the fuel AI runs on, both up front and continuously.

The caffeinated org didn’t show up because we asked AI to make every part of the work faster. What it actually does, beautifully, is make exploration cheap and validated decisions faster. Use that where it belongs. Respect cadence and rigor where they belong. Three streams. Three speeds.

If I could go back to those design sessions I ran, I’d be more diligent. Not just about what to build, but about whether the org was ready to change. Whether the foundation was mutable. What it would actually take to make the innovation come alive on the other side of the off-site — and whether we were willing to do that work. Most of the time, we didn’t ask. We shipped the deck and moved on.

If you’re trying to run AI speed on the old operating layer and it isn’t working, that’s the conversation I want.