Stell dir vor, du hast 80.000 Euro und sechs Monate Zeit in eine KI-gesteuerte App investiert, die automatisch Termine für Handwerker koordinieren soll. Du hast Entwickler bezahlt, APIs integriert und nächtelang Codezeilen optimiert. Am Tag der Veröffentlichung stellst du fest: Die Nutzer hassen das Interface, und die Logik hinter der Automatisierung versteht kein Mensch. Das Geld ist weg, die Motivation im Keller. Hättest du stattdessen die Methode Wizard Of Oz The Wizard Of Oz genutzt, hättest du dieses Desaster für weniger als 500 Euro innerhalb einer Woche kommen sehen. Ich habe diesen Fehler bei Startups und gestandenen Unternehmen im deutschen Mittelstand so oft gesehen, dass es wehtut. Die Leute bauen Schlösser aus Glas, bevor sie wissen, ob überhaupt jemand darin wohnen will.
Den Algorithmus programmieren bevor man ihn manuell simuliert hat
Der größte Fehler besteht darin, technische Komplexität mit Marktwert zu verwechseln. Viele Gründer denken, sie müssten sofort eine funktionierende Künstliche Intelligenz oder ein komplexes Backend bauen. Das ist Quatsch. In der Praxis bedeutet dieser Prozess, dass ein Mensch im Hintergrund die Aufgaben erledigt, von denen der Nutzer glaubt, sie würden automatisch geschehen. Wenn du eine App baust, die Rechtsverträge analysiert, dann setz im ersten Monat einen Jurastudenten hin, der die PDF-Dateien manuell liest und die Ergebnisse in ein schickes Web-Interface tippt.
Warum? Weil du so lernst, welche Daten der Nutzer wirklich braucht. Ich habe ein Team erlebt, das drei Monate an einem automatischen Kategorisierungssystem für Belege gearbeitet hat. Als sie es endlich fertig hatten, merkten sie, dass die Kunden eigentlich nur die Gesamtsumme und das Datum wissen wollten, nicht die Mehrwertsteueraufschlüsselung nach Warengruppen. Hätten sie das manuell simuliert, hätten sie nach drei Tagen gewusst, dass sie 90 % der Funktionen gar nicht programmieren müssen. Man spart nicht nur Zeit, sondern verhindert, dass man sich in eine technische Sackgasse manövriert, aus der man nur schwer wieder herauskommt.
Wizard Of Oz The Wizard Of Oz als reines Design-Spielzeug missverstehen
Viele Designer nutzen diesen Ansatz nur für Usability-Tests im Labor. Das reicht bei weitem nicht aus. Wenn du die Methode nur nutzt, um zu schauen, ob ein Button an der richtigen Stelle sitzt, verschenkst du das eigentliche Potenzial. Es geht um die Validierung des Wertversprechens unter Realbedingungen.
Die Falle der Laborbedingungen
In einem sterilen Testraum verhalten sich Menschen anders als in ihrem stressigen Arbeitsalltag. Ich rate dazu, den Prozess direkt in die Arbeitsabläufe der Testkunden zu integrieren. Wenn der Nutzer glaubt, das System sei echt, bekommst du ehrliches Feedback. Sobald er weiß, dass im Hintergrund ein Mensch sitzt, wird er gnädig. Aber Gnade bringt dir kein Geld ein. Du brauchst die harte Wahrheit: Ist die Lösung so gut, dass der Kunde dafür bezahlen würde? In Deutschland sind wir oft zu perfektionistisch. Wir wollen, dass alles „ordentlich“ ist, bevor wir es zeigen. Das ist ein teurer Hochmut. Ein manuell betriebenes Backend ist nicht „unordentlich“, es ist eine kluge Investition in Wissen.
Die Skalierungsangst blockiert den Erkenntnisgewinn
Ein häufiges Argument gegen diese Strategie lautet: „Aber das skaliert doch nicht!“ Wer das sagt, hat den Sinn der frühen Phase nicht verstanden. Natürlich kannst du nicht 10.000 Kunden manuell bedienen. Aber du hast momentan keine 10.000 Kunden. Du hast vielleicht fünf. Und diese fünf Kunden manuell zu betreuen, gibt dir tiefe Einblicke in ihre Probleme, die kein Analyse-Tool der Welt liefern kann.
Ich habe ein Projekt begleitet, bei dem es um eine intelligente Routenplanung für Lieferdienste ging. Das Team wollte sofort ein neuronales Netz trainieren. Ich habe sie gezwungen, die ersten 20 Lieferungen per Hand mit Google Maps und Zettel zu planen. Dabei kam heraus, dass die Fahrer gar nicht die kürzeste Route wollten, sondern die mit den wenigsten Linksabbiegern, weil das an Kreuzungen in der Innenstadt zu viel Zeit kostet. Kein Algorithmus hätte das ohne diese manuelle Erfahrung am Anfang berücksichtigt. Wer zu früh skaliert, baut Ineffizienz in Softwareform. Wer manuell startet, baut Expertise, die später in Code gegossen wird.
Wizard Of Oz The Wizard Of Oz falsch kommunizieren und Vertrauen verspielen
Es gibt eine feine Linie zwischen Prototyping und Täuschung. Ein massiver Fehler ist es, den Kunden im Unklaren zu lassen, wenn es um sensible Daten geht. In Deutschland haben wir strenge Datenschutzregeln (DSGVO). Wenn du suggerierst, eine Maschine verarbeite Daten, aber in Wahrheit sitzt ein Mensch in einem Coworking-Space und liest mit, hast du ein rechtliches und ethisches Problem.
Die Lösung ist einfach: Sei transparent bezüglich der Datenverarbeitung, aber vage bezüglich der Automatisierung. Du kannst im Kleingedruckten oder in den Nutzungsbedingungen erwähnen, dass zur Qualitätssicherung und Systemoptimierung eine manuelle Prüfung der Daten erfolgt. Das ist rechtlich sauber und zerstört die Illusion des Produkts für den Endnutzer nicht komplett. Wenn du das vermasselst, ist dein Ruf ruiniert, bevor das erste echte Release ansteht. Vertrauen, das man am Anfang verliert, bekommt man später durch kein Marketing-Budget der Welt zurück.
Den Moment verpassen an dem Code den Menschen ersetzen muss
Ein weiteres Risiko ist das „Hängenbleiben“ im manuellen Modus. Ich kenne Firmen, die seit zwei Jahren so arbeiten und sich wundern, warum sie keine Gewinne machen. Die Kosten für die menschliche Arbeit fressen die Marge auf. Man muss den Punkt finden, an dem die Prozesse so stabil und die Anforderungen so klar sind, dass sich die Programmierung lohnt.
Ein Vorher/Nachher-Vergleich verdeutlicht das Problem: Nehmen wir ein Startup für automatisierte Spesenabrechnungen. Vorher (Falscher Ansatz): Sie programmieren ein Jahr lang an einer OCR-Erkennung, die 99 % Genauigkeit erreichen soll. Nach dem Launch merken sie, dass Nutzer oft zerknitterte oder verblasste Belege fotografieren, die die KI nicht lesen kann. Die Abbruchquote ist riesig, weil das System ständig Fehlermeldungen ausgibt. Nachher (Richtiger Ansatz): In den ersten drei Monaten werden alle hochgeladenen Fotos von Werkstudenten innerhalb von 15 Minuten abgetippt. Das Team lernt, welche Belegtypen am häufigsten Probleme machen. Sie stellen fest, dass die Nutzer gar keine Echtzeit-Erkennung brauchen – 15 Minuten Wartezeit sind völlig okay. Mit diesem Wissen bauen sie eine einfache KI für die Standardbelege und behalten für die schwierigen Fälle einen manuellen Prozess bei. Das Ergebnis ist ein stabiles Produkt mit extrem hoher Kundenzufriedenheit bei deutlich geringeren Entwicklungskosten.
Man sieht hier deutlich: Der manuelle Weg führt nicht nur zu einem besseren Produkt, sondern definiert auch die technischen Anforderungen viel präziser. Du programmierst nur das, was wirklich nötig ist.
Zu viel Fokus auf das Frontend und zu wenig auf die Logik
Ich sehe oft Prototypen, die fantastisch aussehen, aber deren Logik nicht funktioniert. Die Leute verbringen Wochen mit Farben, Schriftarten und Animationen in Figma. Das ist Zeitverschwendung, wenn der Kernprozess nicht validiert ist. Die Methode verlangt, dass die „Backstage“ funktioniert, egal wie sie betrieben wird. Wenn die Antwort, die der Nutzer bekommt, wertlos ist, rettet dich auch das schönste Design nicht.
Einmal arbeitete ich mit einem Team an einem Tool für die automatisierte Erstellung von Social-Media-Posts. Das Frontend war Weltklasse. Man klickte auf einen Button und drei Sekunden später erschien ein Post-Entwurf. Hinter den Kulissen schwitzte ein Texter, um den Entwurf schnell genug zu tippen. Das Problem war nicht die Geschwindigkeit, sondern der Inhalt. Die Nutzer fanden die Entwürfe banal. Das Team hätte diese Erkenntnis auch mit einem hässlichen Textfeld gewinnen können. Sie hatten 20.000 Euro in Design gesteckt, um herauszufinden, dass ihre Grundidee nicht zündet. Das ist der Moment, in dem du merkst, dass du das Prinzip falsch verstanden hast. Es geht um die Validierung des Ergebnisses, nicht um die Ästhetik der Verpackung.
Realitätscheck: Was es wirklich braucht
Machen wir uns nichts vor: Dieser Weg ist anstrengend. Es ist psychologisch belastend, ein System zu betreiben, von dem man weiß, dass es „gepfuscht“ ist. Wir Ingenieure und Produktmanager wollen elegante Lösungen, keinen manuellen Aufwand im Hintergrund. Aber die Wahrheit ist: Wenn du nicht bereit bist, die Drecksarbeit am Anfang selbst zu machen, wirst du ein Produkt bauen, das am Markt vorbeigeht.
Es braucht Disziplin, um nicht zu früh mit dem Programmieren anzufangen. Es braucht Demut, um zu akzeptieren, dass deine erste Idee wahrscheinlich lückenhaft war. Und es braucht eine dicke Haut, wenn die ersten manuell bedienten Nutzer dir sagen, dass deine Lösung ihr Problem nicht löst.
Erfolg in diesem Bereich bedeutet nicht, dass am Ende alles vollautomatisch läuft. Erfolg bedeutet, dass du ein Problem löst, für das Leute bereitwillig Geld bezahlen. Ob im Hintergrund ein hochkomplexer Algorithmus rattert oder eine kluge Kombination aus Mensch und Maschine arbeitet, ist dem Kunden am Ende völlig egal. Wenn du das verstanden hast, sparst du dir die 80.000 Euro Lehrgeld und baust stattdessen etwas, das wirklich Bestand hat. Es gibt keine Abkürzung zur Marktreife, nur den harten Weg durch die manuelle Validierung. Wer das ignoriert, spielt Roulette mit seinem Budget – und die Bank gewinnt in der Softwareentwicklung fast immer. Es ist nun mal so, dass die meisten Ideen im ersten Kontakt mit der Realität zerbrechen. Besser sie zerbrechen, wenn du nur ein paar Stunden Arbeit investiert hast, als nach einem halben Jahr im Entwicklungstunnel. Das ist der einzige pragmatische Weg, um in diesem Geschäft zu überleben.
