Engineers got Cursor. Designers got AI-assisted Figma. Product managers got... a slightly faster way to format their Notion docs.
The gap is striking when you lay it out. Code generation tools have fundamentally changed how engineers work - Cursor autocompletes entire functions, suggests refactors, and explains unfamiliar codebases. Design tools bake in AI for generating component variants and accessibility checks. But the product manager sitting between these two groups is still manually reading through 50 support tickets, toggling between Amplitude and their notes, and writing product requirements documents from scratch.
This isn't a coincidence. Product discovery - the messy work of figuring out what to build and why - is genuinely harder to automate than code generation or design assistance.
Why Discovery Resists Automation
Code has clear syntax rules. Design has established patterns. Product discovery is fundamentally about synthesizing contradictory signals: the support ticket that represents a vocal minority, the usage data that shows what people do versus what they say they want, the strategic bet that can't be fully justified by numbers alone.
AI is extremely good at pattern matching and generation within defined constraints. Product discovery requires something different: judgment about which patterns matter and which to ignore, informed by context the model doesn't have access to.
When a PM reads 50 support tickets, they're not just extracting themes. They're asking which complaints represent a real problem versus user error, which features would actually drive retention versus satisfy a squeaky wheel, and which requests align with where the product is going. Those questions require knowing the product's strategy, the competitive landscape, and sometimes the specific users in ways that are hard to pass into a prompt.
What Actually Exists Today
Some tools are making inroads on the mechanical parts of discovery. Dovetail and similar research analysis tools can cluster user interview transcripts and tag themes automatically. Pendo and Amplitude now surface AI-generated summaries of behavioral patterns. A handful of PM-focused tools will draft sections of a product requirements document if you give them a problem statement.
But none of this touches the core judgment layer. The synthesis is still manual. The "should we build this?" question - weighing feasibility, desirability, business value, and timing - still lives in someone's head.
The tools that exist mostly automate the note-taking and organizing. That's useful, but it's not discovery. It's record-keeping.
The Harder Problem
Discovery isn't a solo activity that can be handed to an AI agent. It involves conversations with users, negotiation with stakeholders, and synthesis sessions with engineering and design. The workflow is inherently collaborative and messy in a way that a text box doesn't capture well.
For AI to meaningfully help with product discovery, it would need persistent context across months of decisions, awareness of the org's strategic priorities, understanding of technical constraints from the engineering side, and the ability to reason about what users actually need versus what they ask for. That's a significantly harder problem than generating code from a description.
The tooling will get there eventually. Longer context windows (which let models hold more conversation and document history at once), better multi-source synthesis, and tighter integration with the data sources PMs actually use are all improving. But right now, the discovery workflow is mostly untouched.
Until the tooling catches up, product managers are doing the same manual synthesis work they were doing two years ago - just with a better spell checker.