Der Prototyp, der kein Produkt war

Zwei Dinge sehen sich zum Verwechseln ähnlich und sind doch grundverschieden: etwas bauen, um zu prüfen, ob es geht — und etwas bauen, damit es bleibt. Diese Geschichte handelt davon, was passiert, wenn man den Unterschied nicht früh genug benennt. Sie ist bewusst allgemein gehalten — ohne Kunden, ohne Projekt, ohne Zeitpunkt.

Situation

Ein Kunde wollte einen Machbarkeitsnachweis — die Antwort auf eine einzige Frage: Geht das überhaupt? Kein Produkt, keine dauerhafte Lösung, nur der Beweis, dass ein Weg gangbar ist. Im Verlauf entstand jedoch eine benutzbare Oberfläche, etwas, das man anfassen und bedienen konnte. Nach dieser Phase stellte der Kunde das Vorhaben ein.

Ausgangsannahmen

Die stille Annahme war, dass ein guter Machbarkeitsnachweis von selbst in ein Produkt übergeht — dass das eine der erste Schritt des anderen sei. Eine benutzbare Oberfläche fühlte sich wie Fortschritt in Richtung Produkt an. In Wahrheit sind es zwei verschiedene Vorhaben mit verschiedenen Zielen, und das eine folgt nicht zwangsläufig aus dem anderen.

Problem

Eine Machbarkeitsstudie und eine Produktentwicklung haben gegensätzliche Erfolgskriterien. Die Studie ist erfolgreich, wenn sie eine Frage beantwortet — auch dann, wenn danach nichts weitergeht; ihr Wert liegt in der Erkenntnis, nicht im Bestand. Ein Produkt ist erst erfolgreich, wenn es bleibt und benutzt wird. Werden beide nicht klar getrennt, entsteht eine falsche Erwartung: Aufwand fließt in etwas, das nach Produkt aussieht, obwohl nur eine Frage beantwortet werden sollte — und wenn die Antwort „ja, aber wir machen es nicht" lautet, wirkt das wie ein Scheitern, obwohl die Studie ihren Zweck erfüllt hat.

Ursache

Die Ursache war, dass die Art des Vorhabens nicht scharf benannt war. Eine benutzbare Oberfläche zu bauen, verschob die Studie unmerklich in Richtung Produkt, ohne dass jemand entschieden hätte, ein Produkt zu bauen. Der Übergang geschah durch die Arbeit selbst, nicht durch eine Entscheidung — und damit wuchs eine Erwartung, die niemand bewusst gesetzt hatte.

Entscheidung

Die Lehre führte zu einer klaren Trennung für die Zukunft: Vor Beginn wird benannt, ob ein Vorhaben eine Machbarkeitsstudie oder eine Produktentwicklung ist — und was jeweils der Erfolg wäre. Eine Studie darf und soll enden, wenn ihre Frage beantwortet ist. Ein Produkt beginnt bewusst, nicht durch das Weiterwachsen einer Studie.

Trade-offs

Diese Trennung kostet etwas: Man muss früh eine Erwartung aussprechen, die unbequem sein kann — dass ein Ergebnis womöglich in einer Erkenntnis endet und nicht in einem laufenden System. Das nimmt einem Vorhaben den verlockenden Anschein, immer weiterzuführen. Anders würden wir es nur behandeln, wenn von Anfang an vereinbart und finanziert ist, dass aus der Studie ein Produkt werden soll — dann sind es zwei bewusste Schritte, nicht ein unbemerktes Abrutschen.

Was wir gelernt haben

Machbarkeit zu beweisen und ein Produkt zu bauen sind zwei verschiedene Aufträge, und sie haben verschiedene Definitionen von Erfolg. Eine Studie, die mit „geht, machen wir aber nicht" endet, ist geglückt, nicht gescheitert — vorausgesetzt, alle wussten von Anfang an, dass es eine Studie war. Der Fehler ist nicht, eine Studie zu bauen, die im Nichts endet; der Fehler ist, nicht zu sagen, dass es eine Studie war. Eine benutzbare Oberfläche macht aus einer Frage noch kein Produkt.

Wie das Batunet verändert hat

Seither klären wir vor dem ersten Schritt, welche Art von Arbeit ansteht — Frage beantworten oder Bestand schaffen — und was in beiden Fällen ein gutes Ende wäre. Das schützt beide Seiten vor der falschen Erwartung, dass jede Studie in ein Produkt mündet. Wir behandeln das Ende einer Studie nicht als Abbruch, sondern als das, was es ist: eine beantwortete Frage.

Weiterführend

• Guide: Warum Softwareprojekte wirklich scheitern — warum unklare Ziele früh zu falschen Erwartungen führen.
• Glossar: Cone of Uncertainty — warum am Anfang das Verständnis am geringsten ist.
• Story: „Das ist doch schnell gemacht." — was passiert, wenn man den Charakter eines Vorhabens nicht ernst nimmt.
• Leistung: MVP-Entwicklung — wie man von einer Idee zu einem validierten Produkt kommt, bewusst und in Schritten.

Grundlage ist die Batunet Engineering Method: das Vorhaben benennen, bevor man baut — und wissen, was Erfolg bedeutet.

Eine Studie fragt, ob etwas geht. Ein Produkt sorgt dafür, dass es bleibt. Wer beides verwechselt, hält eine beantwortete Frage für ein gescheitertes Produkt.