Yes, and it's one of the cheapest insurance policies in product. Here's 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). Six months of customer requests behind it, executive sponsorship, sales buy-in, a completed design, allocated engineering capacity. Then, in the design review, I realized we had never actually watched a customer do this work. We'd 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.
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 one specific thing. I didn't explain the feature. I showed the prototype and said, "You've asked us for this. Here's what we built. Walk me through how you'd use it." Then I stopped talking. By Thursday evening the pattern 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 didn't have. A power user wanted to reuse configurations instead of starting from scratch. The last one admitted the feature wasn't 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.
I walked into the kickoff with the call notes. The pushback was immediate. "We've been planning this for six months. These are edge cases." And I said the thing that mattered: "These aren't edge cases. These are the actual cases. The linear workflow we designed is the edge case. It's elegant, it's logical, and it's wrong." We didn't 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.
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. Those five calls could have happened in the design phase, and they didn't, 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 didn't 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."