AI Stopped Being a Tool and Started Changing How We Work

For the past year, like most tech companies, we’ve been experimenting with AI. Our engineering team tried GitHub Copilot. Product managers (myself included) dabbled with ChatGPT for writing. Design explored some generative tools. It felt incremental, like adding another app to the toolkit.

Something shifted in the last few months, and I’m still processing what it means.

I’m director of product management at a wholesale domain registrar. A few months ago, our engineering teams started using Claude Code for significant portions of their development work. Not just autocomplete or boilerplate generation, but actual feature implementation. And some of them got fast. Like…really fast.

That’s when the inflection point hit us: the constraint had moved.

For years, the rhythm of product development was predictable. Product would spend a few weeks researching and writing detailed requirements. Design would iterate on flows and interfaces. Then we’d hand everything to engineering, and the waiting game would begin. Engineering was almost always the bottleneck, not because they were slow, but because building software was genuinely hard and time-consuming.

Now engineering is telling us they can build in days what used to take weeks. They’re potentially asking for the next set of requirements before we’ve even finished validating the last release. The bottleneck has shifted, and it’s pointing directly at the rest of us.

This isn’t a comfortable realization. It means my team in product management needs to fundamentally rethink our process. We can’t spend three weeks perfecting a PRD when engineering could have built and deployed two iterations in that time. We need to get faster at research, faster at writing, faster at decision-making. Fortunately, we can use the same AI tools that sped up engineering. I’m now using Claude to help synthesize user feedback, draft requirements, and analyze data. But it’s not just about using AI to do the same work faster; the real shift is realizing and learning how we can work differently.

When engineering can move this quickly, rapid prototyping becomes viable in ways it never was before. We can test three different approaches to a feature in the time it used to take to build one. We can learn from real user behavior instead of debating hypotheticals over a Google Meet call. The whole product development cycle can become more experimental and more iterative.

Here’s the uncomfortable part: every team needs to make this shift, or they risk becoming the new bottleneck. Our design team is now grappling with how to do rapid wire-framing and exploration of user flows at a pace that matches engineering’s new velocity. Customer support needs to think about how AI can help them process feedback and identify patterns faster. Even our compliance and legal teams are starting to ask how they can accelerate their processes.

The teams that figure this out will thrive. The ones that don’t will find themselves constantly apologizing for holding everyone else up.

I don’t think that this means we’re working any harder. We’re working differently. Busy work or tedium is what’s going away, allowing more time for thinking or discussion. It is sometimes more mentally taxing because less of my work day is spent messing with data in Excel or typing into a Confluence doc.

This is what an actual inflection point feels like: not the slow adoption of a new tool, but the moment when the tool changes the constraints of the entire system. When the question stops being “how can we use AI?” and becomes “how do we reorganize our work now that AI has fundamentally changed the pace?”

We’re still figuring it out. Some days it feels exciting. Other days it feels chaotic. But I’m certain we can’t go back to the old rhythm.

The companies that will succeed in the next few years won’t just be the ones that adopt AI tools. They’ll be the ones that reorganize their entire operating rhythm around the new possibilities those tools create. That’s a much harder challenge than buying some software licenses, and I suspect most organizations haven’t fully reckoned with it yet.

We’re trying to. Ask me in six months how it’s going.