The best prototypes don't answer anything. That's not a complaint about prototypes that fail to prove a thesis — it's a different claim about what a good one is actually for. A prototype's job isn't to confirm what the slide deck already said would happen. It's to let a room disagree about something concrete instead of something abstract — to take a debate that's been circling for two quarters in adjectives and give it a shape people can point at and argue over directly.
Abstract disagreement is comfortable in a specific, costly way. Two executives can debate whether an agentic assistant "should feel proactive" or "should feel deferential" for an entire meeting without ever resolving anything, because both positions are compatible with every slide in the deck. Nobody has to be wrong. Nobody has to update their position, because there's nothing concrete enough to update it against. The conversation can repeat itself at the next meeting with the same energy and the same lack of movement.
Put a working prototype in front of the same two people — one that actually offers a suggestion, actually waits for confirmation, actually behaves one way instead of the other — and the debate changes shape immediately. Now someone can say "that felt pushy" or "that made me wait too long" about an actual interaction that just happened, not a hypothetical one. The disagreement gets smaller and more specific, which is exactly backwards from how it sounds: a vague disagreement about philosophy is actually much harder to resolve than a specific disagreement about one concrete interaction, because the specific one can be tested, adjusted, and tried again in the room.
This is the entire logic behind building fast, narrow, and real instead of comprehensive and theoretical. A two-week Rapid Launch isn't trying to prove the final version of anything. It's trying to produce the smallest object that can hold the actual disagreement — one working prototype, scoped tightly enough to build in two weeks, built real enough that people react to it the way they'd react to the finished thing, not the way they'd react to a mockup they know isn't real. A mockup gets polite feedback. A working prototype gets honest reactions, because people respond to things that behave like they'll actually ship.
There's a cost to skipping this step that rarely shows up until much later. Teams that go straight from strategy deck to full build end up litigating the same abstract disagreements deep into implementation, when changing course is expensive and slow — the proactive-versus-deferential debate that could have been settled in a two-week prototype instead gets settled, badly, six months in, after real budget and real credibility have been spent defending whichever side happened to win the original slide-deck argument.
A prototype you can touch doesn't eliminate disagreement. It relocates it to the cheapest possible place to have it.
A prototype you can touch doesn't eliminate disagreement. It relocates it to the cheapest possible place to have it — early, concrete, and reversible — instead of the most expensive place, which is in production, after the thing has already shipped and the disagreement has become a postmortem instead of a conversation.