A prototype can promise. A product must answer

A prototype makes the idea visible

A good prototype answers an important early question: can this scenario be experienced as a coherent whole? It connects intention, sequence and interface. It reveals whether a person can see the next step, whether the logic holds together and whether further development is justified.

The prototype is allowed to be incomplete. Its data may be prepared in advance, a complex action may be simulated and some states may be absent. Its purpose is not to conceal these conditions but to make the Concept available for examination as quickly as possible. The difficulty begins when a convincing image is mistaken for a working system.

AI has intensified this illusion. A screen, transitions and part of the logic can now be assembled quickly enough to resemble a finished service. That speed is valuable, but visual completion arrives earlier than technical and organisational readiness. Most of the real product still lies between them.

An MVP tests one central assumption

An MVP is often treated as a smaller version of the future product. A team then tries to include a little of everything: profile, notifications, settings and analytics. The result is a small system with a large surface of uncertainty.

I see an MVP differently. It must prove the central assumption from beginning to end. If the value lies in producing an accurate estimate, the first version must take a person from their initial information to that result. If the product promises to preserve project context, the test is not a polished note form. It is whether someone can return a week later and continue without reconstructing the work by hand.

There may be few features, but the main journey cannot be decorative. It must end in a result that can be accepted, rejected or compared with the previous way of working.

A product begins when consequences appear

A real person enters unexpected data, closes the screen halfway through an action, returns on another device, loses connection and presses a button twice. They have permissions, expectations and information that must not be shown to others. An external service changes its terms, a payment is not confirmed or a notification fails. A product needs an answer to these states.

Cost and maintenance belong to the same boundary. Who will see a failure? Can data be recovered? What happens when an external service reaches its limit? Can another person continue developing the system? These questions are almost invisible in a demonstration, yet they determine whether real work can be entrusted to the product.

As in object production, a working model and an artefact intended for daily use demand different depths of resolution. A chair may look complete, but until its joints, load, stability and repeatability have been tested, it remains a promise of form. A digital object carries the same responsibility even when its weaknesses cannot be seen.

Acceptance begins before development

“It seems to work” usually means that the result was never defined in advance. Without an observable outcome, readiness has to be judged by impression. The screen resembles the design, the transition opens and the console contains no errors, so the work moves on. An unnoticed decision made by a model or developer gradually becomes part of the product.

Before implementation, I try to state the observable behaviour. What does the person do? What do they see afterwards? Where is the result stored? What happens when the action fails? Which areas must remain untouched in this iteration? The implementation is then checked against this contract. Anything invented along the way becomes a separate decision to accept or remove.

Tests are useful when they prove that scenario. They do not replace a live examination of the interface, just as looking at a screen cannot replace checking data and permissions. Readiness requires several forms of evidence.

Release does not complete the product

After launch, facts appear that were absent from the design model: real questions, mistaken expectations, new forms of use and moments where a person still needs help. These are not interruptions to the original decision. They are material for the next version.

Within the Method, a prototype allows the Concept to meet reality early. An MVP limits that meeting to one central assumption. A product emerges when the form can withstand the consequences of use and remain intelligible after its first impression. Its quality is measured less by how quickly it was assembled than by how confidently it continues to work after the demonstration.

From an idea to a digital product

If the task calls for a service or internal tool, we can define the first complete journey and a path to a working release.

Discuss a digital product