How can a prototype beat a spec in a product decision?

THE SHORT ANSWER

A spec is a bet placed with no information. A prototype buys the information. When a feature was stuck in a three-week spec review, I built a clickable version in an afternoon, put it in front of five customers, and four of five reached for the wrong control first. That failure mode was invisible in the doc because everyone reviewing it already knew where the button was. The prototype did not win by being better looking. It won by producing evidence, and when the cost of being wrong drops to half a day, evidence beats argument every time.

A spec and a prototype are trying to answer the same question: should we build this, and how should it behave? The difference is where the answer comes from. A spec compounds the opinions of the people reviewing it. A prototype extracts behavior from the people who will actually use it. When those two disagree, the prototype is right, because it is the only one holding evidence.

The mechanism

I watched a feature sit in review for three weeks: a twelve-page spec, four reviewers, and a debate that would not resolve. Every review added detail and closed nothing, because every open question was about what a confused user would do, and nobody in the room had been confused by the product in years. We were raising the stakes on a bet instead of buying the information that would settle it.

So I stopped writing and built it. About four hours with Claude Code, ugly, one path working. The next morning I put it in front of five customers and said nothing. Four of the five reached for the wrong control first. The smart default the entire spec was built around sat there, correct, and they ignored it, because they did not trust a value they had not chosen themselves. That failure mode was never going to appear in a document written by people who already knew where the button was.

Why this works now and did not before

When building a feature cost three months of engineering, the spec was cheap insurance against an expensive mistake. Now building the throwaway version costs an afternoon, so the spec is no longer insurance. It is a slow substitute for the cheap experiment that answers the question directly. The cost of being wrong collapsed, and the order of operations should collapse with it: prototype first, evidence second, doc last.

The rule I follow: take the decision your team has argued about longest, build the smallest clickable version of the one path in dispute, and put it in front of five people who do not already agree with you. The argument you cannot win in a document usually dissolves the moment a real person touches the thing.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-08-12 · 2 min read