Your validation gate runs the weak instrument first

The validation industry has a confident answer for what comes first. Mind the Product lays it out clean: "Validating demand and validating the problem come first. Then you come up with a solution. Finally, you validate the product you have thought up, separately." The 2026 frameworks formalized it into a pipeline. One popular Medium playbook calls the optimal process "sequential," using AI to compress the research phases, then spending the saved time on "the 15-30 customer interviews that surface what data cannot." Building sits at the end of every one of these diagrams. By design.

Grant the part that holds. Skipping research builds things nobody asked for. And changing course early, before the code hardens, is cheaper than ripping it out later. That intuition is sound. I am not arguing for shipping blind.

I am arguing the ordering assumed something that stopped being true. The whole sequence makes sense only if building is the expensive, slow, late step. The thing you protect by gating everything in front of it. That assumption broke. SVPG, no fringe voice, says new prototyping tools let you "put functional prototypes in front of users and collect data from actual use much sooner and less expensively," and that "10-20 prototypes (or prototype iterations) per week is easy for just about anyone." Parallelhq puts the number in hours: teams go "from concept to usable prototype in hours rather than weeks," and you can "test an idea with users, adjust your prompt, regenerate screens and test again, all within a single day." When building collapsed to a day, "validate first" stopped describing the cheapest path to the truth. It just describes the old cost structure.

Now the deeper problem with the ritual. The interview gate validates on what people say. Strategyzer, who sell discovery for a living, are blunt about what that is worth: "people rarely do what they say," and "asking for opinions rather than facts is the single biggest error in customer discovery interviews." Their own prescription is to chase evidence from behavior, because "evidence from the past strongly indicates future behaviour." So the validation gate collects stated intention, the least reliable signal a human emits, and then uses it to authorize the reliable thing: a working version in a real hand. You are running the weak instrument first to get permission to run the strong one. Backwards.

Name the lens. Distance to first proof: how many days until a real person uses a real version and has an opinion grounded in use, not imagination. The interview round is days of recruiting and scheduling to harvest what people predict they will do. The working version is hours to harvest what they actually do when the thing is in front of them. One of those numbers is small and the signal is behavior. Optimize that number, and the interview-first sequence loses on both axes at once.

The honest part: the best discovery people already know this, and they collapsed the split years ago. Teresa Torres calls continuous discovery "weekly touch points with customers by the team building the product," with research as "small, bite-sized activities that fit alongside other work like writing code and designing." Talking to customers, testing prototypes, running experiments, every single week. That is not validate, then build. That is build and learn in the same loop, run by the same people. The clean build-versus-research boundary the sequential frameworks defend is already gone in the practice they cite as best. The frameworks are defending the diagram, not the work.

So say what the upfront gate actually protects. The gate protects the team. It lets you be wrong in a meeting instead of wrong in someone's hands, which feels safer and teaches you less. It converts the discomfort of shipping something unfinished into the comfort of a deliverable nobody can use. The user would rather poke a rough working thing than answer a survey about a thing that does not exist.

There is one floor. Where the user cannot opt out, public-sector software pushed to millions who have no alternative, you cannot put half a thing in a real hand and call it research. The proof has to be real before it is wide. Fleetwise had a paying customer using the working thing before there was a finished argument about what it should be, so I trust this in the small. But the principle holds everywhere else.

So here is the question worth disagreeing with. If you could put a working version in a user's hand this afternoon, what is the interview round buying you, other than a few more days of being comfortably wrong?