Turning build speed into product progress
AI tools compress execution risk, but Product-Market Fit doesn't care how fast you ship. Here's how to turn velocity into progress.
AI coding tools have changed the economics of building software. Features that once took a sprint can now be deployed in hours. But faster building is not the same as faster progress, and the gap between the two is where a lot of product teams are about to get stuck.
When a team gets access to AI-accelerated development, something predictable happens: output increases. Features appear on staging daily – and engineers previously blocked by capacity constraints start building at the speed of their curiosity. But that creates challenges around focus. Imagine requests from senior stakeholders: now there’s no reason for these not to go live almost immediately, irrespective of Product-Market Fit or customer sentiment. Similarly, design simplicity may get lost when everything is possible.
This is what velocity without progress looks like. The accelerator is slammed down hard, but the distance between where the product is and where it needs to be doesn’t really change. While AI compresses execution risk in the product development lifecycle, the organisations that benefit most will be those that connect their new speed to a clear sense of direction. Ultimately, outcomes still matter most.
Changing the risk profile
Marty Cagan’s four risks: value (will customers want this?), usability (can they figure it out?), feasibility (can we build it?), and business viability (does it work for our business?) provide a useful lens for what actually shifts in the new world (1):
Feasibility compresses
For many teams, feasibility was already the least dangerous of the four risks but consumed a disproportionate share of attention because it was the most visible constraint. But now, the cost and time to produce working software drops significantly, especially for new features and well-scoped work. Things requiring a sprint or two of engineering effort can be prototyped in hours, and the default answer to, ‘Can we build this?’ is increasingly, ‘Yes – and quickly.’
Usability shifts
Faster access to working software means usability issues surface in real usage rather than prototype testing. The risk does not disappear: it migrates from the lab to the wild. Faster, but messier.
Value and viability are reweighted
No amount of execution speed changes whether you are solving a real problem for real people, whether customers care enough to engage, or whether the solution fits your business model. These risks sit upstream of execution and they are the ones that determine Product-Market Fit.
But speed does change two things about them:
First, you have more opportunities to test value assumptions through real usage, provided your experimentation and customer research can capture what you learn.
Second, the consequences of not addressing these risks go up. Faster execution produces more evidence of strategic weakness, more quickly. Ship three features in a month that nobody uses and the pattern is hard to ignore.
Value and viability risk are not untouched by AI-accelerated development. They are reweighted: easier to validate if you are disciplined, more painfully exposed if you are not.
The shift in prototyping shows this clearly. Traditional prototyping existed partly because building real software was expensive, so it was simulated to test assumptions cheaply. When building becomes cheap and coding is driven through conversation with agents, this becomes far less necessary. Teams that once spent weeks crafting high-fidelity prototypes in Figma are increasingly vibe coding working software or designing directly inside tools like Cursor, so design outputs are now the product, not just a simulation. Yet the need to understand what you are testing and why remains: understand the problem, understand the customer, understand what success looks like.
From circular motion…
Slow delivery cycles have quietly acted as a safety net for weak strategy. When it takes a quarter to ship a feature, there is time to retrofit a narrative, adjust positioning, and claim alignment that was never really there. Nobody notices the rationale was thin because by the time the feature lands, the context has moved on enough to obscure the gap.
Rapid execution removes that buffer. If your strategy is vague, the gap between what you are shipping and what you should be shipping becomes visible almost immediately, and at volume. Leadership starts asking why the hit rate is low, and the answer is almost always the same: the team was building solutions to problems that were not well enough understood, or the definition of success was loose enough to accommodate any outcome.
A list of initiatives is not a strategy. Neither is a growth target. What teams need, more than ever, are guiding principles, clear positions on where to play and where not to, and high-level actions connecting business objectives to product decisions. When delivery was slow, you could get away with a vague destination and course-correct along the way. When delivery is fast, you build confidently in three different directions at once and get nowhere fast.
… To forward motion
If the danger is velocity without progress, the opportunity is a tighter feedback loop between strategy and execution. More frequent shipping generates more frequent signals about whether your strategic assumptions hold, but only if you are set up to capture and process them. Get this right, and each cycle of building, releasing, and learning brings you closer to Product-Market Fit rather than further from it.
Gate proportionally to risk
Not everything needs the same level of rigour. If the primary risks are feasibility or usability, adopt a build-first mindset and evaluate in production. If value or viability are genuinely at stake, do more discovery and customer research before committing. Be pragmatic and prevent product management becoming a bottleneck while maintaining discipline where the stakes are high.
There’s a middle path too, and one that becomes increasingly practical when working software is cheap to produce: beta groups and early-access cohorts let you put real software in front of real customers before a full release. Instead of testing assumptions against prototypes or mock-ups, test them against the actual product with people who can tell you whether it solves their problem.
The key is honesty about which category a piece of work falls into. Left ungoverned, teams will default to treating everything as low-risk, because building is now the path of least resistance.
Set the direction, don’t police the output
Talking about the ‘why’ with cross-functional colleagues has never been more important.
For work that does not need gating, PMs can keep things directionally sound by curating the strategic context that surrounds development. Product strategy documents, feature inventories, and experiment framing templates can live alongside the code, accessible to both developers and their AI coding agents. This does not prevent anyone from building, but it creates a shared reference point when someone asks, ‘Should we be doing this?’
When the pace of change accelerates, people outside the immediate product team need to understand the reasoning behind what is being built too. If the only thing that scales is output, you create confusion across the organisation.
Build the learning into the building
For features that go straight to build, the discipline of experimentation needs to live inside the development workflow, not upstream:
What hypothesis does this feature test?
How will we know if it is working?
What are the criteria for keeping, iterating, or removing it?
If these questions are answered alongside the code, speed and rigour coexist. Without them, features and concepts accrue that are individually harmless but collectively incoherent. Building may be cheap, but maintaining, supporting, and explaining a growing product surface is not (2).
Your analytics need to keep pace with your release frequency too. If you are pushing to production weekly but reviewing metrics monthly, you have created a gap that swallows the advantage of speed.
Faster feedback
This is where the compounding effect lives. Most organisations are not short of data. What they lack is the ability to turn it into something actionable quickly enough to inform the next round of decisions. If AI can make building faster, it can make learning faster too, and it is the learning that determines whether speed translates to progress. Tools like Claude can compress the synthesis step, taking experiment results, usage data, and customer feedback and turning them into insight filtered through your product strategy. Not just, ‘Here is what happened’ but also, ‘Here is what this means for our assumptions.’
Yet none of this works if strategy is treated as a fixed document reviewed once a year. A two-way dialogue between execution and strategy is needed too:
Execution anchored through strategy. Strategy informed by accelerated learning.
What this means for product management
In an AI-accelerated world, the PM’s most important contribution is maintaining strategic coherence across a faster cycle: keeping the team pointed at problems that matter, ensuring customer insight feeds into direction, and making sure the product stays focused on user needs and business outcomes rather than on whatever is fun to build. This requires PMs to be deeply embedded in the team, not sitting above it writing specs that arrive too late to be useful.
This shift is already under way. In some organisations, engineers frustrated by the pace of product decision-making are going directly to customer recordings and building from what they hear. That is a rational response to a bottleneck – and PMs who define their value by what they prevent will find themselves increasingly worked around. But PMs who bring strategic grounding, customer centricity, and a relentless focus on whether the product is getting closer to solving real problems will find their contributions embraced.
The binding constraint in product development is no longer how fast you can build. It is how clearly you understand what you are building towards, and whether your organisation learns fast enough to steer. AI has removed one bottleneck. Are you ready for the ones it has revealed?
Sources
1. Cagan, M., Inspired: How to Create Tech Products Customers Love
2. McKinsey & Company, ‘How an AI-enabled software product development life cycle will fuel innovation’, February 2025: https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/how-an-ai-enabled-software-product-development-life-cycle-will-fuel-innovation
Finding Product Breaks valuable? Please consider sharing it with your friends - or subscribe if you haven’t already.
Good insights!