When a prototype answers a strategy question better than a document

We build prototypes of our recommendations, and clients sometimes read that as a preference for making things over thinking about them. It is the opposite. We build prototypes because certain questions cannot be resolved by thinking harder or writing more clearly. They can only be resolved by putting a working version in front of people and watching what happens. The skill is knowing which questions those are, and scoping the prototype so it answers one of them cleanly.

Documents are good at some questions and bad at others

A written recommendation is the right tool when the disagreement is about facts, priorities, or trade-offs that everyone can reason about from shared information. If the question is whether to enter a market, or how to sequence a roadmap against a budget, or what a system’s architecture should be at a high level, a document forces the argument into the open where it can be examined. Writing is thinking, and a good strategy memo earns its place.

Documents start to fail when the question depends on how something feels to use, whether a technical approach actually holds together under real conditions, or how real people behave when confronted with a specific interface rather than a description of one. In those cases a document can describe the proposed answer perfectly and still leave the actual question unresolved, because the words are standing in for an experience that no one in the room has had yet. Everyone nods at the paragraph and then disagrees the moment they see the thing.

The tell is a meeting that keeps circling. When a group has read the same clear document three times and still cannot converge, the disagreement is usually not about the argument. It is about a mental picture that each person is filling in differently. A prototype replaces the mental pictures with a single shared object, and the disagreement either resolves or turns into a much sharper and more useful one.

What a prototype is actually for

A prototype is an instrument for reducing a specific uncertainty. It is not a small version of the product and it is not a demo built to impress. Before we build one, we try to name the single question it exists to answer, and we resist the pull to make it answer more than that.

The questions worth a prototype tend to fall into a few kinds. Some are about feasibility: can this integration actually be made to work, does this data support the feature we want to build on top of it, does the performance hold when the inputs are realistic rather than convenient. Some are about experience: does this flow make sense to someone who did not design it, where do people hesitate, what do they try that we did not anticipate. Some are about value: when a real person can use the thing, do they want to, and does the behavior we were counting on actually appear.

Each of these is a question a document can pose but not settle. You settle a feasibility question by building the risky part and seeing whether it holds. You settle an experience question by watching someone who did not design the flow try to use it, and a value question by observing what people actually do rather than what they say they would do. In every case the prototype exists to convert an argument into evidence.

How to scope one so it stays honest

The failure mode of prototyping is building too much. A prototype that tries to be a small product takes as long as a small product, costs the credibility of the method when it runs late, and buries the one question it was supposed to answer under a hundred incidental decisions. The discipline is to build only what the question requires and to be deliberately, visibly incomplete everywhere else.

We scope a prototype backward from the uncertainty. First we state the question in a single sentence and agree on what a clear answer would look like, including what result would tell us the recommendation is wrong. That last part matters. A prototype that cannot fail is a demo, and a demo teaches you nothing you did not already believe. If there is no outcome that would change the decision, there is no reason to build.

Then we build the smallest thing that can produce that answer. For a feasibility question that usually means the risky technical core with everything around it faked or hard-coded. For an experience question it means one real flow, working end to end, with the rest of the product stubbed out and obviously so. For a value question it means enough of a real experience that a real person’s behavior is meaningful, and no more. What we leave out is as considered as what we put in, because every part we build that the question does not need is time spent not answering it.

Finally we agree in advance on how the result gets read. A prototype answers its question through observation, and observation is easy to rationalize after the fact. Deciding beforehand what we are watching for, and what each possible result would mean, keeps the exercise from collapsing into everyone seeing what they already expected to see.

The payoff is a decision made against something real

The reason we build prototypes as part of advisory work is that a recommendation defended only on paper is a recommendation everyone is free to imagine differently. A recommendation you can put in front of people, watch them use, and measure is a recommendation that has already survived contact with reality before anyone commits budget to it. The decision gets made against a working thing rather than a described one, which is a much stronger position to be in.

This does not replace strategy work. It completes it. The document sets the direction and makes the argument. The prototype tests the part of the argument that words cannot reach. Used together, they let a team commit with more confidence and less risk than either could provide alone, and they turn the hardest kind of disagreement, the kind about a thing no one has experienced yet, into a question with an answer.