Discovery flipped
When building gets cheaper than validating, the order of the work changes.
I spent fifteen years doing discovery the classic way. In-depth interviews. Landing pages with lead capture. Fake doors to measure intent before writing a line of code. Problem trees on the wall. Every one of those techniques was born from a concrete constraint: building was expensive. Getting product wrong cost months of engineering and a whole team's payroll.
So we learned not to build. We built stand-ins instead. The landing page was a stand-in for the product. The clickable prototype was a stand-in for the product. The intent survey was a stand-in for a user actually using it. The entire classic discovery arsenal existed to answer, with as little code as possible, a single question: is this worth building?
That question made sense while the wrong answer was expensive. But the cost moved. With Claude Code, Cursor and AI design tools, building a lean, working version of a product became cheaper than assembling the experiment that would pretend to be the product. Sit with how absurd that is for a second: the proxy became more expensive than the real thing. Setting up a fake door campaign, buying media, waiting two weeks for data and reading ambiguous signals costs more than putting the lean version live and watching real people use it.
When that happens, the order flips. The path is no longer validate, then build. It becomes build to validate. Build first, put the real product in front of real users, and learn from behavior instead of opinion. The feedback changes quality instantly: instead of "I would use this", you see whether the person comes back the following Tuesday.
This doesn't kill the classic techniques. It repositions each one. In-depth interviews still earn their keep for small, niche products, when you need to talk to people who feel the problem first-hand and the signal volume is low. Problem trees still earn their keep for genuinely complex problems, the kind no weekend MVP solves and that demand structured thinking and patience. What changes is the bar. These techniques used to be the default path. Now each one has to justify its own cost against a new alternative: just building it. That's what product judgment has become: knowing when the proxy still pays for itself, and when it's just ceremony.
I've tested this thesis in practice. I recently shipped a complete product, from discovery to production, in five weeks, alone. Not because I work fast, and not because I cut corners. Because I stopped validating stand-ins and started validating the product. The first version was in front of real users in days, not months. Every feedback round happened on the real thing, with real usage data. Discovery didn't disappear from the process: it started happening with the product live, continuously, instead of before the product existed.
If you still spend six weeks validating whether something is worth building when building it would take three, the math no longer works. Discovery flipped.