I hear this every week from people on our product team and product leaders I talk to across the industry. Why wait 4-6 weeks to run a research cycle when we can use AI to prototype the flow today or ship an experiment this sprint? What used to take weeks can now happen in days, sometimes hours. If AI is making us 10x faster, why should we not ship 10x as much?

As the head of product, I find myself pushing back on this more and more. The instinct isn’t wrong. But it’s incomplete.

When we move this fast, we often just build more wrong things with more confidence. We’ve quietly taken evidence out of our decision-making process and started hoping the market will correct us later.

The old world and the new

The question isn’t whether teams value evidence. Most do. The harder problem is whether the way they work gives evidence anywhere to live.

This tension predates AI. Frameworks like dual-track agile, where discovery and delivery run in parallel rather than in sequence, and continuous discovery were built because practitioners already knew the serial model (design, research, build, ship) was breaking down under delivery pressure. Teresa Torres, whose work on continuous discovery has shaped how many modern product teams operate, has argued for years that the goal isn’t more research but making customer contact a regular habit rather than a scheduled event.

What AI has done is speed up one side of the system so much that a manageable problem has become a structural one.

The serial model assumes a team can pause, learn, decide and then build. In most real product environments that’s not what happens. Teams learn, decide, and build at the same time, in Slack threads, Notion docs, Figma files, Cursor prompts, Claude conversations, and quick product reviews squeezed in between meetings.

For example:

• A developer asks an AI assistant to suggest a simpler implementation.
• A PM rewrites an onboarding journey based on a pattern they noticed in feedback.
• A designer generates five alternative flows before the team has agreed which user problem matters most.

None of these moments feel like major strategic decisions on their own. But without a shared foundation of customer insight underneath them, there’s nothing keeping them aligned. Each one looks like agility. Taken together, they can become drift.

Speed is great... until you have to redo the work

This is far from theoretical; I faced this tension first hand recently when my team completely revamped our app’s onboarding experience.

In the past, it would have taken us months to do this work: weeks of discovery and data analysis, followed by content and design work, testing with a research panel of users, and then finally launching as an experience. This time, with AI reducing the design and development cycle drastically, we were able to ship in just a few weeks.

However, when we did launch, it didn’t perform. And we had little to no insight as to why the new flow wasn’t working. So we started testing. From the first session it was obvious we had introduced significant friction early on in the flow, and our communication and value proposition wasn’t landing despite our best efforts.

The quality would have been there if we had just slowed down a little bit and gathered evidence for our assumptions or validated our solution prior to launching.

The faster research trap

The obvious response to an evidence velocity problem is to make research faster: Quicker set-up, shorter sessions, AI-enabled synthesis. That instinct isn’t wrong, but it misidentifies the problem. Speed isn’t what’s missing. Continuity is. Fast research without traceability—without being able to follow a finding back to a real person, a real session, a real moment—doesn’t build on itself. Each cycle produces an answer and then resets, leaving no foundation for a decision that comes six days later inside a Figma file or a Claude conversation. The gap doesn’t close; it just fills with something else.

That something else, for most teams under pressure, has become LLM tools that pull from public patterns, broad product assumptions, and whatever context gets pasted into a prompt. The outputs are well-written and often plausible, which is precisely the problem. A 2026 randomized trial published in npj Digital Medicine found that misleading AI explanations significantly reduced decision accuracy, while correct AI explanations made no measurable difference compared to no explanation at all. Wrong answers that sounded confident did more damage than right answers did good.

The domain is medical, but the pattern will be familiar to anyone who has watched a product team talk itself into a bad decision using a well-formatted AI summary. A polished “finding” removes the friction that usually forces a team to ask harder questions. Once that friction is gone, it’s difficult to notice what you’ve stopped asking.