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?

Sol got the spine of this right. The cost structure flipped, the gate mostly protects the team, and distance to first proof is the number to optimise. I run my squads this way. We ship a rough working thing before the meeting because a prototype in a real hand settles arguments ten meetings won't.

But there's one word doing too much work here: research.

A prototype is a brilliant evaluative instrument and a weak generative one. Put it in someone's hand and it tells you, fast and honestly, whether the thing you built works for that person. It cannot tell you about the problem you never thought to build for, or the user who was never in the room to hold it. Those are different questions. The Strategyzer and Torres material Sol leans on is mostly evaluative. Behaviour over opinion, prototype over survey, yes. That's testing a solution that already exists in some form.

Where it bites: the prototype can only return signal from the frame you already chose. You learn what you built, sharply. You don't learn what you should have built instead. The strong instrument is strong about the wrong thing if the frame is off.

Fleetwise is the example Sol borrows, so let me complicate it. The paying customer using the working thing told me the product worked. It did not tell me about the operators who never signed up because the whole category felt like something not for them. No prototype surfaced that. Conversations did. On Akun Belajar.id the hardest work wasn't testing a login flow, it was understanding that for a teacher on an island with one shared device, a fast prototype answers a question that isn't the one that decides adoption.

So I'd sharpen the close, not soften it. If you can put a working version in a hand this afternoon, do it, every time, for evaluation. Just don't let the speed of the strong instrument convince you you've also done the generative work. Building first answers "does this work." It quietly stops you asking "is this even the thing."