Prototype-Driven Development: from conversation to evidence

Two people can leave a meeting convinced that they agreed on the same thing while imagining completely different products. The problem rarely appears in the minutes. It emerges weeks later, when something that has been built forces us to specify what words such as “simple”, “fast” or “automated” were supposed to mean.

For years, we tried to reduce that risk by writing more: requirements, specifications, user stories and diagrams. All of them can help, but no document eliminates interpretation. The newer the solution, the less shared language we have to describe it.

Prototype-Driven Development starts from a different idea: when uncertainty is high, the first result of the work should not be a finished solution. It should be evidence that we can observe together.

A prototype is not a cheap version of the product

A good prototype answers a question. It may be a navigable interface, an automation using controlled data, a simulation, a carefully represented manual flow or a small piece of real software. Its fidelity depends on the decision we need to make.

If we want to know whether someone understands a process, we need an observable interaction. If we want to check whether an integration is possible, we need code running against the right system. If the question is commercial, a concrete proposition that someone can accept or reject may be enough.

The quality of a prototype is not measured by how closely it resembles the final product. It is measured by the quality of the conversation it creates and the decision it makes possible.

A cycle of five movements

The method can be understood as a loop:

1. Observe. Understand the context, constraints and current behaviour before proposing an answer.
2. Reframe. Turn a broad request into a question that can be resolved with evidence.
3. Create. Build the smallest thing that makes the important hypothesis visible.
4. Learn. Put it in front of the people who know the problem, observe their reaction and record what changes.
5. Evolve. Decide whether to move forward, correct, integrate, discard or start another cycle.

The order helps explain the method, but the work is not a chain of hand-offs. While creating, we may discover a constraint that forces us to reframe the question. While learning, a risk may emerge that requires us to observe again. The value lies in keeping the distance between each finding and the next action short.

Agents make the method more necessary, not less

AI dramatically reduces the cost of producing a first version. That is an advantage, but it also makes it easier to build something nobody needed with remarkable efficiency. When execution becomes cheaper, the ability to frame the right question and recognise useful evidence becomes more important.

Agents can explore alternatives, write code, prepare data, test scenarios and document results. Human direction still decides what deserves to be tested, what risk is acceptable and what evidence is sufficient to move forward.

The goal is therefore not to “build prototypes faster”. It is to compress the entire cycle between intent, reality and learning.

What remains afterwards

A cycle should leave behind something more valuable than a demo: a better decision, a discarded hypothesis, a shared criterion, a discovered risk or a capability the team can reuse. Sometimes the prototype continues until it becomes a product. At other times, fulfilling its purpose means being able to throw it away without regret.

Sources and references

• Principles behind the Agile Manifesto.
• Primary source: the experience and method developed by Victor H. Sáez.