Yes, and it is one of the cheapest insurance policies in product. Here is the story. It was a Tuesday. We were 48 hours from kicking off a full-squad Q2 feature: three engineers, one designer, one PM (me). The feature had six months of customer requests, executive sponsorship, sales buy-in, a completed design, and allocated engineering capacity. Then, in the design review, I realized we had never actually watched a customer do this work. We had asked them what they wanted, they told us, and we built what they said. So I asked for three days to test the design with five customers. The answer: you have until Friday.
The prototype and the calls
I used Claude Code to generate a rough clickable prototype in about two hours. Zero polish, just the core workflow: pick a template, configure parameters, apply across environments, review, confirm. Linear, logical, exactly what the design doc said. I scheduled five discovery calls across early-stage, mid-market, and enterprise, all customers who had requested the feature.
On the calls I did something specific: I did not explain the feature. I showed the prototype and said, "You have asked us for this. Here is what we built. Walk me through how you would use it." Then I stopped talking. The pattern by Thursday evening was clear and consistent. One customer wanted to batch operations across weeks, not all at once. Another wanted to explore parameters before committing rather than knowing them up front. An enterprise customer needed a collaboration and approval handoff the review step did not have. A power user wanted to reuse configurations instead of starting from scratch. The last one admitted the feature was not quite what they needed and asked to just save and reload state. Our linear workflow was wrong. Everything we had designed was, roughly, in reverse.
The Friday decision
I walked into the kickoff with the call notes. The pushback was immediate: "We have been planning this for six months. These are edge cases." And I said the thing that mattered: "These are not edge cases. These are the actual cases. The linear workflow we designed is the edge case. It is elegant, it is logical, and it is wrong." We did not start Monday. We took a week.
The redesign was a pivot, not a rebuild. We flipped the logic from "you know what you want, enter it" to "explore first, then confirm," added a collaboration layer three of five customers had asked for, and built in automatic persistence. We started development the following Monday, lost two weeks of schedule, and shipped in May instead of April. Adoption was immediate: target DAU in week one, stable by month three. The alternative was shipping in April, spending May and June fixing the workflow, and re-shipping in July.
Why the two hours worked
The prototype was nothing special. What it did was force a different conversation: not "do you want this?" but "when you have this, how do you use it?" The first question gets affirmation. The second gets behavior. The five calls could have happened in the design phase, but they did not, because a "done" design feels less worth validating than a rough sketch. That instinct is backwards. This is the same reversible-versus-irreversible judgment behind naming the match before you bet, and the assumption testing framework has a section on exactly this: the most expensive assumption is "customers said they want X, so X is the right answer."
The prototype did not save the project. The customer behavior did. The prototype just made it visible early enough to matter. Before your next full-squad kickoff, spend two hours building a rough clickable version and run five walkthrough calls where you say nothing and watch. Catch the wrong workflow at "prototype and five calls," not at "six months of development and customer frustration."