AI velocity is product management's newest problem
Engineering teams are shipping code faster than ever. AI coding tools turn ideas into working software overnight. Sprint velocity is up. The roadmap looks full.
And yet the features teams celebrate internally are not the ones customers actually use.
U.S. businesses have poured an estimated $35 to $40 billion into generative AI. Independent research found that 95 per cent of pilots deliver no measurable impact on profit or loss. A global management consultancy found that 75 per cent of CTOs are not hitting return on investment expectations on software development.
The organisations winning are not the ones with the fastest pipelines. They are the ones with the strongest product inputs: discovery rigour, customer understanding, and cross-functional alignment that ensures AI is pointed in the right direction before it starts building.
Speed without strategy
The productivity lift is real. A 2025 software engineering report found that 63 per cent of engineering organisations ship code more frequently since adopting AI tools.
The same report found that 45 per cent of deployments involving AI-generated code lead to problems, and 72 per cent have suffered a production incident.
But tighter reviews, better testing and more governance cannot answer the more important question: should this have been built at all?
What AI-accelerated development changes is not whether features get used. It is how many unused ones ship. More features, faster, with the same underlying rate of customer indifference.
The rise of product slop
Product slop is what this build-up looks like internally. It is not necessarily buggy software. Product slop is technically sound, carefully developed and yet entirely missing the point.
Think of a filtering interface built because a product manager assumed frustration, when the data showed customers had stopped using that section altogether. Each one ships cleanly, appears in the changelog and largely gathers dust.
A prototype only creates value when teams build to learn, not to ship. AI has made that distinction easier than ever to ignore. When plausibility keeps being mistaken for proof, the result is discovery debt: unvalidated assumptions hardened into roadmap commitments before anyone tested whether they were true.
The quality ceiling of an AI-assisted process is set by what goes in. The answer is stronger product inputs.
Where discovery fails under velocity pressure
Product discovery breaks down at three stages:
- Gathering: defaulting to internal experts rather than the full signal set - usage data, sales patterns, competitor intelligence and real customer conversations
- Analysis: converging on solutions before separating symptoms from root causes
- Framing: building the business case to justify a decision already made, rather than to earn genuine confidence in one still open
Fixing this starts with visibility. Map your discovery process cross-functionally - every step, every handoff, every wait-state between insight and launch. Most organisations find around 50 steps. That map alone is often enough to create momentum with senior leadership.
The follow-on question is which steps genuinely require human judgment, and which can be automated. Some organisations have compressed a discovery process that previously took five or six months down to a week by being rigorous about that distinction.
What AI changes is the speed of the automatable work - synthesising customer feedback, aggregating usage data, monitoring competitor moves. This frees up the work that cannot be automated: talking to customers, separating real problems from symptoms, building the commercially grounded case that earns confidence.
A 2025 survey found that 94 per cent of enterprise product managers use AI daily. The gap between those who find it transformative and those who find it merely useful comes down almost entirely to input quality, not tool sophistication.
The spec is the new conversation
That shared understanding has a name. It is the spec. In an AI-native development environment, getting it right is the difference between a team that ships value and one that ships fast.
The consensus that held for two decades - write less, talk more, iterate fast - has collapsed. When your delivery mechanism is an AI coding agent, it has no memory of past decisions, no ability to infer intent, and no judgment to flag when a spec is dangerously underspecified.
The knowledge has to be in the spec. Pricing plan, analytics events, onboarding impact. These are not details you resolve in a hallway conversation when your coding agent is building at three in the morning.
AI is also changing how specs get written. The same synthesis capabilities that accelerate discovery can now generate first drafts grounded in real customer evidence, surface commonly missed sections, and flag gaps before they reach engineering.
The bottleneck has moved
Every organisation now has access to the same AI coding tools. The differentiator is who knows most clearly what to build.
What AI has changed is the cost of getting it wrong. Bad prioritisation used to produce one wasted sprint. Now it produces a wasted quarter, shipped at speed.
The product leaders who get this right are building something that compounds: discovery that is rigorous, customer understanding that runs continuously and specifications that actually reflect what customers need. Features get used, retention improves, and the roadmap earns trust because it keeps proving itself externally.
The question is not whether your team is using AI. It is whether you have built the discipline upstream that makes the machine worth running.
For product managers looking to strengthen this discipline, AI learning paths for product managers cover strategy, roadmap planning, and analytics - the inputs that determine whether velocity produces outcomes.
Your membership also unlocks:
