I Used to Spend Weeks Planning Discovery Sprints. Now I Ship Prototypes in 3 Days and Learn Faster.
Six months ago, I would block off two weeks for discovery before writing a single line of a PRD. User interviews, synthesis sessions, affinity mapping, the whole ritual. It felt responsible. Thorough.
Then at Sonic Linker, we needed to validate whether our AI linking logic actually solved the problem users described. I didn't have two weeks. I had maybe three days before our next sprint planning.
So I did something different. I used Claude to generate five different prototype concepts based on raw interview transcripts. Dropped them into Figma in four hours. Sent them to eight users the next morning. By end of day two, I knew which direction would work.
That's when I realized AI isn't just making discovery faster. It's fundamentally changing what discovery even means.
The Old Discovery Playbook Is Built on Scarcity
Traditional discovery assumes you can't afford to build the wrong thing. So you front-load all the research. You talk to 15 users, synthesize for a week, write a detailed spec, then finally build.
This made sense when building anything took two sprints minimum. The cost of being wrong was enormous.
But now? I can spin up a working prototype of an AI feature in a day. Not a Figma mockup. An actual functional prototype with real AI behavior that users can interact with.
At Sonic Linker, we tested three different approaches to how our AI surfaces cross-document connections. I built all three versions in TypeScript using GPT-4's API in about six hours total. Showed them to users the same week. One approach had 4x better engagement than the others.
If I'd spent two weeks doing traditional discovery first, I would have picked the wrong approach. I know because the one that worked wasn't the one users said they wanted in interviews.
Build-Measure-Learn Actually Works Now
I used to think build-measure-learn was startup propaganda. In practice, building anything meaningful took so long that you had to get it right the first time.
AI changed the build time. Now the loop actually closes fast enough to be useful.
When I was figuring out pricing tiers at Finvestfx, I couldn't A/B test pricing pages with 20 enterprise clients. Too risky. So I did what everyone does: researched competitors, talked to clients, made my best guess.
Now? I would build five different packaging concepts as interactive prototypes, each with slightly different feature bundles and AI capabilities. Show them in user calls. Watch where people's eyes go. Ask them to explain what they think each tier does. You learn so much more than asking "would you pay for this?"
The discovery happens in the interaction with the prototype, not in the abstract conversation about hypothetical features.
The Questions Changed
I used to ask users: "What's your biggest pain point with X?" Then I'd spend weeks validating whether that pain point was real and big enough.
Now I ask different questions. I show them a working AI feature and ask: "Does this actually solve it?" And I can ask that question on day three, not week six.
At Sonic Linker, we thought users wanted the AI to automatically link everything. Seemed obvious. Every interview confirmed it.
Then I built it. Showed it to users. Turns out auto-linking everything creates a different problem: users don't trust links they didn't create. The feature that actually worked was AI-suggested links that users could accept or reject.
I learned this in one week of showing prototypes. I would never have discovered it in interviews, because users don't know how they'll feel about AI suggestions until they see them.
What This Actually Means for How I Work
I still do user interviews. But now they happen in parallel with building, not before it.
Week one: rough prototype based on my hypothesis. Week two: show it to five users, rebuild based on what breaks. Week three: show the new version to five more users.
This is faster than the old model and I learn more, because I'm validating real behavior, not hypothetical preferences.
The hard part isn't the AI tools. It's letting go of the idea that you need perfect clarity before you build anything. I was trained to de-risk everything upfront. AI makes it cheaper to just build the risk and see if it's real.
The Real Shift
AI didn't make discovery obsolete. It made a different kind of discovery possible.
I spend less time trying to predict what users want and more time showing them things and watching what happens. Less synthesis, more iteration. Less planning, more shipping.
At Sonic Linker, we shipped our core product in three months because we stopped treating discovery as a separate phase. We built, we learned, we rebuilt. The AI tools made the build step cheap enough that this actually worked.
The PMs who win in the next few years won't be the ones who do the most thorough research upfront. They'll be the ones who can loop from idea to working prototype to user feedback the fastest. AI just made that loop about 10x faster than it used to be.