AI Didn't Replace Product Discovery. It Just Made Me Realize How Bad I Was At It

I used to think product discovery meant talking to users, writing down their problems, and building solutions. Then I spent three months at Sonic Linker watching AI completely change what that process actually looks like.

Here's what I mean: we built an AI SaaS platform from scratch. Fast. But about halfway through, I noticed something weird. Our AI could generate outputs in seconds, but I was spending days trying to figure out if those outputs actually mattered to users. The speed of building had completely outpaced my ability to validate.

That's when it hit me. AI doesn't just change what you build. It changes how you figure out what to build in the first place.

The Old Playbook Breaks Down When Build Time Drops to Zero

Traditional product discovery has this built-in brake system. You talk to users, prototype something, wait for dev cycles, ship it, measure, repeat. Each step takes time. That time forces you to think.

With AI, that brake system is gone. I could spin up a working feature in an afternoon. Which sounds great until you realize you can also ship the *wrong* feature in an afternoon.

At Sonic Linker, we learned this the hard way. We built an AI workflow automation tool that technically worked perfectly. The model was solid. The outputs were accurate. But we hadn't spent enough time understanding the *context* in which people would use it. Turns out, our users didn't need faster automation. They needed *legible* automation, something they could explain to their teams.

We only figured that out after shipping. Because we could build so fast, we skipped the harder questions. What does success look like here? Who's actually going to use this daily? What happens when the AI is wrong?

AI makes building easy. It makes *thinking* harder to justify. And that's dangerous.

Discovery Now Means Testing Assumptions in Production, Not Before It

The other thing that changed: I used to do discovery upfront, then move to execution. Clean handoff. But with AI products, that line blurs completely.

At Finvestfx, we managed enterprise clients who needed specific treasury workflows. Traditional SaaS meant we'd gather requirements, build a feature, deploy it months later. Feedback loop was slow but predictable.

Now imagine that same scenario with an AI layer. Suddenly, I can configure a custom workflow for a client in a day. Which means discovery isn't a phase anymore. It's continuous. I'm learning what they need *while* they're using it, because I can iterate that fast.

This sounds efficient, but it's also chaotic. I found myself in this weird loop: ship a feature, get feedback, tweak the AI behavior, ship again, get different feedback. Repeat. The problem wasn't the speed. It was that I lost track of whether I was discovering a real need or just chasing edge cases.

The fix? I started treating every AI-powered iteration as a hypothesis. Not a solution, a test. "We think this output format will help treasury teams reconcile faster." Ship it. Measure time-to-reconciliation. If it doesn't move, kill it. If it does, double down.

AI doesn't let you do discovery once and move on. It forces you to do discovery in production, constantly. And if you're not disciplined about what you're testing, you'll just build faster garbage.

The Questions That Actually Matter Now

Here's what I ask now that I didn't ask before:

Can users explain what the AI just did? If they can't, it doesn't matter how accurate the model is. I learned this at Sonic Linker. Our AI could generate perfect outputs, but if users couldn't tell their managers *why* it made that decision, they wouldn't trust it. Explainability isn't a feature. It's the whole product.

What happens when the AI is wrong? Traditional software breaks in predictable ways. AI fails differently every time. At Finvestfx, we had to design workflows assuming the AI *would* mess up occasionally. That meant discovery wasn't just about happy paths anymore. It was about failure modes. How do users recover? Do they even know it failed?

Is this solving a capability gap or a confidence gap? This is the big one. Sometimes users don't adopt AI features because they *can't* do something. But more often, they don't adopt because they don't *trust* it yet. Discovery now means figuring out which problem you're solving. And they require completely different solutions.

At NJ Group, I coached 60+ insurance advisors on product adoption. Half the battle wasn't teaching them what the product did. It was convincing them it wouldn't screw up their client relationships. Same thing applies to AI features. If discovery doesn't account for trust, you're building something nobody will use.

What This Means for PMs

AI didn't make product discovery obsolete. It just made it *way* harder to fake. You can't hide behind long build cycles anymore. You can't blame engineering for delays. If you're not talking to users, testing hypotheses, and killing bad ideas fast, it shows immediately.

The good news? If you actually commit to discovery, AI makes you dangerously effective. You can test 10 ideas in the time it used to take to test one. You can personalize experiences in ways that were impossible before. You can learn in production without breaking things.

But only if you're honest about what you don't know. And only if you're willing to kill features as fast as you ship them.

That's the real shift. AI didn't change *what* product discovery is. It just made it impossible to pretend you're doing it when you're not.