May 18, 2026
For years, the bottleneck in technology teams was delivery. Too slow to ship, too slow to learn and too slow to adapt. We responded with better methodologies. Lean thinking, Kanban boards, Scrum teams. All of it pointed at the same problem: remove friction from the build.
It worked. We got faster. Then AI changed the equation entirely.
Today, code generation is instant. Prototypes are ready in hours. Entire features scaffolded before the standup ends. Small, AI-powered teams now outpacing traditional, larger squads. Some recent Equal Expert examples;
These results aren’t anomalies; they’re the new baseline. Delivering fast is no longer the problem. The new issue is that AI never stops to ask whether what you’re building is the right thing. Whether it solves a real problem. Whether it makes things better.
AI is remarkably good at answering questions, but it struggles with ambiguous requirements, real-world constraints, and knowing which questions are worth asking in the first place. The difference between a good engineer and a great one was never how fast they could write code. It was how clearly they could think through a problem before writing any.
I recently saw this play out with an early-stage payments startup. Its non-technical co-founder, frustrated with the pace of development, used AI to build dashboards and reporting tools before a single customer had seen anything. He ignored the experienced technical and product voices in the room who urged him to slow down and validate first.
Months later, the MVP was a blackbox codebase nobody fully understood, riddled with bugs and connectivity issues. The AI made building faster, but it didn’t make it right.
In contrast, I worked with a marketplace startup with a similar starting point: AI-assisted build, feature bloat, and an inconsistent codebase resulting in an inconsistent product. We paused. We talked to industry experts and brought in proper engineering discipline. Three weeks after a proper, discovery-led launch, the product was attracting 3,000+ page views a week.
The difference between these examples wasn’t the technology. It was whether anyone stopped to ask if what was being built was the right thing and if people actually wanted it.
Clear intent with AI accelerates value. Fuzzy intent with AI accelerates waste. If you’re close to your customers and clear on your why, AI is a superpower. If you’re not, it’s an accelerator for bad decisions. It scales your thinking, good or bad.
The most dangerous thing in a product meeting is confidence about what customers want without a recent conversation or data to back it up. It’s a fast track to wasting resources and time on features that will never be used. Pendo’s feature adoption research found that 80% of product features across the average software product are rarely or never used, representing billions in wasted engineering investment
As a former CTO, I’ve seen what happens when you solve the problem at speed but ignore the “why”. We had a team of 12 developers shipping a new feature every month, and by most measures, the speed problem had been solved. But customers weren’t using the features. We’d been arrogant, assuming customers would just stumble across new features. It took talking to customers directly to realise they didn’t even know the features existed or had the capacity to explore them.
So we slowed down a little. We introduced beta testing, an early adopters group, and a visible roadmap. We started scheduling releases more deliberately rather than just shipping. And we started talking to customers again.
As companies grow, it’s easy to convince yourself that data and roadmaps are a substitute for real conversation. They aren’t. Discovery isn’t a box you check at the start of a project. It’s the discipline of always knowing why you’re building something, staying close enough to customers to notice when that why changes, and being honest enough to measure whether you got it right.
AI is not a neutral thinking partner. It is a biased, mostly agreeable one. Research from Scientific American found that AI models are 49% more likely to affirm your existing point of view rather than challenge it.
LLMs are designed to help you execute an idea, not to tell you if it’s bad. That’s useful when your thinking is clear, and your intent is sharp. It’s dangerous when it isn’t. AI validates your prompt, not your strategy. But if the strategy is wrong, no prompt will save you. This is why you still need humans in the room who are willing to push back.
Where AI focuses on the how, humans are asking why. They bring the business context, connect initiatives to real customer outcomes, and are willing to block work that doesn’t meet that bar. That kind of friction is not inefficiency. It is the work.
During my time leading a digital transformation, an innovation framework was introduced that “returned” 10,000 hours to the business. On paper, it was a triumph.
However, when I asked the CFO if EBITDA had gone down, the answer was no. It hadn’t moved. That moment crystallised something. We were measuring delivery, not impact. Outputs, not outcomes. New software installed, meetings removed, perceived effort reduced. All of it was disconnected from the business’s actual goal of 1% efficiency improvement.
Delivering projects isn’t the same as improving the business. Done isn’t the same as better. Adopting AI and shipping faster are no longer the real challenges for technology leaders. Now it’s about staying close enough to customers and business outcomes to know whether what you’re building actually matters.
The leaders who get that right will use AI to accelerate real value. The rest will just accelerate faster toward the wrong destination.
The latest Equal Experts ebook explores evolving product discovery for AI delivery, and how to keep product and engineering teams aligned in an AI-driven world. It outlines how discovery and specification must evolve so product and engineering teams can stay aligned as software delivery accelerates.
If you want to discuss how to integrate AI into your workflow without sacrificing discovery or engineering discipline, contact the Equal Experts Australia team today.
Jonathan Milgate is a Principal Technology Strategist at Equal Experts with over 15 years of experience scaling digital products and engineering teams. As a former CTO of an ASX-listed marketplace, he led a business from early-stage startup through IPO and international expansion across six markets. He works with technology leaders to connect what gets built to real business outcomes. Connect with Jonathan on LinkedIn.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.
