“I don’t like this. I feel like sh!t.” That was the reaction from a senior developer at one of our portfolio companies after spending two days building something that would previously have taken two or three people several weeks to deliver. He wasn’t celebrating. He was trying to process what had just happened.
At another portfolio company, the reaction was completely different. They’ve started using Claude Code, but they’re not convinced it’s helping. Things still get stuck. Features still take too long. The developers are beginning to wonder whether the whole AI coding movement is overhyped.
Both teams have access to similar tools – the difference isn’t AI.
This is the fourth article in this series and focuses on AI for product development. One of the biggest mistakes leadership teams make is assuming that AI coding tools automatically make software organisations faster. They don’t – what they do is expose where your organisation was already slow. In almost every software business, there is a bottleneck. AI simply moves it.
The Real Difference Isn’t AI, It’s Engineering Readiness
The difference between these two scenarios comes down, ultimately, to two things: architecture and the software development lifecycle. My firm belief is that the software development lifecycle (SDLC) is the most important factor. The companies seeing the biggest gains from AI coding today are often the ones that invested in engineering discipline years ago and are now able to capitalise on those decisions.
A good SDLC has always allowed teams to move faster with fewer mistakes. AI simply amplifies the advantage that the best companies already have. This is particularly important for mid-market software businesses. Unlike startups, they often have years of accumulated technical debt, older deployment processes and more complex organisational structures. AI doesn’t remove those problems. In many cases it makes them impossible to ignore.
The companies seeing the greatest productivity gains aren’t necessarily using better AI tools. They’re benefiting from investments they made years ago in automation, testing and engineering quality.
One of the patterns we’re seeing across our portfolio is that AI doesn’t eliminate constraints. It simply moves them. Companies that spent the last decade improving deployment, testing and engineering processes are finding they can absorb AI-generated output surprisingly well. Those that didn’t are discovering that writing code was never the real bottleneck in the first place.
The New Bottleneck Is Organisational Absorption
If you do all of this successfully, the bottleneck eventually moves outside the product and engineering teams altogether.. there’s a limit to how quickly customers can understand, adopt and implement new functionality. Sales teams need time to learn how to position new products. Customer success teams need to understand how to support them. Marketing teams need to explain why they matter.
In many mid-market businesses, this becomes the next constraint. I don’t think many companies have reached this point yet. Most are still working through testing, deployment and review processes. But this is ultimately where the bottleneck should live.
The goal isn’t to maximise the amount of code being written. The goal is to maximise the amount of value that customers successfully adopt. AI coding tools don’t eliminate bottlenecks. They expose them.
For some companies, the bottleneck is testing. For others, deployment. For others, product management itself.
The organisations seeing extraordinary productivity gains from AI aren’t necessarily using better models. They’re benefiting from decisions they made years ago around engineering practices, automation and ownership.
The companies that have already moved the bottleneck out of engineering are beginning to discover the next constraint: how quickly the rest of the business can absorb change.
That’s a much better problem to have.
Three Questions for Leadership Teams
1. Once a developer has finished coding, is it a matter of minutes before that code is in production and potentially available to customers?
2. Are developers responsible for product decisions, design, front end, back end and deployment?
3. Is the wider business capable of absorbing the volume of functionality the product team could now produce?
The answers will tell you where your bottleneck is today. The companies that move it fastest will benefit most from AI.
Next: Part 4 – AI for Operational Transformation – Making the Entire Business AI-Capable
1. You Need to Understand AI Before You Implement AI
2. AI in Your Product – Data Moats and Why Most AI Features Are Worthless
3. AI for Product Development – Why Your Engineering and Product Teams Need to Change Now
4. AI for Operational Transformation – Making the Entire Business AI-Capable
5. The AI Transformation Toolkit – Frameworks, Checklists, and What We’re Actually Building
