Does continuous discovery scale for AI-native products?

THE SHORT ANSWER

No. Teresa Torres' continuous discovery is the right model for human-centric SaaS and the wrong one for AI-native products, because agent products break the deterministic feedback loop it assumes in three places: the agent generates behaviors users never anticipate, causality is fuzzy in non-deterministic systems, and the weekly cadence is too slow. The alternative is punctuated discovery: three-week intense discovery sprints sandwiched between eight-week build phases, with a 60/40 split of agent testing to customer interviews.

I have a respectful argument with Teresa Torres. Her continuous discovery, one to two hours of customer interviews a week, forever, shaped how a generation of PMs learn from customers, and it is right for the products her frame was built for. It is wrong for AI-native products, and the field has not done that update yet.

Where the deterministic loop breaks

Continuous discovery assumes a clean loop: customer expresses pain, team builds feature, adoption signals validate or falsify. Agent products break that loop in three places.

First, agent behavior is not customer-anticipated. In deterministic SaaS a customer says "I want a faster way to filter invoices by date." In an agent product the customer says "the agent broke," and the bug is in a corner they never thought to mention because they did not know it was a corner. Interviews still tell you the job-to-be-done and almost nothing about the actual surface, which is generated dynamically. You discover the surface yourself by running the agent against real workloads.

Second, causality is fuzzy. The Opportunity Solution Tree works because you can trace an outcome back to an opportunity back to a solution. In an agent product the same input gives different outputs across runs, adoption signals are noisier, and retention causes are diffuse. The tree collapses at branch points where causality is fuzzy.

Third, the cadence is wrong. Continuous discovery's weekly hour is tuned for a product that ships every six weeks and customer needs that evolve over months. Agent products change daily as the model drifts, prompts evolve, and customer expectations shift weekly. Weekly interviews are too slow.

What I run instead

Punctuated discovery, three rules. Discovery is bounded and intense, not continuous: eight weeks of building, three weeks of pure discovery, repeat. Three weeks of full attention produces ten times the insight of three months of one-hour-per-week sessions that keep getting interrupted by build work.

Sixty percent of the discovery sprint is agent testing, not customer interviews: 40 percent interviews, 40 percent agent testing, 20 percent competitive and ecosystem surface. The 60/40 inversion is not a downgrade of customer voice. It recognizes that the customer is now one of three signals that matter, not the only one.

Discovery ends in a commit document with three sections: what we learned, what we will test, and what we will ship, each with success criteria. Without it the sprint becomes interesting conversations that never reach shipped product.

What to try this week

Run the numbers on your last quarter. How many hours did your team spend on customer interviews, and how many on agent testing? If the ratio is 90/10 or higher and you ship an agent product, you have a discovery model mismatch: the right frame for the wrong product. The fix is not more interviews. It is allocating engineering time to agent testing in the next discovery sprint with the same seriousness as interviews. Three weeks, 40 percent allocation, a written commit document at the end. Try it for one cycle and the team's mental model of the product surface will visibly change.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read