The Prototype That Wasn’t a Product

Two things look deceptively alike and yet are fundamentally different: building something to test whether it works — and building something so that it stays. This story is about what happens when you don’t name the difference early enough. It is deliberately kept general — no client, no project, no date.

Situation

A client wanted a proof of concept — the answer to a single question: is this even possible? No product, no permanent solution, just proof that a path is viable. Along the way, however, a usable interface emerged, something you could touch and operate. After this phase, the client discontinued the undertaking.

Initial assumptions

The unspoken assumption was that a good proof of concept naturally turns into a product — that one is the first step of the other. A usable interface felt like progress toward a product. In truth, these are two different undertakings with different goals, and one does not necessarily follow from the other.

Problem

A feasibility study and product development have opposing criteria for success. The study succeeds when it answers a question — even if nothing follows afterwards; its value lies in the insight, not in anything that remains. A product only succeeds when it stays and is used. If the two are not clearly separated, a false expectation arises: effort flows into something that looks like a product even though only a question was supposed to be answered — and when the answer is “yes, but we won’t do it,” that looks like failure, even though the study fulfilled its purpose.

Root cause

The cause was that the nature of the undertaking had not been sharply named. Building a usable interface imperceptibly shifted the study toward a product without anyone having decided to build a product. The transition happened through the work itself, not through a decision — and with it grew an expectation that nobody had consciously set.

Decision

The lesson led to a clear separation going forward: before starting, we name whether an undertaking is a feasibility study or product development — and what success would be in each case. A study may and should end once its question is answered. A product begins deliberately, not by a study continuing to grow.

Trade-offs

This separation costs something: you have to voice an expectation early that can be uncomfortable — that a result may end in an insight rather than a running system. That takes away the undertaking’s tempting appearance of always leading somewhere further. We would only handle it differently if it had been agreed and funded from the start that the study is to become a product — then these are two deliberate steps, not an unnoticed slide.

What we learned

Proving feasibility and building a product are two different assignments, and they have different definitions of success. A study that ends with “it works, but we won’t do it” has succeeded, not failed — provided everyone knew from the start that it was a study. The mistake is not building a study that leads nowhere; the mistake is not saying that it was a study. A usable interface does not turn a question into a product.

How it changed Batunet

Since then, before the first step, we clarify what kind of work lies ahead — answering a question or creating something lasting — and what a good ending would be in either case. That protects both sides from the false expectation that every study leads into a product. We treat the end of a study not as an abandonment, but as what it is: an answered question.

Further reading

• Guide: Why software projects really fail — why unclear goals lead to false expectations early on.
• Glossary: Cone of Uncertainty — why understanding is at its lowest at the beginning.
• Story: “That’s a quick job.” — what happens when you don’t take the nature of an undertaking seriously.
• Service: MVP development — how to get from an idea to a validated product, deliberately and in steps.

It is grounded in the Batunet Engineering Method: name the undertaking before you build — and know what success means.

A study asks whether something works. A product makes sure it stays. Whoever confuses the two mistakes an answered question for a failed product.