Hören Sie auf, Empfehlungen zu liefern
Seit 15 Jahren ist mein Job, Teams zu helfen, anders zu denken. Workshops moderieren. Sprints durchführen. Menschen dabei unterstützen, ihre Nutzer zu verstehen, Ideen zu generieren und zu priorisieren, was als Nächstes gebaut werden soll. Und ich war gut darin. Die Workshops waren energiegeladen. Die Ideen waren oft wirklich brillant. Die Kunden gingen mit dem Gefühl, dass etwas Wichtiges passiert war.
Dann ist das meiste davon in einer Schublade gestorben.
Nicht weil die Ideen schlecht waren. Nicht weil es den Teams an Engagement fehlte. Sondern weil es immer eine Lücke gab zwischen dem Sprint und dem Moment, in dem tatsächlich jemand anfing zu bauen. Aus Wochen wurden Monate. Momentum schwand. Prioritäten verschoben sich. Das schöne Prototyp-Deck lag in einem Shared Drive, während die Organisation zu den Bränden des nächsten Quartals überging.
Vor zwei Jahren hat sich etwas verändert. Ich habe angefangen, selbst Dinge zu bauen — nicht als Nebenprojekt, sondern als Teil des Sprints. Funktionierende Software, in derselben Woche wie die Discovery und Ideation. Und es hat alles verändert, was Innovationsberatung liefern kann.
Was ein Sprint bisher geliefert hat
Lassen Sie mich ehrlich sein über den typischen Output eines Innovationssprints. Auf der Basisebene bekommt man ein Konzept-Deck — eine gut strukturierte Präsentation mit Empfehlungen, was gebaut werden soll und wie. Professionell, durchdacht, und es braucht sechs bis zwölf Monate Umsetzungsarbeit, bevor irgendetwas Reales existiert.
Eine Stufe höher: ein klickbarer Prototyp. Etwas in Figma, das wie ein echtes Produkt aussieht, aber tatsächlich nichts tut. Nützlich, um Konzepte mit Nutzern zu testen, aber immer noch eine Darstellung einer Idee, nicht die Idee selbst.
Die dritte Stufe ist das, was möglich wurde, als ich das Bauen zur Facilitation hinzufügte. Ein funktionierendes Tool — mit Datenbank, echter Geschäftslogik und einem Interface, das echte Nutzer bedienen können. Kein Mockup, das die Erfahrung simuliert. Die Erfahrung selbst. Deployed in derselben Woche, in der der Sprint stattfand.
Die Lücke, in der Ideen sterben
Ich habe das bei Dutzenden von Organisationen beobachtet. Der Sprint endet am Freitag. Alle sind aligned. Der Executive Sponsor ist begeistert. Und dann geraten die Ergebnisse in das Immunsystem der Organisation.
Budgetfreigaben. Architektur-Reviews. Sicherheitsbewertungen. Vendor-Auswahl. Ressourcenplanung. Jeder Schritt für sich vernünftig. Zusammen bilden sie einen Spießrutenlauf, den die meisten Sprint-Ergebnisse nicht überleben. Bis jemand grünes Licht bekommt, um mit dem Bauen zu beginnen, hat der Champion, der den Sprint vorangetrieben hat, oft das Team gewechselt. Der Kontext, der die Idee dringend gemacht hat, hat sich verschoben. Die Energie ist weg.
Das war der frustrierendste Teil meiner Arbeit über Jahre. Nicht die Workshops — die waren immer gut. Das Danach. Zu wissen, dass die Qualität der Erkenntnis da war, das Alignment da war, und es trotzdem wahrscheinlich zu nichts führen würde.
Was sich verändert hat
Als ich anfing, KI-gestützte Coding-Tools zu nutzen, wurde mir etwas klar: Die Lücke muss nicht existieren. Nicht weil die Tools magisch wären — sind sie nicht. Sondern weil sie die Zeit zwischen "wir verstehen das Problem" und "hier ist etwas, das funktioniert" von Monaten auf Stunden verkürzen.
In einem kürzlichen Sprint habe ich die ersten zwei Tage das getan, was ich immer tue — Betriebsabläufe beobachtet, mit den Leuten gesprochen, die die Arbeit machen, das Problem mit dem Team gerahmt. Klassische Facilitation. Am Mittwochmorgen wechselte ich vom Moderieren zum Bauen. Am Donnerstagabend nutzte das Team eine funktionierende Anwendung auf ihren Geräten. Nicht durch einen Prototypen klicken — echte Daten in ein echtes Tool eingeben.
Das Feedback am Freitag war anders als alles, was ich in 15 Jahren Sprints erlebt hatte. Nicht "Ich stelle mir vor, das könnte funktionieren", sondern "Dieses Feld ist nutzlos, schieb den Status-Indikator nach oben, und können wir einen Alarm für überfällige Aufgaben einbauen?" Konkret, spezifisch, sofort umsetzbar — weil das Tool real war und deshalb auch das Feedback real war.
Warum es nicht ums Coden geht
Ich will hier vorsichtig sein. Es geht nicht ums Coden. Große Beratungen bauen auch Dinge — Accenture, Deloitte, McKinsey Digital haben Entwicklungsteams mit Tausenden von Leuten. Die Bau-Kapazität existiert. Was nicht existiert, ist Kompression. In einem typischen Engagement einer großen Beratung führt das Strategie-Team den Sprint durch. Es produziert Erkenntnisse und Empfehlungen. Dann kommt die Übergabe: Ein Briefing wird geschrieben, ein Anforderungsdokument erstellt, ein Entwicklungsteam, das nie die Nutzer getroffen hat, fängt an zu bauen. Die ursprüngliche Erkenntnis wird in eine PowerPoint komprimiert, durch ein Spezifikationsdokument übersetzt und durch drei Ebenen Projektmanagement verdünnt. Bis etwas gebaut wird, ist das Verständnis, das die Idee gut gemacht hat, verschwunden. Der Unterschied ist nicht, Entwickler zu haben. Es ist, null Übergabe zu haben. Wenn dieselbe Person, die am Montag dem Nutzer bei der Arbeit zugesehen hat, am Mittwoch den Code schreibt, geht nichts in der Übersetzung verloren. Kein Briefing kann einfangen, wie es sich anfühlt, jemandem zuzusehen, der drei Bildschirme prüft, bevor er eine Entscheidung trifft, die mit einem Tap möglich sein sollte. Dieser Kontext lebt im Kopf des Builders — aber nur, wenn der Builder im Raum war.
Die Facilitation ist weiterhin essenziell. Den Problemraum verstehen, gute Discovery durchführen, Erkenntnisse synthetisieren, Alignment moderieren — nichts davon ändert sich. Wenn überhaupt, wird es wichtiger. Denn wenn man schnell bauen kann, hängt die Qualität dessen, was man baut, vollständig von der Qualität des Verständnisses ab. Geschwindigkeit ohne Erkenntnis bedeutet nur, dass man das Falsche schneller baut.
Was sich ändert, ist die zweite Hälfte. Statt ein Deck zu übergeben und zu hoffen, dass jemand es umsetzt, schließt man den Kreis selbst. Verstehen → Gestalten → Bauen → Testen. Alles im selben Sprint. Alles mit demselben Team. Alles informiert durch dieselben Gespräche mit echten Nutzern.
Was das bedeutet, wenn Sie Beratung einkaufen
Wenn Sie Innovationsleitung oder Head of Transformation sind, möchte ich, dass Sie über etwas nachdenken: Wenn Sie das nächste Mal ein Beratungsteam für einen Innovationssprint briefen, fragen Sie, was das Ergebnis sein wird. Nicht konzeptionell — buchstäblich. Werden Sie ein Slide-Deck haben? Einen Figma-Prototypen? Oder ein funktionierendes Tool, das Ihr Team am Montag nutzen kann?
Die Antwort auf diese Frage sagt Ihnen alles über den Wert, den Sie einkaufen. Ein Konzept-Deck kauft Ihnen Alignment und Ideen. Ein Prototyp kauft Ihnen validierte Annahmen. Ein funktionierendes Tool kauft Ihnen einen Vorsprung bei der Umsetzung — und manchmal die Umsetzung selbst.
Die beste Beratung endet nicht mit einer Empfehlung. Sie endet mit etwas, das man benutzen kann. Nicht bewerten, nicht reviewen, nicht freigeben — benutzen.
Ich moderiere immer noch. Ich führe immer noch Discovery-Sessions und Ideation-Workshops und Prototyping-Sprints durch. Diese Arbeit ist so wichtig wie eh und je. Aber jetzt ist sie die Hälfte von dem, was ich tue, nicht alles. Die andere Hälfte ist, Dinge real zu machen. Und diese Kombination — die Fähigkeit, ein Problem tief zu verstehen und dann die Lösung im selben Atemzug zu bauen — ist das, was endlich die Lücke geschlossen hat, auf die ich 15 Jahre lang gestarrt hatte.