Prototype-first is my thesis. I argue for it everywhere on this site. PRD as output not input, the working prototype as the argument, build to learn instead of speccing to death. It is right for where software is going. It also has a body count, and the people selling it, me included, do not talk about it honestly. So here is the asterisk.
How a good idea dies
The death is always the same. Someone has a genuinely strong idea. Building is cheap now, so instead of arguing for it, they build a quick prototype over an afternoon. The prototype is rough, because it was an afternoon. It gets shown in a review. The room reacts to the rough thing in front of it, the reaction is lukewarm, and the idea gets shelved. Everyone feels rigorous, because hey, we prototyped it.
But nobody tested the idea. They tested a rushed first rendering of it, in a room that could not separate the two. A weak prototype of a strong idea reads as a weak idea. That is the whole tragedy. The cheapness that let them build it fast is exactly what let them kill it fast, for a reason that has nothing to do with whether the idea was good.
Why cheap building makes it worse
The counterintuitive part is that expensive prototypes used to protect against this. When a prototype cost three weeks of engineering, the cost forced a conversation first: what are we trying to learn, what do we believe, is this worth the three weeks. That friction was annoying, and it did real work. It made the team articulate a hypothesis before committing.
Now building is an afternoon, so the friction is gone and the forced hypothesis went with it. Teams generate five prototypes in a week and learn nothing from any of them, because no one said what each one was supposed to prove. Cheap building makes undisciplined teams more prolific, not more correct.
The fix is one sentence
You do not fix this by prototyping less. You reinstall the friction the cost used to provide, deliberately, as a habit. Before you build anything, write one sentence: I believe this specific user will do this specific thing for this specific reason, and I will be wrong if they do not. A falsifiable claim, out loud, before the editor opens.
Now the prototype has a job that is not just to look good. Its job is to make that sentence true or false. When you show it, you are not asking do you like this, you are asking did the user do the thing I claimed. In the review room, hold the two things apart: judge the idea against the claim, and judge the prototype as a rough first instrument. A great idea behind a clumsy build is not a dead idea. Say that in the room every time.
Before your next prototype this week, write the sentence. If you cannot write it, that is not a signal to build faster. It is a signal you do not yet know what you are testing.