Wenn ich heute mit Vibe Coding experimentiere, denke ich oft an meine Startup-Zeit als Gründer und VP Product zurück. Damals war alles so aufwendig, was heute so einfach, schnell und günstig ist.
„Es geht darum, dass ich meine Ideen selbst ausprobieren kann, ohne dafür zuerst ein ganzes Team in Bewegung setzen zu müssen.“
Build – Measure – Learn
Wir haben unzählige User-Tests durchgeführt, Hypothesen aufgestellt und unser Produkt immer wieder angepasst. Genau darum geht es im Lean-Startup-Ansatz von Eric Ries: Build–Measure–Learn. Eine Idee umsetzen, die Reaktion der Nutzer messen und aus den Ergebnissen lernen. Dann beginnt der nächste Durchlauf. Das klingt einfach und ist im Grunde auch logisch. Aber in der Praxis lag das größte Problem häufig schon im ersten Schritt: Build.
Denn bevor wir überhaupt testen konnten, musste jemand unsere Idee in Software übersetzen. Wir diskutierten Anforderungen, technische Machbarkeit und Design. Es folgten Sprint Planning, Entwicklung, Qualitätssicherung und die nächste Runde von Anpassungen. Dann konnten wir endlich testen – und stellten fest, dass unsere Hypothese falsch war, ein Ablauf nicht funktionierte oder die Nutzer etwas ganz anderes verstanden hatten als erwartet. Also zurück zum Anfang.
Das war nicht nur teuer. Es war manchmal schlicht frustrierend. Kleine Fehler im Code konnten Tage dauern, bis sie gefunden waren. Besonders die berüchtigten Corner Cases, also Sonderfälle, die im normalen Ablauf zunächst niemand bedacht hatte, brachten mich und das Team regelmäßig zur Weißglut. Es wurde diskutiert, analysiert, nachgebessert und erneut getestet. Natürlich hatte das alles seinen Grund. Software muss funktionieren. Aber als Product Manager wollte ich in der frühen Phase vor allem möglichst schnell lernen. Was nützt mir das perfekte Feature, wenn es am Ende niemand nutzt?
Denken und Machen – ohne Umweg
Heute kann ich eine Idee innerhalb kurzer Zeit selbst in einen funktionierenden Prototyp übersetzen. Ich kann etwas ausprobieren, auf meinem Telefon testen und direkt verändern. Wenn mir ein Button nicht gefällt, ändere ich ihn. Wenn ein Ablauf nicht funktioniert, passe ich ihn an. Ich muss nicht erst ein Ticket schreiben, auf einen Entwickler warten und die Änderung durch einen weiteren Sprint bringen, bevor ich herausfinde, ob meine Idee überhaupt sinnvoll ist.
-
Build
Wochen→ StundenDie Idee in eigenen Worten beschreiben, mit Vibe Coding zum funktionierenden Prototyp machen und direkt auf dem Telefon ausprobieren. Ohne Ticket, ohne Sprint.
-
MeasureTage · wie vorher
Echte Nutzer testen lassen: Wo stocken sie, was verstehen sie anders, was nutzen sie wirklich? Das bleibt der Schritt, der die meiste Zeit braucht.
-
LearnStunden · wie vorher
Hypothese bestätigt oder verworfen? Button ändern, Ablauf anpassen – und sofort in die nächste Runde.
Zeit pro Durchlauf
Idee validiert? Dann übernimmt die Entwicklung: Architektur, Sicherheit, Qualitätssicherung und Skalierung machen aus dem Prototyp ein Produkt.
Ich kann denken und machen, ohne dass zwischen beidem erst ein ganzer Entwicklungsprozess liegen muss. Für mich ist das ein unglaublich starkes Gefühl. Ich fühle mich heute als Product Guy unabhängiger und handlungsfähiger als je zuvor. Und ich wünschte wirklich, ich hätte diese Möglichkeiten schon während meiner Startup-Zeit gehabt.
Dabei geht es nicht darum, dass ich heute plötzlich programmieren kann. Es geht darum, dass ich meine Ideen selbst ausprobieren kann, ohne dafür zuerst ein ganzes Team in Bewegung setzen zu müssen. Und ich bin längst nicht der Einzige, der diese Erfahrung macht.
Menschen mit Ideen werden zu Machern
Ein Freund von mir arbeitet als Disponent. Er hat seinen eigenen Arbeitsablauf analysiert und mit Vibe Coding digitalisiert. Für bestimmte monotone Aufgaben benötigt er heute statt drei Stunden nur noch rund zwanzig Minuten. Er ist kein Softwareentwickler. Er kennt seinen Arbeitsalltag und weiß genau, wo Zeit verloren geht. Jetzt kann er dieses Wissen direkt in eine Lösung übersetzen.
Ein anderer Freund vermisste ein Spiel aus seiner Vergangenheit, das er im App Store nicht mehr finden konnte. Also hat er es sich kurzerhand selbst gebaut. Auch er ist kein Programmierer. Er hatte eine Idee und wollte sie umsetzen. Heute kann er das tatsächlich tun.
Ich finde diese Geschichten faszinierend, weil sie zeigen, worum es bei Vibe Coding eigentlich geht. Es geht nicht nur darum, dass Software schneller entwickelt werden kann. Es geht darum, dass Menschen, die bisher von Entwicklern abhängig waren, plötzlich selbst ins Machen kommen. Menschen, die ihre Kunden, ihre Prozesse oder ein bestimmtes Problem verstehen, können ihre Ideen sichtbar und erlebbar machen. Sie müssen nicht mehr nur erklären, was sie sich vorstellen. Sie können etwas bauen, das andere ausprobieren können.
Ein Prototyp ist noch kein Produkt
Natürlich ist ein Prototyp noch kein fertiges Produkt. Wenn eine Anwendung sicher, zuverlässig und skalierbar funktionieren soll, braucht es weiterhin erfahrene Entwickler, eine gute Architektur, Qualitätssicherung und professionelle IT. Vibe Coding ersetzt diese Arbeit nicht. Aber es verändert den Weg dorthin. In der frühen Phase können wir schneller testen, welche Ideen überhaupt funktionieren und welche es wert sind, professionell weiterentwickelt zu werden. Wir können früher lernen und müssen weniger Zeit und Geld in Annahmen investieren, die sich später als falsch herausstellen.
Genau hier sehe ich auch die Verbindung zu meinen Digital Explorern. Das sind Menschen, die neue Technologien aus eigenem Antrieb ausprobieren, Probleme hinterfragen und ihre Arbeitswelt verbessern wollen. Vibe Coding gibt ihnen ein neues Werkzeug. Aus einem Verbesserungsvorschlag kann ein Prototyp werden. Aus einer Idee eine Anwendung. Und aus einem einzelnen Experiment vielleicht eine Lösung, die auch anderen im Unternehmen hilft.
Eine neue Generation von Product Guys
Vielleicht erleben wir gerade den Beginn einer neuen Generation von Product Guys. Damit meine ich ausdrücklich nicht nur Männer und auch nicht nur Menschen mit dem offiziellen Titel Product Manager. Ich meine alle, die ein Problem erkennen, eine Idee entwickeln und sie selbst in die Realität umsetzen können. Menschen, die nicht mehr darauf warten müssen, dass jemand anderes ihre Vorstellung baut.
Now is the time of the product guys. Nicht, weil Entwickler überflüssig werden. Sondern weil viel mehr Menschen die Möglichkeit bekommen, wie Product Manager zu denken und wie Builder zu handeln.
Mich würde deshalb interessieren: Seid ihr selbst schon zu Product Managern geworden? Kennt ihr Freunde, Bekannte oder Kollegen, die plötzlich eigene Produkte bauen, obwohl sie vorher nie programmieren konnten? Ich bin gespannt, welche Geschichten ihr erlebt.
Wie sich das im Team anfühlt, zeige ich im KI Bootcamp: Keynote, Live Vibe Coding und Hands-on – am Ende stehen echte Prototypen, ohne eine Zeile Code.
Wenn du in deinem Unternehmen mehr Product Guys willst – lass uns sprechen.