Discovery is the real AI bottleneck — not engineering

Teams obsess over shipping AI faster while the 60-day discovery cycle in front of it goes unexamined. Here's how we cut ours to 40 days, and what broke along the way.

Ask a product org where their delivery bottleneck is and they will point at engineering. Almost always. Backlog depth, sprint velocity, capacity planning — the whole apparatus of product management is built around the assumption that building is the expensive part.

Then you measure the cycle honestly and find that the sixty days before the first sprint are where the time actually went.

Where the sixty days go

Discovery for an enterprise feature is not one activity. It’s a chain: recruit participants, run interviews, transcribe them, synthesise across them, reconcile what you heard with what the analytics say, socialise the finding, get alignment, write the PRD.

Each link is individually reasonable. Together they add up to two months, and the expensive part is not the interviewing. It’s the synthesis — the slow, manual work of reading thirty transcripts and finding the pattern that three of them share.

That’s the step I went after.

What we actually built

I architected and vibe coded an AI-driven discovery agent — built in Cursor and Claude Artifacts, not by an engineering team — that automates user-insight extraction from research conversations. It ingests transcripts, clusters observations by underlying job-to-be-done rather than by keyword, surfaces contradictions between what users said and what the product telemetry shows, and produces a first-pass synthesis a human researcher then edits.

Discovery went from 60 days to 40. A third of the cycle, removed.

The number that matters more, though, is a different one: the quality of the synthesis went up, because the agent doesn’t get tired around transcript nineteen and it doesn’t unconsciously privilege the interview it happened to run most recently.

Three things that broke

I want to be specific about the failures, because “we automated discovery and it worked” is the kind of sentence that helps nobody.

It found patterns that weren’t there. Clustering models are enthusiastic. Early versions confidently grouped observations that shared vocabulary but not meaning — two users saying “workflow” about completely different problems. The fix wasn’t a better prompt; it was requiring the agent to cite the specific transcript line behind every claimed pattern, so a human could check it in seconds. Traceability turned out to be the whole feature.

It flattened the outliers. Synthesis rewards frequency, and the most valuable thing in a research round is often the one user who said something nobody else did. We had to explicitly instrument for anomalies — a “said once, said strongly” surface — or the tool would have made us systematically less curious.

People trusted it too fast. This was the dangerous one. Once the output looked polished, reviewers stopped interrogating it. A confident-sounding synthesis with a clean layout gets less scrutiny than a messy human one, regardless of which is more accurate. We now present the agent’s output explicitly as a draft with visible confidence gaps, because a tool that suppresses scrutiny is worse than no tool.

The general lesson

Every product org has a step like this: high-effort, low-glamour, invisible in the sprint metrics, and sitting directly in front of everything else. Discovery synthesis was ours. Yours might be requirements reconciliation across stakeholders, or competitive analysis, or the compliance review that adds three weeks to every release.

The instinct with AI is to point it at the visible work — the customer-facing feature, the thing in the demo. The higher-leverage move is frequently to point it at your own operating model first. It’s lower risk, you are your own user, and the payback compounds across every subsequent project rather than a single feature.

And there’s a second-order benefit that’s easy to miss: building an internal AI tool teaches your team what AI is actually good and bad at, using a problem where you can tolerate the failures. That organisational fluency is worth more than the forty days.

What I’d tell a team starting this

Measure the cycle before you optimise it, and measure it in wall-clock days rather than effort. Effort-hours hide the waiting.

Pick the step that is expensive and repetitive and where a human reviews the output anyway. That last condition is what makes it safe to start.

And build the traceability before you build the intelligence. An AI synthesis you can’t audit is a rumour with good typography.

  • AI Product Management
  • Product Discovery
  • Operating Model