Design Doing: Eine erste Version eines AI-beschleunigten Innovations-Frameworks

Warum AI das Testen von Nutzerverhalten günstiger macht, als Meinungen einzusammeln.

TL;DR: Die Kosten für einen testbaren Prototyp sind dank AI um ~90% gefallen. Es ist heute günstiger, zu bauen und zu testen, als vorab umfassend zu forschen. Design Doing ist ein Workflow, in dem der Prototyp selbst zum Experiment wird: funktionale Software, ausgerollt zu echten Nutzern, um tatsächliches Verhalten zu beobachten, nicht Meinungen. Discovery und Empathie zählen weiter, aber die Confidence-Schwelle, um mit dem Bauen zu starten, liegt niedriger (30–40%). Der neue Engpass sind nicht Ideen oder Engineering. Es ist Nutzer-Aufmerksamkeit.

---

Ich habe in deutschen Konzernen genug Design-Thinking-Workshops mitgemacht, um das Muster wiederzuerkennen.

• Tag 1: 8 Leute in einem Raum. Sticky Notes. Sharpies. Eine Moderatorin führt durch „Empathize, Define, Ideate”. Alle gehen energiegeladen raus. „Wir verstehen unsere Nutzer jetzt wirklich!”
• Tag 10: Ein Prototyp wird gebaut. Schön gestaltet. Intern validiert. Nutzer lieben ihn.
• Tag 50: MVP-Entwicklung startet. Und verzögert sich.
• Tag 310: Launch-Tag.
• Die Woche danach: 12 Sign-ups. 0 wiederkehrende Nutzer.

Wir workshoppen. Wir prototypen. Wir validieren. Wir shippen. Wir scheitern.

Aber was sich in den letzten Monaten verändert hat, glaube ich, ist Folgendes: Die gesamte ökonomische Gleichung digitaler Produkt-Innovation kippt.

Die traditionelle Ökonomie von Innovation

Jahrelang war die Rechnung simpel:

• User-Research (Recruiting, Interviews, Synthese): 10.000 – 20.000 € + 3–4 Wochen
• Bau eines funktionalen MVPs: 40.000 – 100.000 € + 2–12 Monate Developer-Zeit (je nach Komplexität)
• Voll geladen: ~50.000 – 120.000 €

Du brauchtest mindestens 60% Confidence, bevor du gebaut hast, weil Falschliegen teuer war. Also haben wir aufwändige Research-Prozesse gebaut. Nutzer rekrutieren, Personas und Empathy-Maps erstellen, Findings in Reports synthetisieren, mit Stakeholdern validieren, Freigabe holen, dann vielleicht mit dem Bauen anfangen.

Das ergab Sinn, solange Engineering der Engpass war.

Das Problem? Sicherheit erreichst du nie, bevor du das Produkt launchst. Es gibt schlicht zu viele Variablen, die kein Workshop und kein klickbarer Prototyp adressieren kann. Wie fühlt sich das Produkt an, wenn es echt ist? Vermittelt die Marke das richtige Signal? Fühlt sich die Interaktion premium oder billig an? Erzeugt das Onboarding Vertrauen oder Friction? Desirability ist nicht nur die Frage, ob du das richtige Problem löst. Es geht um Tonalität, Textur, Timing und hundert Mikro-Entscheidungen, die erst auftauchen, wenn jemand etwas Echtes in einem echten Moment nutzt. Ein Figma-Mockup kann keine Brand-Energie tragen. Ein Sticky-Note-Prototyp kann kein Vertrauen simulieren.

Und ganz nebenbei: Bis du diese teuren Insights hast, hat sich der Markt weitergedreht. Dein Wettbewerber hat drei Hypothesen getestet, während du noch Interview-Themen synthetisiert hast.

Die neue ökonomische Realität

So sieht es heute aus, einen testbaren Prototyp zu bauen — und es wird noch verrückter werden:

• AI-generierter Behavioral Prototype: 400 € (API-Kosten + Tool-Subscriptions) + deine Zeit: 5 Tage (~2.000 – 3.000 € zu üblichen Innovations-Manager-Raten). Komplexe Prototypen können länger dauern, einfachere Konzepte sind in einem Wochenende testbar.
• Deployment zu 100 echten Nutzern: 500 – 1.000 € Ad-Spend pro Woche (über ~4–6 Wochen)
• Voll geladen (inkl. Zeit): ~4.400 – 7.400 €

Die Kosten, eine Hypothese zu testen, sind um rund 90% gefallen. Time-to-Learning: Wochen statt Monate.

Aber die meisten Innovations-Teams nutzen immer noch das Entscheidungs-Framework aus der Zeit, als Testen teuer war.

Die Inversion: Es wird günstiger, zu bauen und zu testen, als vorab umfassend zu forschen.

Denk drüber nach. Eine Focus Group kostet 10.000 € und sagt dir, was Leute sagen, dass sie tun würden. Für ein ähnliches Budget zeigt dir ein Behavioral Prototype, was Leute tatsächlich tun. Welchen Daten würdest du trauen?

Warum die Ökonomie gekippt ist

Die Kosten-Inversion ist nicht aus Versehen passiert. Sie ist passiert, weil sich das Bauen von Software fundamental verändert. Und die Trends sind klar. Hab kurz Geduld, gleich kommt der AI-Teil ;)

Developer, die Tools wie Cursor, GitHub Copilot oder Claude nutzen, berichten konsistent von 30–50% Produktivitätssteigerung. Was früher zwei Wochen brauchte, dauert eine. Boilerplate wird in Sekunden generiert. Context Switching sinkt. Lernkurven komprimieren. Das alleine verschiebt die Bauen-vs-Forschen-Rechnung.

Aber das, was für Innovation noch mehr zählt: Leute, die früher nicht coden konnten, können heute funktionale Prototypen bauen. Andrej Karpathy, früher Director of AI bei Tesla, hat es „Vibe Coding” genannt. Beschreiben, was du willst, in normaler Sprache — und funktionierende Software zurückbekommen. Tools wie Replit Agent, Lovable und Claude Artifacts machen das real. Keine Mockups. Keine Wireframes. Funktionierende Software, mit der Nutzer interagieren können.

Eine Marketing-Managerin mit einer Hypothese zu einem neuen Customer-Portal muss kein Requirement-Dokument mehr schreiben, kein Budget genehmigen lassen und keine sechs Monate auf die IT warten, bis ein MVP fertig ist. Sie kann den Prototyp selbst an einem Wochenende bauen und ihn am Montag vor echte Nutzer bringen.

Für Produktivsysteme reicht das nicht. Du würdest keine Bank auf vibe-gecodeter Software betreiben. Aber für die Frage „wird das überhaupt jemand benutzen?” ändert es das Spiel komplett.

Die Kosten, eine Hypothese zu testen, sind kollabiert. Egal ob du als Developer schneller wirst oder als nicht-technische Person deinen ersten Prototyp baust — die alte Logik „erst extensiv forschen, dann bauen” trägt nicht mehr.

Der Code ist disposable. Die Behavioral Data, die er erzeugt, nicht.

Ich nenne das Behavioral Prototypes: funktionale Software, gebaut nicht für die Produktion, sondern um zu beobachten, was echte Nutzer in echten Kontexten tatsächlich tun. Kein Mockup. Keine Demo. Ein funktionierendes Tool, ausgerollt zu echten Menschen, gezielt darauf ausgelegt, Behavioral Data zu erzeugen statt Meinungen.

Damit das klar ist: Das ist kein MVP. Der Begriff trug schon immer zwei konkurrierende Definitionen. Frank Robinson, der ihn 2001 geprägt hat, meinte ein echtes Produkt: „das richtig dimensionierte Produkt für dein Unternehmen und deine Kunden, groß genug, um Adoption, Zufriedenheit und Verkäufe auszulösen”. Eric Ries hat ihn 2011 neu definiert als Lerninstrument: „der schnellste Weg durch den Build-Measure-Learn-Loop mit minimalem Aufwand”. Konzerne sind mehrheitlich bei Robinsons Version gelandet, ob sie es wussten oder nicht. Ein Behavioral Prototype baut auf Ries’ Version auf, geht aber weiter: Er ist nicht einmal dazu gedacht, das Produkt zu werden. Er soll eine Frage beantworten und dann sterben. Beides zu verwechseln, ist der Grund, warum Teams Code optimieren, der hätte weggeworfen werden sollen. Oder Produkte wegwerfen, die hätten verfeinert werden sollen.

Design Doing: Ein weiterentwickelter Workflow

Ich wollte nichts neu erfinden. Ich habe nur gemerkt, dass sich die Tools verändert haben, also habe ich meinen Workflow verändert. Über das letzte Jahr hat sich das zu dem entwickelt, was ich Design Doing nenne. Ich weiß noch nicht genau, wohin das führt. Aber die Richtung fühlt sich klar genug an, um sie zu teilen.

Der Begriff ist nicht neu. Der Shift von „Design Thinking” zu „Design Doing” wird seit Jahren diskutiert, etwas, das wir auch mit Kollegen bei Dark Horse erkundet haben. Ich mag ihn, weil er genau einfängt, was sich verändert hat: Das „Doing” selbst ist zur Research-Methode geworden. Aber meine Nutzung geht über „weniger theoretisieren, mehr machen” hinaus. Es beschreibt einen Prozess, in dem Bauen Testen ist und der Behavioral Prototype das Experiment.

Der Name geht nicht um Geschwindigkeit, auch wenn Geschwindigkeit ein Nebenprodukt ist. Er geht um einen fundamentalen Shift, was als Evidenz zählt.

Wenn du Design Thinking ernsthaft praktiziert hast, wirst du widersprechen: „DT war immer darum, echtes Verhalten zu beobachten. Empathize heißt kontextuelle Beobachtung, keine Focus Group.” In der Theorie hättest du recht. Aber denk darüber nach, was tatsächlich in der Konzernpraxis passiert ist. Wenn Bauen 100.000+ € kostete, konnten sich Teams nicht leisten, echte Produkte als Research-Tools zu nutzen. Interview-basierte Empathie war keine methodische Entscheidung. Es war ein ökonomisches Constraint. Die Lücke zwischen DT-Versprechen („beobachte echtes Verhalten”) und DT-Praxis („frag Leute in Workshops”) wurde nicht von schlechten Facilitators verursacht. Sie wurde von Budget-Realität verursacht.

• Design Thinking validiert mit: Prototypen, die simulieren. Reaktionen in kontrollierten Settings.
• Design Doing validiert mit: Prototypen, die funktionieren. Verhalten in echten Kontexten.

Das ist keine subtile Unterscheidung. Es ist der Unterschied zwischen Meinungen einsammeln und Verhalten beobachten. Zwischen hypothetischer Präferenz und revealed Preference. Zwischen „das würde ich definitiv nutzen” im Interview und Stille nach dem Launch.

Die Philosophie bleibt human-centered. Der Fokus bleibt auf echten Bedürfnissen. Aber die Validierungsmethode ändert sich komplett. Vom Fragen zum Beobachten, vom Forschen zum Testen, vom Confidence-Aufbauen zur schnellen Falsifikation.

Dieses Framework ist ein erster Entwurf, kein fertiges Modell. Ich arbeite jetzt seit etwa einem Jahr so und passe den Prozess mit jedem Projekt an. Aber was ich mit wachsender Sicherheit sagen kann: Dieser Workflow war signifikant effizienter und effektiver als das, was ich vorher gemacht habe. Nicht weil er Schritte überspringt, sondern weil er den teuersten Schritt — Bauen — zum Research-Instrument macht. Statt Monate Confidence aufzubauen, bevor irgendetwas entsteht, machst du etwas, das Confidence liefert. Die Reihenfolge kippt. Und damit kippt auch, wie Teams lernen, entscheiden und iterieren. Versteh das als Einladung zum Experimentieren, kein Rezept zum Befolgen.

Discovery: Die Nutzer verstehen

Der erste Schritt hat sich nicht verändert: Du musst die Menschen verstehen, für die du baust. Ihre Bedürfnisse, ihre Frustrationen, die Probleme, die sie nicht mehr bemerken, weil sie so lange damit leben. Dieser Teil ist nicht verhandelbar.

Was sich verändert hat, ist das Toolkit. Im Framework ist das die Discovery-Phase: AI Research und Human Depth arbeiten iterativ, nicht sequentiell.

Klassisch hieß Discovery Interviews, Field Visits, vielleicht eine Umfrage. Kleine Samples. Du sprichst mit 10–15 Leuten, synthetisierst die Findings und hoffst, dass sie repräsentativ waren. Es war das Beste, was wir mit Zeit und Budget machen konnten.

AI Research öffnet hier neue Dimensionen. Du kannst Reddit-Threads, Forendiskussionen, App-Store-Reviews, Support-Tickets und Social-Media-Conversations crawlen. Tausende echte, ungefilterte Stimmen, die über ihre Probleme in ihren eigenen Worten reden, ungefragt. Du fängst an, Friction-Patterns in existierenden Produkten zu erkennen, die Nutzer im Interview nie erwähnen würden, weil sie sie bewusst nicht wahrnehmen. Es ist noch früh, und es ist nicht perfekt. Aber die Richtung ist klar.

Was ich gemerkt habe: AI Research ersetzt Interviews nicht — es reframet sie. Hier kommt Human Depth ins Spiel. Statt reinzugehen und zu hoffen, die Probleme zu entdecken, gehst du mit einem besseren Gefühl für die Landschaft rein und nutzt das Gespräch, um das Warum hinter den Mustern zu verstehen. Den emotionalen Kontext. Die gelebte Erfahrung. Die Dinge, die Daten an die Oberfläche bringen können, aber nie erklären.

Im besten Fall funktioniert die Kombination so: AI Research gibt dir Breite. Viele Datenpunkte über Foren, Reviews und Nutzungsmuster. Human Depth gibt dir genau das. Tiefe. Vertrauen, Nuance, die Momente, in denen jemand zeigt, was er tatsächlich braucht, statt was er denkt, dass du hören willst.

In einem kürzlichen Projekt im Sportbereich lief das genau so. Vor dem ersten Interview haben wir mit AI Foren, App-Reviews und Wettbewerbslandschaften gescannt. Das hat uns über 20 Hypothesen für Gespräche geliefert. Keine Vermutungen. Informierte Startpunkte. Fünf Interviews später hatten wir fast hundert validierte Datenpunkte. Aber der Moment, der das ganze Projekt reframet hat, war in keinem Datensatz. Es war eine Nutzerin, die auf ihr Ergebnis schaute und sagte „Okay, aber was mache ich jetzt damit?” Diese Pause, diese Frustration. Das ist die Tiefe, die kein Modell aus einem Transcript extrahieren kann.

Unter der alten Ökonomie brauchtest du hohe Confidence vor dem Bauen, weil Falschliegen 100.000+ € und Monate Engineering-Zeit kostete. 60% Confidence anzustreben, bevor du Ressourcen committest, war rationales Risikomanagement.

Unter der neuen Ökonomie kostet Falschliegen 4.000–7.000 € und ein paar Wochen Arbeit. Das Kalkül kippt.

Und das ändert die Explorationsphase selbst. Du musst nicht mehr forschen, bis du sicher bist. Du musst forschen, bis du eine Richtung hast. Ein informiertes Bauchgefühl, eine starke Hypothese basierend auf echten Signalen — kein erschöpfender Beweis — reicht, um mit dem Bauen zu starten. Denn der Prototyp ist nicht das Commitment. Er ist die nächste Runde Research. Der schwere Upfront-Discovery-Prozess ergab Sinn, als er deine letzte Chance war, vor einer sechsstelligen Wette gegenzusteuern. Wenn die Wette ein paar tausend Euro und ein paar Wochen kostet, lehrt dich dein Bauchgefühl plus ein funktionierender Prototyp mehr als ein weiterer Monat Interviews.

Bei der Confidence-Schwelle, 30–40%, weißt du genug, um etwas Testbares zu bauen, hast aber noch nicht die Wochen Research investiert, die emotionale Bindung an deine Hypothese erzeugen. Du bist informiert, aber nicht committed. Neugierig, aber nicht überzeugt.

Unter 30% rätst du zufällig. Es gibt nicht genug Signal, um auch nur zu wissen, was zu prototypen ist.

Über 50% überforscht du wahrscheinlich. Du verbrennst Zeit, um Sicherheit zu erreichen, die ohnehin nur echtes Verhalten liefern kann.

Das Ziel ist nicht, leichtfertig zu sein. Es ist, zu erkennen, dass zusätzliche Research abnehmenden Grenznutzen hat, sobald du die Confidence-Schwelle überschritten hast: den Punkt, an dem ein Behavioral Prototype günstiger wird als noch eine Runde Interviews.

Klar: Das heißt nicht, Research zu überspringen. Unter 30% baust du blind. Kein Maß an günstigem Prototyping ersetzt komplettes Nicht-Verstehen. Discovery zählt weiter. Du musst weiter mit Menschen reden, die Landschaft mappen, testenswerte Hypothesen aufbauen. Der Unterschied ist, was passiert, sobald du die Schwelle überschritten hast. Das ist der Problem-Reframing-Loop im Framework. Discovery endet nicht, wenn Bauen anfängt. Es läuft durch das Bauen weiter. Menschen tun sich schwer, Probleme im Abstrakten zu artikulieren. Aber gib ihnen etwas Konkretes, und sie zeigen dir, wo du falsch lagst. Bei 30–40% committest du dich nicht auf eine Lösung. Du schaffst die Bedingungen für tiefere Discovery.

Aber eines bleibt unersetzbar.

Empathie kannst du nicht automatisieren.

Du musst weiterhin im Raum sein. Du musst die Mikro-Mimik sehen, die Pause vor der Antwort, die Art, wie sich jemand zurücklehnt, während er „ja, funktioniert ganz gut” sagt, aber sein Körper etwas anderes sagt. Du musst die Energieverschiebung spüren, wenn du etwas berührst, das wirklich zählt. Du musst merken, wenn dir jemand die polierte Antwort statt der echten gibt. Und wissen, wie man sanft über sie hinausschiebt.

AI kann transkribieren. AI kann Themes clustern. AI kann zusammenfassen. Aber AI kann sich nicht einer frustrierten Pflegerin am Ende einer 12-Stunden-Schicht gegenübersetzen und verstehen, was sie tatsächlich braucht, indem sie beobachtet, wie sie ihren Workaround navigiert. Sie kann nicht erkennen, dass das echte Problem nicht das ist, das sie beschreibt — es ist das, was sie als normal akzeptiert hat.

Der menschliche Skill in Discovery ist nicht, Informationen einzusammeln. Es ist, Bedingungen zu schaffen, in denen jemand dir genug vertraut, um dir die Wahrheit zu zeigen. Das ist eine Beziehung, kein Datenpunkt.

Build, Deploy, Watch: Solution Testing

Hier wird es wirklich anders. Und ehrlich, hier musste ich am meisten umlernen.

Klar, wir haben Prototypen gebaut. Diese „Lern”-Prototypen haben uns etwas gegeben. Wir konnten sie Nutzern zeigen. Wir konnten beobachten, wo sie zögerten, wo sie sagten: „Oh, das hatte ich nicht erwartet.” Wir haben Insights gesammelt. Wir haben Confidence aufgebaut.

Aber was diese Prototypen uns nicht sagen konnten: Würde das überhaupt jemand in seinem echten Leben benutzen?

Ein Figma-Prototyp beantwortet nicht, ob jemand die App an einem Dienstagmorgen öffnet, wenn er gestresst und beschäftigt ist. Ein klickbares Mockup zeigt dir nicht, ob er morgen wiederkommt. Eine Demo zeigt dir nicht, ob er einem Kollegen davon erzählt oder es leise vergisst.

Wir hatten immer Fragezeichen offen. Große. Die Art, die nur echte Nutzung in echten Kontexten beantworten kann. Aber echte Nutzung verlangte echte Software, und echte Software verlangte echtes Investment. Also haben wir Entscheidungen auf Basis unvollständiger Daten getroffen und das Beste gehofft.

Ich habe das direkt im Sportbereich erlebt. Ein Team hatte ein technisch solides Produkt gebaut — voller Prozess, Research, Prototyping, interne Validierung. Alle waren sich einig, dass es ein echtes Problem löst. Sie haben gelauncht. Der CEO hat mir später gesagt: „Wir haben ein Tool platziert, wo eine Lösung gebraucht wurde.” Nutzer bekamen Ergebnisse, aber niemand zeigte ihnen, was sie damit machen sollten. Das Produkt ist leise verschwunden. Nicht weil die Technologie falsch war. Weil der echte Bedarf nie mit einem echten Produkt in einem echten Kontext getestet wurde.

Diese Lücke — zwischen „den Nutzern gefällt der Prototyp” und „die Nutzer benutzen das Produkt tatsächlich” — ist, wo die meisten Innovationsprojekte sterben.

Diese Lücke ist jetzt kollabiert.

Wo der zweite Diamond früher Mockups in 5–10 Tagen produziert hat, kannst du heute funktionale Software im selben Zeitraum bauen. Nicht weil wir Ecken abschneiden. Nicht weil wir leichtsinnig werden. Sondern weil die Tools sich so fundamental verändert haben, dass wir jetzt Behavioral Prototypes bauen können, funktionale Software statt Mockups, und sie zu Nutzern deployen können — in echten Kontexten. In der Zeit, die früher für die Buchung einer User-Testing-Session draufging.

Und Folgendes ist in diesem Shift leise verschwunden: Ideation als separate Phase. Es gibt keinen Whiteboard-Moment mehr, in dem du Konzepte brainstormst und sie dann jemandem zum Bauen übergibst. Du hast eine Idee, du fängst an zu bauen, du spürst, dass es falsch ist, während du baust, du löschst es, du baust neu. Das Gespräch mit dem Tool ist die Ideation. Du denkst, indem du machst. Drei Ideen, die früher Sticky Notes an einer Wand gewesen wären, sind jetzt drei Prototypen, die du vor Leute bringen kannst. Das Denken ist nicht weg. Es ist mit dem Machen verschmolzen.

Dasselbe Sportprojekt? Wir sind von der Insight-Synthese zu 15 Behavioral Prototypes in unter drei Wochen gekommen. Keine Mockups. Formate, mit denen Nutzer wirklich interagieren konnten. Eine Card mit drei persönlichen Action Zones. Eine 60-Sekunden-Voice-Message mit einer konkreten Empfehlung. Ein System, das den wichtigsten Hebel hervorhebt und alles andere zurücktreten lässt. Jeder Prototyp hat eine andere Hypothese darüber getestet, was „nützlich” tatsächlich heißt. Und das waren keine Demos, durch die wir Leute geführt haben. Sie haben echte, persönliche Ergebnisse geliefert, die Nutzer teilen, speichern oder ignorieren konnten. Derselbe Prototyp, zwei völlig unterschiedliche Settings. Wir haben nicht gefragt „gefällt dir das?”. Wir haben Verhalten beobachtet. Wir haben beobachtet, ob es den Moment des Verstehens auslöst.

Der eigentliche Shift

Die Empathie-Phase sollte nie eine Workshop-Übung sein. Sie sollte tief, kontextuell, behavioral sein. Gute DT-Praktiker haben das auch so gemacht: Shadowing, Contextual Inquiry, ethnografische Beobachtung. Aber selbst die beste Empathie-Research konnte nicht beantworten, ob Menschen eine Lösung in ihrem echten Leben tatsächlich nutzen würden. Das brauchte ein echtes Produkt, und echte Produkte brauchten echtes Investment. Also gab es immer einen Vertrauenssprung zwischen „wir verstehen das Problem tief” und „diese Lösung funktioniert in der Praxis”.

Genau diese Lücke kollabiert AI. Nicht die Empathie. Das Testen.

Workshops und Sticky Notes waren nie der Punkt. Sie waren das Constraint. Jetzt, da Bauen günstig genug ist, um es als Research-Methode zu nutzen, kann die Erkundung menschlicher Bedürfnisse dort stattfinden, wo sie immer stattfinden sollte: in der gelebten Realität der Nutzung, nicht in der Abstraktion einer Post-it-Wand.

Lean Startup war zuerst da

Und ja — Lean Startup war zuerst da. Nicht nur philosophisch, sondern methodisch.

Build-Measure-Learn. Validated Learning. Das MVP. Eric Ries hat explizit für günstige Validation plädiert: Landing-Page-Tests, Explainer-Videos, manuelle Concierge-Services. Dropbox hat sein gesamtes Konzept mit einem Drei-Minuten-Video validiert. Zappos hat getestet, ob Leute Schuhe online kaufen würden, indem es das Inventar lokaler Läden fotografiert und Bestellungen per Hand erfüllt hat. Ries hat 2009 geschrieben, dass selbst ein zweiwöchiger Build „viel zu lang” sei, wenn ein einfacher AdWords-Smoketest zeigen würde, ob es überhaupt jemanden interessiert.

Die Theorie war solide. Das Problem war Adoption.

In den meisten Konzernkontexten ist „MVP” zurück in Robinsons Ursprungsbedeutung gedriftet: erste Version des Produkts, gedacht zum Verkauf. Was Ries als günstiges Experiment gemeint hat, wurde zu einer umetikettierten Entwicklungsphase, die routinemäßig 50.000+ € und Monate Engineering kostet. Steve Blank, Ries’ Mentor, hat das „Innovation Theater” genannt: tolle Pressemitteilungen darüber, wie innovativ das Unternehmen ist, keine echte Veränderung daran, wie Produkte gebaut werden.

Die Organisationen haben die Methodik nicht korrumpiert. Sie haben die Definition gewählt, die sich sicherer anfühlte.

AI verbessert nicht die Philosophie von Lean Startup. Sie entfernt die organisatorische Barriere, die sie theoretisch gehalten hat. Was AI ändert, ist nicht das MVP selbst — es ist, was davor kommt: die Fähigkeit, Behavioral Experiments in Produktform zu fahren, ohne sich auf ein Produkt zu committen.

Lean Startup hat Organisationen gesagt, weniger zu bauen. Design Doing sagt: Bau Throwaway-Prototypen, um zu lernen, und entscheide dann, was sich lohnt, wirklich zu bauen. Wenn eine nicht-technische Person in Tagen einen Behavioral Prototype bauen kann, kann der Validation-Loop endlich das sein, was Ries immer gemeint hat.

Der Engpass ändert seine Form

Wenn Testen sofort und günstig ist, was wird zum Constraint?

Es sind nicht Ideen. Jeder hat Ideen. Es ist nicht das Bauen. AI handhabt das. Es ist nicht mal Geld. Prototypen kosten fast nichts.

Der neue und alte Engpass ist Aufmerksamkeit.

Denk drüber nach. Wenn jedes Innovations-Team, jedes Startup, jedes Corporate Lab in Tagen testbare Prototypen aufsetzen kann — was passiert mit den Menschen, die sie erreichen wollen?

Sie ertrinken in Anfragen. Noch eine Umfrage. Noch ein Beta-Test. Noch ein „wir würden uns über dein Feedback freuen”. Noch eine App, die 10 Minuten ihrer Zeit will.

Nutzer-Aufmerksamkeit wird die knappste Ressource in Innovation.

Das hat reale Implikationen:

Ad-Spend skaliert nicht mehr linear. Heute bringen dich 500–1.000 € pro Woche vor 100 echte Nutzer. Aber was passiert, wenn alle Prototyp-Tests fahren? Dieselben Augen werden teurer. Dieselben Zielgruppen werden müde. Dieselben Kanäle werden gesättigt.

Zugang zu Nutzern wird Wettbewerbsvorteil. Unternehmen mit existierenden Kundenbeziehungen, Communities oder Distributionskanälen können schneller und günstiger zu Nutzern deployen als solche, die bei null starten. Eine Audience zu haben, ist nicht mehr nur ein Marketing-Asset. Es ist Innovations-Infrastruktur.

Die Ironie ist klar. Je mehr AI das Bauen beschleunigt, desto mehr zählen menschliche Beziehungen. Strategische Empathie. Community. Vertrauen. Die Fähigkeit, Aufmerksamkeit zu verdienen, statt sie zu kaufen.

Ich glaube, wir gehen in eine Welt, in der jeder alles bauen kann. Wenn das stimmt, werden die Gewinner nicht die sein, die am schnellsten bauen. Sie werden die sein, die die Beziehungen aufgebaut haben, die sie am schnellsten lernen lassen.

Ein erster Entwurf, kein fertiges Framework

Ich lerne noch, wo das bricht, wo es hält und wo es sich entwickeln muss. Wenn du mit ähnlichen Ansätzen experimentierst, an Grenzen stößt, die ich nicht bedacht habe, oder denkst, dass ich etwas fundamental falsch verstehe — würde ich es ehrlich gern hören.

Meld dich, fordere das Denken heraus oder teile, was in deinem Kontext funktioniert. Die beste Version davon entsteht nicht durch eine Person, die isoliert schreibt.

---

Eine Notiz dazu, wie das geschrieben wurde: Die Ideen, Meinungen und Erfahrungen in diesem Artikel sind meine. Ich habe Claude als Writing-Partner genutzt, um Denken zu strukturieren, Argumente zu schärfen und von rohen Notizen zu einem fertigen Stück zu kommen. Der Prozess fühlte sich sehr nach dem an, was dieser Artikel beschreibt: AI hat das gemacht, worin sie gut ist, der Mensch hat das eingebracht, was sie nicht kann.