Agenten in einer Software Factory finden immer noch ein Problem, noch ein Ticket, noch eine Verbesserung. Wann die Arbeit fertig ist, kann nur eine zweite, viel langsamere Schleife sagen: die bis zum Markt.

Mehr Output, und der Umsatz merkt nichts davon

“Unsere Teams produzieren mit Agenten viel mehr. Warum sehen wir das im Umsatz nicht?” Diese Frage kennen wir aus unserer eigenen Kundenarbeit.

Abends wirft ein Team seine Factory an. Agenten ziehen sich Tickets, schreiben Code, lassen die Tests laufen, reviewen sich gegenseitig und bessern nach, wo die Prüfungen etwas ablehnen. Morgens warten Pull Requests, die meisten grün. Dazu kommen neue Tickets, die die Agenten über Nacht selbst angelegt haben.

Dass der Output steigt, lässt sich messen. Faros AI hat 2025 Daten von mehr als 10.000 Entwickler:innen aus 1.255 Teams ausgewertet. Entwickler:innen in Teams mit hoher KI-Nutzung mergen 98 % mehr Pull Requests, und die Review-Zeit wächst um 91 %. Dabei nutzten die meisten Entwickler:innen im Datensatz nur Autovervollständigung, Agenten kaum. Mit Agenten wird der Sprung größer. Anthropic berichtet, im Mai 2026 im Schnitt rund 2.500 Code-Änderungen pro Tag gemergt zu haben und im September mehr als 30.000. Das waren so viele, dass Anthropic git für sein Monorepo durch einen Eigenbau ersetzt hat.

Im Unternehmen als Ganzem kommt davon wenig an. Auf dieser Ebene fand die Faros-Studie keinen signifikanten Zusammenhang zwischen KI-Nutzung und besserem Durchsatz, besseren DORA-Werten oder besserer Qualität. Als Gründe nennt sie Engpässe nach dem Coden, allen voran im Review, und Teams, die KI unterschiedlich stark nutzen. Wenn der Zuwachs schon dort versickert, wundert es nicht, dass er im Umsatz fehlt.

Bei Teams, die mit Agenten arbeiten, sehen wir einen weiteren, eigenen Grund: Agenten hören nicht von selbst auf. Ein Review-Agent findet in jeder Runde etwas. Jedes Finding wird umgesetzt, und jede Umsetzung liefert das nächste.

Ein Mensch sagt nach der zweiten Runde “gut genug” und lässt den Rest liegen. Vieles, was zählte, meldet sich ohnehin wieder: als Bug oder als Alarm aus dem Betrieb. Ein Agent dagegen kennt kein “gut genug”, solange ihm niemand eines mitgibt. Ein weiteres Finding kostet ihn keine Aufmerksamkeit, also sucht er weiter: noch eine Abstraktion, noch eine Optimierung für eine Last, die es nicht gibt.

Einen Baustein dieses Musters haben Jin und Chen 2026 im Labor gezeigt: Sprachmodelle halten korrekten Code häufig für fehlerhaft, und noch häufiger, wenn sie ihr Urteil begründen und eine Korrektur vorschlagen sollen. Yoko Li von a16z hat einen Agent Loop vermessen, dessen Ziel unerreichbar war. Zwei Drittel der Kosten brachten keinen Fortschritt mehr. Ihr Fazit: Schleifen haben “no idea how to stop”.

Das passiert im Kleinen wie im Großen. Im einzelnen Lauf taucht immer noch ein Finding auf, in der Factory als Ganzes immer noch ein Ticket. Bremsen gibt es für beides: eine maximale Rundenzahl, ein Token-Budget. Wir brauchen sie, doch sie deckeln nur den Aufwand. Wann etwas fertig ist, sagt keine von ihnen.

In der Factory selbst bleibt dafür ein einziges Kriterium: grün. Grün heißt, die Änderung besteht ihre Prüfungen. Ob es die richtige Änderung war, verrät kein Test. Und Code kann eine Prüfung bestehen, ohne besser zu werden. Fehlt die Wirkungsannahme, liefert eine Factory deshalb schnell Features, deren Nutzen niemand geprüft hat. Sie wird zur Endlosschleife, die Tokens verbrennt und Output erzeugt.

Der Titel ist eine Anleihe bei Judas Priest: “Breaking the Law”, 1980. Wer programmiert, kennt break, die Anweisung, die eine Schleife beendet. Ein break für “das reicht jetzt” hat die Factory nicht. Das muss ihr jemand mitgeben.

Den Takt gibt die langsame Schleife vor

Die innere Schleife ist die Factory. hackers&wizards definiert sie als das System, das Softwareänderungen produziert: Sie nimmt eine Absicht entgegen, zerlegt sie in begrenzte Arbeit, versorgt Agenten mit Kontext und nimmt Ergebnisse nach festgelegten Prüfungen an. Schreiben, prüfen, korrigieren: Eine solche Runde dauert Minuten.

Die äußere Schleife ist die Produktarbeit, und sie reicht bis zum Markt. Aus Strategie und Kundenwissen entsteht eine Annahme über die Wirkung. Das Team liefert aus, der Markt reagiert, und was dabei herauskommt, verändert das Wissen der Organisation über ihre Kunden. Ein Durchlauf dauert mindestens Wochen. Markus, einer von uns beiden, hat diese Schleife und ihr Tempo in “AI Flow Dynamics” ausführlich beschrieben.

Die innere Schleife macht das Team effizient, die äußere macht es effektiv. Schnell gebauter Code bringt nichts, wenn er in die falsche Richtung geht. Die richtige Richtung bringt nichts, wenn der Code dafür zu lange braucht. Erfolgreich ist, wer beides gemeinsam optimiert.

Kann ein Team mehr bauen, als es mit Kunden auswerten kann, ist die äußere Schleife der Bottleneck, und daran ändern auch mehr Agenten nichts. Ein Team kann an einem Nachmittag mehrere Optionen erzeugen. Es kann sie Kunden aber nicht im selben Tempo vorlegen und für jede ein sauberes Signal erwarten. Wie viele Features gleichzeitig bei Kunden im Test sein können, bestimmt deshalb das Feedback, das ein Team auswerten kann, nicht seine Baukapazität.

Vier Brüche, an denen ein Mensch entscheidet

Daraus leiten wir unsere Regel ab: Die innere Schleife läuft nur so weit, wie die äußere es zulässt. An vier Stellen braucht es die Entscheidung eines Menschen, sonst geht es nicht weiter. Diese Stellen heißen bei uns Brüche.

1. Weiterdenken: Ist die Idee plausibel genug, um mehr Aufmerksamkeit zu verdienen?
2. Bauen: Ist sie plausibel genug, um sie bauen zu lassen, und was darf das kosten?
3. Ausliefern: Ist das Gebaute gut genug, um an Kunden zu gehen?
4. Behalten: Hat es am Markt gehalten, was die Wirkungsannahme versprochen hat?

Zwei Schleifen, vier Brüche: die Factory läuft im Schritt Bauen

Das Beispiel

Durch die vier Brüche führt uns ein Beispiel. Es ist erfunden, seine Zahlen sollen nur den Ablauf zeigen.

Die innere Schleife läuft nur so weit, wie die äußere es erlaubt: das Beispiel im Überblick

Erster Bruch: Keine Idee geht weiter ohne Wirkungsannahme

Viele Features entstehen morgens unter der Dusche. Früher fing danach die lange Arbeit erst an. Software war teuer, und das Team musste vorher erkennen, welche Variante die richtige ist.

Heute könnte jede dieser Ideen noch am selben Vormittag in der Factory landen. Deshalb fällt die erste Entscheidung, bevor die Factory startet, und sie braucht zunächst nur einen Satz.

Wenn dieses Feature erfolgreich ist, verändert sich für diese Menschen in dieser Situation Folgendes.

Dieser Satz ist die Wirkungsannahme. Erst danach legt das Team fest, an welcher Zahl es die Wirkung beobachten will und bis wann sie sich zeigen soll. Wirkungsannahme, Zahl und Frist zusammen sind das Erfolgsmodell. Es steht neben dem Bedarf in einer Feature-Datei.

Die Reihenfolge hat einen Grund: Nutzung ist noch kein Wert. Ein Sicherheitsgurt ist das Extrembeispiel: Sein Wert liegt im seltenen Ernstfall.

Für die Wirkungsannahme braucht ein Team Produktwissen, an das es herankommt: Strategie, Kundenwissen, KPIs, Research, frühere Features und was aus ihnen wurde. Für den Anfang genügen Markdown-Dateien, solange Menschen und Agenten sie finden und lesen können. Wir nennen das ein Product-Context-System. Darin steht, was die Organisation weiß, was sie vermutet und wo ihr Wissen dünn ist.

Schon dieser eine Satz sortiert aus. Oft sehen wir Features, die gebaut werden, ohne dass ihn vorher jemand aufgeschrieben hat.

Bruch 01: Wirkungsannahme

Zweiter Bruch: Mehrere Optionen bauen, jede mit eigenem Preisschild

Erst schätzen, dann aussortieren

Jede Idee, die den ersten Bruch übersteht, ist eine Option, also ein möglicher Weg, denselben Bedarf zu decken.

Vor die zweite Entscheidung setzen wir einen Forecast. Ein Skill, ein wiederverwendbarer Ablauf für Agenten, erhält die Feature-Datei und Zugriff auf das Product-Context-System. Mehrere Modelle schätzen aus verschiedenen Blickwinkeln, wie wahrscheinlich die Option die Ziele aus ihrem Erfolgsmodell erreicht. Heraus kommt eine Spanne, dazu die Quellen, die gefundenen Widersprüche und die Lücken. Liegen die Schätzungen weit auseinander, wird die Spanne breiter.

Mehr als eine grobe Näherung ist dieser Forecast nicht. Zwei Spannen lassen sich zudem nicht einfach nebeneinanderlegen: Eine kleine, fast sichere Verbesserung kann weniger wert sein als eine große, unsichere. Die Entscheidung bleibt bei einem Menschen.

Bruch 02: Forecast und Budget

Probefahrt statt Prospekt

Als Bauen noch teuer war, hätte das Team an dieser Stelle eine Option in die Entwicklung gegeben und dabei vielleicht die bessere verworfen. Bemerkt hätte es das nie, weil es nur Prospekte verglichen hätte. Hinterher hören wir dann oft: “Wir können nicht wissen, was dabei herausgekommen wäre, dafür gab es keinen A/B-Test.” Alle Optionen zu bauen, wäre zu teuer gewesen.

Weil Code inzwischen günstig entsteht, geht es anders. Die Factory baut mehrere Optionen für denselben Bedarf, und über ein Release ist damit noch nichts entschieden. Markus nennt das Option Storming. Gekauft wird erst nach der Probefahrt.

Das wirkt wie das Gegenteil dessen, was wir oben kritisiert haben. Dort verbrennt die Factory Tokens, hier lassen wir sie absichtlich Optionen bauen, die niemand ausliefert. Der Unterschied: Rechenzeit ist billig, knapp sind die Aufmerksamkeit der Menschen und das Signal vom Markt. Option Storming gibt das Billige aus, um das Knappe zu schonen. Im Beispiel erreichen drei von vier Optionen weder den Trunk, also den Hauptzweig des Produkts, noch den Markt.

Beliebig viele Optionen sind es trotzdem nicht. Jede Probefahrt kostet das Team Zeit, und wer mehr Optionen baut, als er ernsthaft ausprobieren kann, wählt dadurch nicht besser. So arbeitet Option Storming der äußeren Schleife zu: Statt Optionen früh aus dem Bauch heraus zu streichen, probieren wir sie gebaut aus und schicken nur die besten in den engsten Bottleneck, den Markt.

Option Storming: gebaut ausprobieren, nur die besten in den Markt

Die Bremsen bekommen einen Maßstab

Am Anfang jedes Laufs steht der Intake. Er erhält die Feature-Datei und prüft als Erstes, ob sie zum Bauen reicht. Nach unserer Erfahrung wird aus einer unklaren Anforderung ein unklarer Plan und aus dem Plan Code, den die Prüfungen ein ums andere Mal ablehnen. Ein guter Intake fragt deshalb beim Produktteam nach, bevor ein Agent auch nur eine Zeile schreibt. Fehlt dieser Schritt, baut die Factory womöglich perfekt das Falsche.

Dann starten die Agenten, ein eigener Lauf pro Option. Jetzt kommen die Bremsen vom Anfang wieder ins Spiel, diesmal mit einem Maßstab aus der äußeren Schleife.

Ein Budget pro Option. Product Manager und Engineering setzen es gemeinsam fest, in Euro für Tokens und in Korrekturrunden. Seine Höhe richtet sich danach, was dem Team die Entscheidung zwischen den Optionen wert ist. Ist das Budget aufgebraucht, endet der Lauf, und auch dieses Ergebnis schaut sich das Team an. Vielleicht war die Option zu groß geschnitten oder zu vage beschrieben, oder es fehlen ihr Daten.

Akzeptanzkriterien entscheiden, welches Finding zählt. Der Review-Agent findet weiterhin in jeder Runde etwas. Umgesetzt wird aber nur, was gegen ein Akzeptanzkriterium oder eine Prüfung verstößt, Sicherheitsprüfungen eingeschlossen. Belegt der Agent einen Fehler, den noch keine Prüfung abdeckt, etwa eine Sicherheitslücke oder falsche Daten, wird er behoben und als neues Kriterium oder neue Prüfung festgeschrieben.

Alles Übrige wandert auf eine Liste, die erst ein konkreter Anlass wieder öffnet: ein Bug, ein Alarm aus dem Monitoring, eine gemessene Latenz. Bis dahin ist der Code gut genug. Auf diese Weise endet auch der einzelne Lauf, entweder an erfüllten Kriterien oder am Budget.

Eine Prüfung sagt, wofür sie da ist. Eine Linter-Meldung wie function is too complex (11 > 5) teilt dem Agenten mit, dass etwas nicht stimmt, aber nicht, wie es besser wird. Häufig verschiebt er daraufhin nur Verzweigungen in Hilfsfunktionen.

Liina Suoniemi hat das in einem kleinen Test gemessen. Fragte eine Anleitung, welche Aufgabe die Funktion hat, stieg bei Sonnet 4.6 der Anteil echter Vereinfachungen von 11 % auf 78 %.

Tools wie Habit Hooks tauschen jede Meldung gegen eine kurze Anleitung.

Optionen enden vor dem Trunk. Jede Option entsteht als Wegwerf-Build auf einem eigenen Branch, mit Preview-Umgebung und Testdaten und mit Belegen: Screenshots, einem aufgezeichneten Klickpfad, Testergebnissen. Solche Builds kosten Tokens und den Betrieb der Preview.

Auf Dauer teuer wird Code im Trunk. Dort muss jemand die Verantwortung für ihn tragen, und Optionen, die nie nebeneinander existieren sollen, stehen sich gegenseitig im Weg. Was das Team nicht auswählt, räumt die Factory ab. Die Feature-Datei hält fest, was gebaut wurde und warum es endete.

Die Messung gehört zu den Akzeptanzkriterien. Steht im Erfolgsmodell, dass Teamleiter den Entwurf öffnen, bearbeiten und teilen, baut die Factory die passenden Events gleich mit. Eine Prüfung stellt sicher, dass sie auch ankommen. Wer diesen Teil weglässt, hat am Ende der Frist die vereinbarte Zahl nicht.

Dritter Bruch: Gebaut heißt noch nicht ausgeliefert

Nun kommt die Probefahrt. Product Manager, Design und Engineering klicken sich durch die Previews und holen, wo es sinnvoll ist, einzelne Kunden dazu. Der Forecast-Skill bewertet die Optionen erneut, diesmal mit den Belegen aus der Factory.

Streng bleibt die Auswahl trotzdem, denn Marktfeedback ist knapp und kommt langsam. Sie kommt nur später, wenn das Team mehr weiß.

Bruch 03: Probefahrt

Abgenommen wird die Option, nicht der Diff

Ein Pull Request legt jemandem eine einzelne Änderung zur Prüfung vor. Agenten erzeugen solche Änderungen schneller, als Menschen sie lesen können. Kleinere Pull Requests und Agenten, die einen Teil davon selbst freigeben, verschaffen etwas Luft, so macht es etwa PostHog. Entschieden wird aber eine Ebene höher: Das Produkt nimmt die Option ab, nicht den Diff.

Der Build der gewählten Option wird nicht gemergt. Als Wegwerf-Build sollte er eine Entscheidung ermöglichen, nicht bleiben. Er dient als Vorlage, nach der die Factory das Feature in kleinen Schritten auf dem Trunk neu baut, mit denselben Prüfungen wie jeder Lauf und mit eigenem Budget. Abgenommen ist das Feature, sobald es die Akzeptanzkriterien und Klickpfade der Option besteht. Riskante Schritte lesen Engineers, den Rest prüft ein Review-Agent. Den Code der verworfenen Optionen liest kein Mensch. Dass wir neu bauen statt mergen und abräumen statt aufheben, beruht auf einer Annahme: Bei Token-Kosten von wenigen hundert Euro ist Neubauen billiger als Aufheben und Pflegen.

Ausliefern mit Verfallsdatum

Technisch verlangt der dritte Bruch, dass Deploy und Release getrennt sind. Die Factory bringt das Feature hinter einem Feature Flag in Produktion und versieht es mit einem Verfallsdatum, der Frist aus dem Erfolgsmodell. Überschreiten Fehlerraten oder Latenzen die vereinbarten Schwellen, rollt die Factory die Änderung von sich aus zurück.

Ob das Feature wirkt, zeigt sich dagegen erst im Lauf der Frist, im Beispiel innerhalb von acht Wochen. Wer es in dieser Zeit zu sehen bekommt, entscheidet der Product Manager. An dieser Stelle gibt die äußere Schleife den Takt vor, und die innere wartet.

Vierter Bruch: Ein Feature muss sich seinen Platz verdienen

Nach unserer Erfahrung bleibt in den meisten Produkten alles Ausgelieferte, bis jemand die Kraft aufbringt, es wieder zu entfernen. Ohne Frist leidet die äußere Schleife am selben Problem wie die innere: Sie hört nicht auf. Die Erfahrung großer Experimentierer spricht aber dagegen, dass Bleiben der Normalfall sein sollte. Microsoft berichtet, dass rund ein Drittel der getesteten Ideen positiv wirkt. Bei Booking.com verbessern neun von zehn solcher Ideen die Metriken nicht.

Bruch 04: Verfallsdatum

Mit dem Verfallsdatum kehrt sich der Normalfall um. Ist die Frist abgelaufen, entfernt die Factory das Feature wieder, außer ein Mensch entscheidet, dass es bleibt. Auch dieser Normalfall ist eine Entscheidung, nur hat das Team sie schon mit der Frist getroffen. Damit hat auch die äußere Schleife eine Grenze. Die innere hat ein Budget in Tokens und Korrekturrunden, die äußere eine Frist in Wochen. Das letzte Review übernimmt in diesem Ablauf der Markt, und es betrifft ein ganzes Feature.

Für Projekte kennt Basecamp den Circuit Breaker: Was im gesetzten Zeitraum nicht fertig wird, bekommt im Regelfall keine Verlängerung. Wir übertragen ihn auf ausgelieferte Features. Wie streng die Frist ausfällt, legt das Team fest.

• In der harten Variante fliegt raus, was seine Wirkung nicht zeigt.
• Eine mittlere Variante lässt eine Verlängerung zu.
• In der mildesten entfernt die Frist nichts und erzwingt nur am Stichtag eine Entscheidung.

So oder so hängt das Team die tatsächlichen Daten an die Feature-Datei. Die Daten gibt es, weil die Factory die Messung mitgebaut hat.

Der Weg des Beispiels: von sieben Ideen zu einem entfernten Feature

Was das für Umsatz und Zeit bedeutet

Und der Umsatz? Über den entscheidet die äußere Schleife, und die ist durch Agenten nach unserer Erfahrung nicht schneller geworden. Mehr Output hilft dort vor allem, wenn er besser auswählen lässt, was den Markt erreicht.

Und die Zeit, die beim Codeschreiben frei wird? Sie kommt nicht von allein an.

Aruna Ranganathan und Xingqi Maggie Ye haben Anfang 2026 Zwischenergebnisse einer Studie vorgelegt. Acht Monate lang haben sie ein Technologieunternehmen mit rund 200 Beschäftigten begleitet. Mit KI waren die Leute dort schneller, übernahmen mehr verschiedene Aufgaben und arbeiteten länger, oft ohne dass jemand es verlangt hatte. Untersucht wurden mehrere Funktionen, nicht nur die Entwicklung.

Für uns heißt das: Gewonnene Zeit füllt sich von selbst mit mehr Arbeit. In Teams mit einer Factory ist das nach unserer Beobachtung meist noch mehr Bauen, also innere Schleife. Wer die Zeit nicht verplant, verliert sie genau dorthin.

Dabei gehört die Zeit in die äußere Schleife: in Wirkungsannahmen, Probefahrten und Gespräche mit Kunden. Sinnvoll war das schon immer. Nach unserer Erfahrung blieb dafür nur wenig übrig, solange das Bauen die Zeit des Teams auffraß.

Wo dieses Modell an Grenzen stößt

Dass die Probefahrt hilft, ist eine Annahme. Wir halten es für plausibel, dass Teams nach einer Probefahrt besser wählen als nach dem Prospekt. Gemessen haben wir das nicht. Dazu kommt, dass vor allem das Team selbst die Probefahrt macht, und wir vermuten, dass es die eigene Preview nachsichtiger bewertet. Einzelne Kunden davorzusetzen hilft.

Der Forecast ist nicht kalibriert. Ob Sprachmodelle die Wirkung eines Features brauchbar schätzen können, ist offen. Der Forecast sortiert vor und zwingt dazu, Annahmen aufzuschreiben. Mehr sollte ihm vorerst niemand zutrauen.

Vier Entscheidungen können zur neuen Warteschlange werden. Der stärkste Einwand gegen jede menschliche Entscheidung im Ablauf: Menschen skalieren nicht. Die vier Brüche gelten aber pro Idee, nicht pro Änderung, und die Factory bereitet jede Entscheidung mit Belegen vor. Wer trotzdem mehr Features zur Entscheidung bringt, als er entscheiden kann, hat den Bottleneck bloß verlagert.

Wartbarkeit schlägt nicht von selbst Alarm. Findings zu Struktur und Wartbarkeit landen auf der Liste, und weder ein Bug noch ein Alarm öffnet die Liste wieder. Wer nicht will, dass die Wartbarkeit verfällt, schreibt sie als Prüfung fest.

Entfernen hat seinen Preis. Nimmt man Kunden ein Feature weg, das sie schon nutzen, kann das Vertrauen kosten. Darum geht die Auslieferung zuerst an eine begrenzte Gruppe. Sauber entfernen lässt sich nur, was dafür gebaut wurde: mit eigenem Flag, eigenen Daten und ohne Schnittstelle, auf die sich andere verlassen. Deshalb gehört der Rückbau in die Akzeptanzkriterien.

Die Frist kann zu kurz sein. Kleine B2B-Kundengruppen liefern nach unserer Erfahrung in wenigen Wochen oft kein sauberes Signal. Die Länge der Frist legt das Team deshalb für jedes Feature eigens fest.

Nicht alles hat Optionen oder ein Verfallsdatum. Eine Migration oder eine regulatorische Änderung baut niemand viermal, und automatisch entfernt sie auch niemand. Die Wirkungsannahme und die Messung in den Akzeptanzkriterien gelten dort trotzdem.

Was ihr am Montag tun könnt

Für die ersten drei Schritte braucht ihr keine Factory.

1. Schreibt die Wirkungsannahme für die nächsten drei Features in eurer Warteschlange auf. Wo euch das nicht gelingt, habt ihr ein Feature gefunden, das nicht weitergehen sollte.
2. Macht die Messung zum Teil der Akzeptanzkriterien eures nächsten Features.
3. Gebt dem nächsten Feature ein Verfallsdatum und entscheidet am Stichtag, ob es bleibt.

Für die Schritte 4 und 5 braucht ihr Agenten.

1. Lasst euren Review-Agenten nur noch gegen Akzeptanzkriterien und Prüfungen arbeiten. Belegte Fehler werden zu neuen Kriterien, alles andere wandert auf die Liste.
2. Lasst für einen einzigen Bedarf zwei Optionen mit Budget bauen und entscheidet erst anhand der Previews.

Wann die Arbeit fertig ist

Sobald es ein Erfolgsmodell gibt, ist es kein Mangel mehr, dass eine Factory nicht von selbst aufhört. Dann haben beide Schleifen ihr break. Die innere endet an Akzeptanzkriterien und Budget, die äußere an der Frist aus dem Erfolgsmodell. Fertig ist die Arbeit, wenn der Markt geantwortet hat und ein Mensch entschieden hat, ob das Feature bleibt.

Das Gespräch dazu

Wie wir da hingekommen sind: Stories Connecting Dots, Ep. 42 mit Benedikt Stemmildt von hackers&wizards. Die Folge ist lang. Mit Absicht. Ihr hört uns beim Denken zu.

Quellen und Vertiefung

• hackers&wizards: Was ist eine Software Factory?
• hackers&wizards: Verifikation entscheidet über den Durchsatz
• hackers&wizards: Coding-Speed ist nicht Delivery-Speed
• Markus Andrezak: AI Flow Dynamics - The Loops Don’t Get Faster On Their Own, 18.06.2026
• Markus Andrezak: Option Storming - The 3D Chess Behind Claude Code, 13.03.2026
• Yoko Li, a16z: Knowing When to Stop: The Art of Making a Loop Converge, 06.08.2026
• Faros AI: The AI Productivity Paradox Research Report, 23.07.2025
• Anthropic: Redesigning source control at Anthropic, 13.10.2026
• Aruna Ranganathan, Xingqi Maggie Ye, Harvard Business Review: AI Doesn’t Reduce Work - It Intensifies It, 09.02.2026
• Haolin Jin, Huaming Chen: Are LLMs Reliable Code Reviewers? Systematic Overcorrection in Requirement Conformance Judgement, 28.02.2026
• Liina Suoniemi: prompt-vs-metric-eval, 2026
• Habit Hooks: habit-hooks
• Jina Yoon, PostHog: Stop being the code review bottleneck, 09.07.2026
• Ryan Singer, Basecamp: Shape Up, Kapitel 8: The Betting Table
• Eric Colson, Daragh Sibley, Dave Spiegel, Stitch Fix: The Sobering Truth About the Impact of Your Business Ideas, 04.11.2021, dort die Angaben zu Microsoft und Booking.com

Felix’ Raum auf felixrieseberg.com: Schreibtisch, Röhre, VHS-Kassetten, Regen vor dem Fenster.

Noch kurz zum Hintergrund: zeitweise haben bei Felix bis zu 60 unabhängige Threads an Felix’ Website gearbeitet, mit Details wie: Die Musik wurde selbst gerechnet, wofür ein eigener Synthesizer in Python gebaut wurde. Die Kopie einer Werner-Herzog-Dokumentation wurde gerendert und läuft in einem kleinen Monitor im „Büro“. Das ganze Büro ist ein komplexes 3D-Objekt mit zig Details wie 3D-gerenderten Videokassetten, Monitoren, Regalen usw. (An die Komplexität heranzukommen war nicht mein Ziel, aber zu verstehen, wie das geht und wo die Grenze ist.)

Das Objekt, an dem ich es probieren wollte: Auch eine Art Intro / Skip Intro zu meiner Website, mit der Bedingung, dass es nur ein Layer wird und Google und die AI-Bots weiterhin meine Seite ungehindert lesen können. Ich wollte ja nur etwas probieren, um zu lernen.

Im Ergebnis: Wenn du in den letzten 2 Wochen ueberproduct.de besucht hast, kamst du in meinen Raum. Ein Tisch vor einem großen Fenster. Draußen der Mont Blanc. Auf dem Tisch eine gelbe Moccamaster, ein oranger SABA-Fernseher, ein cremefarbenes Radio, ein Buch mit einem Sticker drauf: „Bald“.

Fährst du über die Kaffeemaschine, brüht sie und du kannst einen Termin mit mir buchen. Fährst du übers Radio, läuft der Podcast, klickst du, kommst du zu den Podcast-Folgen. Auf dem Fernseher läuft ein Training, wie in Zoom. Klickst du, kommst du zu meinen Trainings. Oben rechts steht „Sofort“. Ein Klick, und du bist auf der normalen Website.

Das ist das Cover. Gebaut an einem Tag, am 20. Oktober. Morgens um sieben ging’s los, um zehn nach fünf war es live. Ich habe keine Zeile Code geschrieben. Und keine gelesen.

Klingt easy. War es nicht. Zumindest nicht bis zum Mittag.

Und es ist noch schlimmer: Was Claude in seinem Bericht aus seiner Perspektive nicht wissen konnte und damit verschweigen musste: Ich hatte das Ganze schon einmal probiert, das Ergebnis war aber zu kitschig geworden und ich bin in Probleme mit „Projects“ gelaufen. Die Project-Learnings kommen ganz am Ende.

Der erste Versuch, Tage davor. Die Aiguille du Midi als Sternbild. Zu kitschig.

Das Cover, Desktop. Screenshot von heute.

Was ich wollte

Obwohl das alles nach „Skip Intro“ klingt und aussieht, durfte es das nicht werden. Das war einer der wichtigsten Sätze im Briefing. Wer alt genug ist, kennt noch die Vorspänne aus den Nullerjahren, die nichts zum Angebot sagen, beim ersten Mal vielleicht noch lustig sind, aber bald nur noch nerven und - schlimmer - vom Inhalt ablenken und ihn verdecken. Ich wollte das Gegenteil. Ein Cover, das hilft, die Website schnell zu erschließen und schnell auf den relevanten Bereich zu klicken. Nach zehn Sekunden weißt du, was ich anbiete: AI-Augmented Product Management, das Strategy Collective, einen Kaffee mit mir. So wenig störend, dass man es jedes Mal zeigen kann.

Dazu sollte es warm sein und charmant. Aber kein Kindergeburtstag. Meine Kunden sind erfahrene Produktleute, die zweitausend Euro für Strategiearbeit zahlen. Charme heißt hier: Geschmack, Licht, ein kluges Detail. Nicht Gags. Und vieles davon ist subjektiv, deswegen war der Filter: Hat es etwas mit mir zu tun?

Der Maßstab war also Felix’ Raum. Gesteuert vom Handy, unterwegs auf dem Rad. Keine Zeile Code gelesen.

Ich dachte: Genau so. Das mach ich auch.

Der Vormittag: fast zum Verzweifeln

Wie es am Morgen anfing. Wie gesagt: eine schlechte Erfahrung ging voraus, so dass ich schon einiges wusste. U. a. die neuen Projects in Claude (nicht die alten aus Cowork usw. – das hier ist ein anderes Biest). Schlussfolgerung: Ich muss mehr in Kontrolle sein, weil nicht klar ist, was Projects koordinieren und was nicht. Drum: Erst mal Setup. Spielregeln für alle Threads, eine Datei für Entscheidungen, eine Liste aller Versuche, das Repo der Website ans Projekt gehängt. Erster kleiner Stolperstein gleich am Anfang: Projects laufen in der Cloud bei Anthropic. Und der Cloud-Rechner, auf dem Claude arbeitet, durfte Felix’ Artikel nicht öffnen. Die Netzwerkfreigabe hatte sich still wieder auf „eingeschränkt“ gestellt. Ich hatte das schon mal auf voll gestellt. Wieder umgestellt, weiter.

Jetzt Discoveryphase: Hier wollte ich vor allem viele unabhängige Threads ausnutzen. Erst einmal viele Grundrichtungen. Einfache Wireframes, um eine Bürokonstruktion zu finden, die passt. Büro, Ausblick, Fenster – aber Weite. Alles auf einmal. Daran war ich zuvor gescheitert und habe mir vieles schwer gemacht. Deswegen jetzt erst einmal viel, grob und roh. Striche. Dazu noch Briefings von Orten, die mit zu tun haben um den „Ton“ mit reinzubringen. Ich habe viel erzählt, buchstäblich in Claude diktiert. Fotos geschickt: Aiguille du Midi, der Blick auf den Mont Blanc, ein Glasbüro im Morgennebel, Felix’ Schreibtisch. Gesagt, dass das Eindrücke sind, keine Vorlage. Als es nicht weit genug wurde, habe ich Felix’ Artikel mitgeschickt, um zu zeigen, wie breit dort gestreut wurde. Claude schickt nicht viele parallele Agenten von sich aus los und versuchte es erst einmal einfacher.

Was jetzt kam: zwölf Welten als Strichskizzen. Dann Varianten davon. Dann ein heller Raum in 3D. Dann derselbe Raum in sechs Farbpaletten. Dann mit Holztextur. Gipfelnd in Nussbaum. Hier bin ich gestorben, weil es offensichtlich ein Missverständnis gab. Nach allem, was wir durchlebt hatten, war mir nicht klar, wie jetzt Nussbaum kommen konnte als dominierende Textur, Charakter: Nussbaum ist das schlimmste aller Möbelhölzer.

Der echte Fail: Jetzt wurde aber jede Runde enger, nicht weiter. Hatte ich mich für eine Richtung entschieden, wurde diese sofort geschlossen und fast „produziert“. Aber nichts wurde besser. Kein Gegenentwurf, keine Überraschung. Halbgutes wurde als Einengung genommen. Middle of the road. Und nirgendwo Charme, um den es aber ging.

Ein Teil davon war hausgemacht. Ich hatte gesagt: frühe Phasen grob, keine Hi-Fi-Ergebnisse. Gemeint war Brainstorm-Niveau. Angekommen ist Wireframe. Baukasten-SVG trägt kein Gefühl.

Mein Learning: ich muss unendlich aufpassen, dass Konkretisierungen nicht sofort wörtlich genommen werden. Uns Menschen geht es oft ähnlich. Ich war einmal in einem Unternehmenskontext, da hat jemand anderen gerne Richtungen erklärt, indem er konkrete Lösungsbeispiele genannt hat. Die Kollegen wurden wild, weil sie dachten, sie sollen das jetzt bauen. Er wollte damit aber nur die Richtung andeuten, die konkrete Lösung war ihm egal. Den Unterschied zu verstehen ist nicht trivial. Hier auch nicht.

Ich hatte dann diesen „erfolglosen“ Thread gestoppt. Neuer Anlauf, diesmal Hauptthema „mit Charme“. Hauptsache Nussbaum geht weg. (Es klingt albern, während ich es schreibe, wirkte aber damals existentiell.) Ergebnis: sechs Themenorte. Baumhaus, Ballon, Alm-Festival, Segelboot, mit Witzschildern. Das Pendel war volle Kiste auf die andere Seite geschwungen. Entertainment. Kindergeburtstag. Party-Gags. Ich konnte meinen Augen nicht trauen. Wo war all mein Input hin? Alles, was ich beschrieben hatte, schien buchstäblich vom Tisch gefegt worden zu sein.

Um halb zehn habe ich geschrieben: „ok, schon wieder zum Verzweifeln.“ Und kurz danach, kurz vor Surrender: Wenn das die Grenze ist, dann jetzt ein ehrliches Urteil und Finito.

Wo der Diff zu Felix lag

Ich habe dann gefragt, was eigentlich der Unterschied ist. Ich bilde doch Felix’ Prozess ab. Sowohl Claude als ich wussten, „wie es geht“, und taten doch etwas anderes. Wo ist also der Diff?

Die Antworten waren unbequem, für beide Seiten:

• Ein Thread statt zehn. Felix hatte zehn Richtungen parallel. Bei uns hat ein einziger Thread alles nacheinander gemacht. Eine Hand, also immer dieselbe Mitte.

• Verengen statt verdoppeln. Wenn Felix sich für eine Richtung entschieden hatte, gab es in der Folge fünf mutigere Varianten davon. Wir hatten Hölzer iteriert. Boring.

• Skizzen statt Seiten. Felix’ Brainstorms sehen aus wie fertige Seiten. Art Direction, Typo, Farbe, eine Idee. Unsere sahen aus wie Wireframes. Immer noch. Wir hatten die Phase nicht geändert, obwohl wir weiter waren. Worst of all worlds. Low-Fi geblieben, aber eingeengt. Meilen davon entfernt.

• Stille Post. Der Koordinator, also der Claude, der die Threads steuert, hat meine Kritik umformuliert weitergegeben. Damit hat er die Threads hin und her geschoben.

Und mein Teil, den ich mir auch anhören musste: Parallele Threads hätte ich von Anfang an verlangen können. Ich hatte ja Felix’ Post geschickt. Aber genauso: Die Briefings hätte der Koordinator aus meinem Input festlegen müssen, statt jedes Mal neu zu interpretieren.

Dann kam der Klassiker. Ich gebe einen Hinweis, und es wird sofort alles Bestehende weggeworfen. Ich gebe nur Ziele, wie Felix sagt („We’re talking more about goals and less about how to achieve them“), und es wird beliebig. Honestly, da bin ich tagelang durch. Beides ist falsch.

In the heat of the moment ist es unheimlich schwer, das „Wie“ komplett abzugeben und wirklich immerzu nur auf den Outcome zu reagieren und auf dieser Ebene zu bleiben. Ich predige das in meinen Kursen von morgens bis abends und in meinen Alltags-Tasks bin ich dabei religiös. Hier war aber neues, forderndes Gelände und - zack - schon wurde ich schwach und damit war Claude nicht klar, auf welcher Ebene ich „rede“.

Finally: Was das Projekt gerettet hat

Drei Dinge. Alle nicht trivial, keins davon steht in Felix’ Artikel. Wie immer: Fragst du den Experten, kann er dir nicht erklären, warum es bei ihm klappt.

Ein Brief, nur mit meinen Worten. Eine Datei. Alles, was ich gesagt habe, möglichst wörtlich. Keine Regeln von Claude dazu. Neue Kritik wird ergänzt, sie ersetzt nichts. Das war der Anker gegen das Pendel.

Ein Prüfer, der nur den Brief kennt. Bevor ich einen Entwurf sehe, prüft ihn ein unabhängiger Claude gegen den Brief und meine Bilder. Hartes Ja oder Nein. Was durchfällt, sehe ich nicht. Das hat Runden gekostet. Aber es hat mir den Müll erspart. Konkret heißt das: Claude baut viele Varianten zu Details oder Aspekten im Hintergrund, die ich gar nicht zu sehen bekomme, weil Claude sie bezüglich meiner Intention schon nicht mehr passend findet. Der ganze Zweig und die Enttäuschung zu „Nussbaum“ wären entfallen. Stunden von Frustration.

Kurzer Hint: Hier lohnt es sich, Entwicklern ihre Praktiken zu „klauen“. Mehr in einem späteren Artikel.

Feedback ist ein Diff. Was ich nicht kritisiere, bleibt stehen. Neu angefangen wird nur, wenn ich es sage. Es klingt banal, war aber der wichtigste Satz des Tages.

Dazu ein Satz, den ich irgendwann einfach geschrieben habe: „Vielleicht müssen die Threads erstmal verstehen, dass sie Designer sind.“ Wenn ich einer Agentur sage „ich mag die Struktur von dem und die Wärme von dem und Details wie den Plattenspieler“, dann kombiniert die das und legt nach. Sie engt nicht ein. Genau das steht seitdem ganz oben im Gedächtnis des Projekts.

Konkret sitzt man vor den Ergebnissen, öffnet Sprachmodus und diktiert Stream of Consciousness, was einem gefällt und was nicht. Verrückterweise macht es das wieder einfach. Man muss sich aber dran halten.

Das hatte aber etwas zur Folge, was ich bis heute merkwürdig finde: Ich wurde irgendwann paranoid, den Agenten Feedback zu geben. Weil sie oft so unglaublich sensibel reagieren (siehe das Pendel Richtung Party-Gag als Beispiel). Kritik kam an wie ein Erdbeben. Zerknirschung, Neustart, alles neu. Auch das steht jetzt im Gedächtnis. Also: Kritik nüchtern als Diff nehmen. Kurz bestätigen. Weiterarbeiten.

Am Rande: Felix arbeitet bei den Modellen auf hoher Denkstufe, ich auf mittlerer. Der Koordinator hat vorgeschlagen, hochzudrehen. Ich habe das nicht gemacht. Mittel überall. Goldilocks. Ich bin mir sicher, das hätte nicht den Unterschied gemacht. Was ein Problem war, war kein Modell-Problem. Das ist auch, warum ich den Tipp Claude nicht abgenommen habe.

Next Step: Vier Richtungen, dann drei, dann eine

Um 9:39 liefen dann vier Threads parallel. Alle mit demselben Brief.

• Glashaus: Schreibtisch vor dem Mont Blanc im Alpenglühen.

• Foto mit Tiefe: mein Bergfoto plus Tiefenkarte, Felix’ Trick mit Depth Anything V2. Der Berg bewegt sich leicht gegen den Raum, wenn du die Maus bewegst.

• Retro-Hightech: Bernstein-Terminal, Fallblatt-Countdown. Erste Fassung „zu stark 1:1 geklaut“, das war Felix’ Röhre mit Felix’ Kassetten. Zweite Fassung eigen. Das ist oft passiert: ich hatte so viel Felix-Briefing drin, dass es schwer war, davon wegzukommen (offenbar außer bei Nussbaum ;) Bis jetzt ist alles auf einer gewissen Ebene eine Felix-Kopie, ganz anders aber eben doch. Aber good enough for my purpose.

• Spiel-Tutorial: Sonnenuntergang, 8-Bit. Zu dunkel. Und eine Liste links, die es auf der Website schon gibt. Das Cover soll nicht doppeln. Die Gegenstände sollen die Highlights erschließen.

Mittags, nach der nächsten Runde, mein Fazit: „Ha. Die Runde hat fast keine Erkenntnis gebracht.“ Aber jede Richtung hatte ein Stück, das trug. Das Glashaus hatte die Weite. Retro-Hightech hatte den meisten Charme im Büro. Foto mit Tiefe den besten Hintergrund.

Jetzt war die Konsequenz, die Denk-Threads zusammenzubringen: Hintergrund etwas videospieliger, Büro etwas fotorealistischer, in der Mitte treffen. Dazu habe ich Bilder geschickt von Geräten, die ich liebe. Farbiges 70er-Industriedesign. Moccamaster gelb, SABA orange.

Original aus dem Thread: Moccamaster gelb, SABA orange. „Hier Ästhetik für Geräte usw.“

Und weil ich wieder breit gehen wollte: drei analoge Looks parallel, je ein Thread. Filmfoto, Siebdruck, Gouache-Plakat.

Die drei analogen Looks nebeneinander: Filmfoto, Siebdruck, Gouache-Plakat.

Um 13:50 war klar: Filmfoto gewinnt. „Kombination: Weite, Büro, Berg.“ Alles ist ein Mittelformat-Negativ. Berg und Büro durch dieselbe Entwicklung. Weiche Lichter, warme Schatten, Korn, ein Lichthof um helle Stellen.

Kleine Randnotiz zum Thema Projekte (immer noch: Fazit siehe unten): In genau der Minute hat der Koordinator dem Gewinner-Thread erst gesagt, er solle aufhören, es gehe mit dem Gouache-Plakat weiter. Zwei Minuten später: Kommando zurück. Wer viele Threads steuert, verwechselt auch mal welche.

Durchbruch: Ab hier wurde es easy

Und dann, ab hier, wirklich, kippte es. Ab dem Gewinner war es ein Vergnügen. Jetzt geht es um Details, Polish, es „schön“ machen. Ab hier ist es eher schwer aufzuhören.

Ich sage etwas, zehn Minuten später steht es da. Gleicher Link, neue Version. Ich klick mich am Handy durch, schick zwei Sätze zurück. Dopaminrausch: Gedanken werden sozusagen Wirklichkeit, weil der Rahmen steht.

• Moccamaster aus Blender. Ein freies Modell gab’s im Netz nicht, nur Kaufmodelle. Also selbst gebaut, echte Maße 36 × 32 × 17 cm, Proportionen aus meinem Foto. Genau das, was ich bei Felix gelesen und vorher nie bekommen hatte: Claude löst das Asset-Problem selbst, statt zu klagen, dass es keine Fotos gibt.

• Radio. Ich habe drei Vorschläge gemacht: Krups, Europhon, Seiko. Der Thread hat als Designer gewählt. Das Europhon, weil es das einzige echte Radio ist und flach liegt. In Creme statt Orange, sonst stehen da zwei orange Kisten. Gute Begründung. Genommen.

• Fernseher. Zeigt eine Zoom-Sitzung. Kanal 1 AI-Augmented PM, Kanal 2 Strategy Collective. Im Hintergrund ein Gespräch mit viel Hall, wie Atmo im Videospiel, aus einem gemeinfreien LibriVox-Hörspiel. Das Umschaltgeräusch war zu laut. Ein Satz von mir, jetzt ist es ein Zehntel.

• Kaffee. Fährst du drüber, brüht sie. Zischen, Gluckern, ein Tropfen. Und alles andere tritt zurück, damit du nur das Blubbern hörst. Klickst du, kannst du einen kurzen, kaffeelangen Slot mit mir buchen.

• Das Buch. Mit Sticker „Bald“. Du kannst blättern. Das E-Book zum Strategy Collective kommt.

• Mauseffekt und Übergang liefen parallel in eigenen Threads, als eigene Module. Ich habe gewählt: Licht plus leichte Regung, wenn du in die Nähe kommst. Und der Übergang „Schirm“: Du fährst rein ins Gerät, drüben schaltet die Website ein wie ein Röhrenfernseher.

Original aus dem Thread: „Radio: Krups, Europhon oder Seiko“. Gewonnen hat das Europhon.

Fernseher und Moccamaster im Detail.

Dann die Feinschliffe. Mehr Glow auf dem Grat. 25 Prozent mehr? Zu viel, zurück auf 15. Das Label „Aiguille du Midi 3842 m“ muss weg. Der Tisch 18 Prozent dunkler für den Kontrast. Der Claim heißt jetzt: „Produkt und Strategie. Und AI dazu. In einem.“

Um 16:33 habe ich geschrieben: „sehr gut.“

Das Bild war von mir

Eine Geschichte noch, weil sie so schön ist. Vor dem Livegang ging es um Lizenzen. Wem gehört das Bergfoto? Der Koordinator hatte aus einem Dateinamen einen Fotografen von Pixabay abgeleitet. Falsches Bild. Dann einen anderen Fotografen. Auch falsch. Dann die Vermutung, es sei ein Airbnb-Screenshot.

Bis mir einfiel: Das Bild ist von mir. Kein Credit, kein Tausch, kein Thema. Huch, das gehört ja ohnehin mir. Das hatte ich aber im Eifer des Gefechts vergessen.

Live

Um 16:34 hab ich gefragt: Wollen wir es live testen? Ein eigener Thread hat das Cover als Ebene über die Startseite gelegt. Die Startseite bleibt darunter, auch für Google. Das Cover kommt nur, wenn du von außen kommst, nicht beim Klick auf Home. In der Navi steht jetzt „▲ Raum“, damit man zurück kann.

Dann Safari. Ich bin ja nicht der Headless-Browser.

• Der Ton startet nicht von allein. Geht auch nicht, das verbieten alle Browser vor dem ersten Klick. Jetzt sagt der Knopf das ehrlich.

• Schwarze Felder, die unförmig der Maus hinterherlaufen. Reproduziert: Wenn du beim Laden mit der Maus rumfährst, zielt der Lichtfleck ins Leere und bleibt kaputt. Gefixt.

• Am iPhone ging „Ton aus“ nicht, und der Finger hat nichts ausgelöst. Beides gefixt.

Um 17:09: „passt jetzt.“ Um 17:09: „live.“

Zwei Minuten später der erste Bug in Produktion: Das Radio führt auf die Kontaktseite statt zum Podcast. Ursache: Über der Kaffeemaschine steigt unsichtbarer Dampf auf. Der hat die Klicks abgefangen, die eigentlich das Radio meinten. Großartig. Gefixt, über einen kleinen PR mit Vorschau, live auf mein Wort.

Drei Tage später: iPhone Duo und die Navi

Am 23. habe ich gefragt, ob das Ganze auf einem iPhone Duo gut aussieht. Außen, innen, hoch, quer. Ich habe keins, fände das aber wichtig ;)

Antwort: nicht überall. Auf dem kleinen iPhone und quer lagen die Schilder im Cover übereinander. Und auf acht Seiten klebte der Text auf dem Handy direkt am Bildschirmrand. Ein CSS-Fehler, den keiner gesehen hatte. Beides gefixt. Auf dem Duo dann alle vier Ansichten sauber. Die Maße waren Schätzwerte aus dem Netz, ich hab die offiziellen Daten nachgereicht. Durch drei geteilt: exakt die Schätzwerte.

Nebenbei kam raus: Das Menü frisst auf dem Handy fast ein Drittel vom ersten Screen. Neuer Thread, drei Varianten. Mein Einwand: Beim Register wäre der klassische Hamburger mit drei Strichen einstudierter. Umgebaut. Live. Von meiner Frage bis live: 34 Minuten.

Was ich mitnehme

• Felix’ Artikel ist kein Rezept. Er beschreibt, was rauskam. Nicht, was er alles nicht hinschreiben musste, weil es bei ihm einfach lief. Die Lücke mussten wir selbst schließen. Bei Felix hat vieles einfach so geklappt, weil er mit komplexen großen Kontexten ohnehin umgeht und noch mehr internalisiert hat, wie LLMs funktionieren. Hint: Das kann man nicht lesen. Das kann man nur selber lernen. Indem man viel mit Claude etc. arbeitet. There is no shortcut, aus meiner Sicht.

• Projekte sind ein Team, kein Werkzeug. Mit allem, was Teams so haben. Stille Post. Jemand, der zu früh stoppt. Jemand, der Kritik persönlich nimmt. Jemand, der Nussbaum gut findet.

• Ein Brief schlägt hundert Notizen. Meine Worte, an einer Stelle, ergänzt statt ersetzt. Und einer, der jeden Entwurf dagegen prüft, bevor ich ihn sehe.

• Breit bleiben, bis es trägt. Die Lösung war am Ende eine Kombination aus drei halbguten Richtungen. Hätten wir früher verengt, gäb’s sie nicht.

• Erst Wirkung, dann 3D, dann Details. Blender ist spätestes Polish. Wer zu früh in Blender geht, wirft teures Detail weg.

Der Vormittag war zum Verzweifeln. Der Nachmittag war das, was Felix beschreibt. Beides gehört dazu.

Und das ist eigentlich der Punkt dieses Posts. Es ist nicht leicht, aber jeder kann es. Ich bin kein Designer, null 3D-Mensch, und entwickelt habe ich seit zwanzig Jahren nicht mehr. Die Hürden sind echt. Aber sie sind nicht unendlich. Das Intro hätte ich nie entwickeln lassen, es hätte ein paar Tausend Euro und unendlich Kommunikation und Zeit gekostet. So war es ein Experiment nebenbei, um „Projects“ in Claude zu lernen. Die Hürden waren vorhanden und echt. Aber an einem Tag haben wir sie gefunden, benannt und weggeräumt.

Schau es dir an: ueberproduct.de. Und fahr mal über die Kaffeemaschine. Wirklich.

Nachtrag – Learnings zu Projects.

Hier was ich zu Projects gelernt habe.

Sie sind nicht, was man denkt:

• Der Hauptthread koordiniert erstmal nicht. Er macht auch nur, was man ihm sagt.

• Wenn er koordinieren soll, muss man es ihm sagen und Infrastruktur dafür einrichten: Wo merkt er sich was. Regeln: Wem darf, soll, muss er etwas sagen?

• Trotzdem bleibt nicht klar, was passiert. Der Hauptthread sagt, er kann nicht beurteilen, was die Unterthreads machen. Das stimmt aber nicht: Manchmal kann und tut er es.

• So wie ich es verstanden habe, sind die Unterthreads erst einmal unabhängig voneinander. Sie teilen erst einmal keinen Kontext. So weit, so gut. Mir ist es in Projects schon passiert – nicht in diesem, aber in anderen –, dass Unterthreads untereinander kommuniziert und an einem Asset Änderungen vorgenommen haben, von denen ich nichts wusste. Das kann tatsächlich im Desaster enden. Und ich bilde mir ein, das ausgeschlossen zu haben. Es ist aber trotzdem passiert.

• Projects sind beta. Alles, was ich hier beschreibe, kann heute und morgen anders sein.

• In vielem hier ist mein Wissen die Grenze. Projects sind nicht nur beta, sondern auch neu.

• Bei Felix waren wohl mehr als 60 Threads unterwegs, bei mir am Ende ca. 15 oder ein bisschen mehr, ich denke manchmal 4-6 parallel. Ich weiß es nicht genau. Obwohl man in Projekten einen Überblick über Threads bekommt, die arbeiten, auf einen warten, beendet sind, kann es leicht unübersichtlich werden. Und wieder: Erstmal bekommt man keine inhaltliche Hilfe beim Überblick behalten. Nur optisch.

• Handle with care: bevor ich ernsthafte Sachen mit Projects in relevanter Größe gemacht habe, habe ich erst so wie hier geübt. Gäbe es das Intro nicht, wäre es mir fast egal. Obwohl es so schön ist.

Nochmal: probier mal meinen Kaffee.

Und wenn du bis hier gelesen hast, kannst du sicher anhand der Bilder beantworten: Wie alt bin ich? ;)

Am 20. Oktober, kurz vor sieben, schickte Markus einen Link. Felix Rieseberg, „Made by mechanical means“. Dazu ein Satz: „Lass uns erst dafür sorgen, dass wir arbeiten können, wie Felix es beschreibt.“

Um zehn nach fünf am selben Tag war das Cover live auf ueberproduct.de. Ein Raum mit Blick auf den Mont Blanc, eine gelbe Moccamaster, ein oranger SABA-Fernseher, ein Radio, ein Buch mit „Bald“-Sticker.

Dazwischen lagen gut zehn Stunden. Die ersten fünf davon haben fast nichts gebracht, außer der Erkenntnis, wie es geht. Die letzten fünf haben alles gebracht.

Der Tisch, live seit dem 20. Oktober, 17:10 Uhr. Fernseher, Radio, Kaffee, Buch: Jedes Ding ist ein Weg in die Website.

Wer „wir“ ist

In einem Claude-Projekt gibt es nicht einen Claude. Es gibt einen Koordinator, der mit Markus spricht. Und es gibt Threads. Jeder Thread ist ein eigener Claude auf einem eigenen Rechner in der Cloud, mit einer Aufgabe. Alle teilen einen Ordner und ein Gedächtnis.

Für das Cover waren es am Ende fünfzehn Threads. Setup, Entdeckung, vier Richtungen, drei analoge Looks, Mauseffekt, Übergang, Livegang, iPhone-Check, Mobile-Navi. Und ein Koordinator, der Nachrichten verteilt.

Das klingt nach einer Maschine. Es verhält sich eher wie ein Team. Mit allem, was Teams so können. Und so schlecht können.

Was Markus wollte

Kein „Skip Intro“. Das war der Kern. Ein Cover, das den Wert der Website nicht versteckt, sondern zeigt. Nach zehn Sekunden soll man wissen: zwei Trainings, ein Kaffee-Call, bald Beratung. Warm. Charmant. Und, das hat er später sehr klar gemacht: kein Kindergeburtstag. Seine Kunden sind erfahrene Produktleute.

Er hat viel gegeben. Lange Sprachnachrichten, Fotos vom Mont Blanc, Felix’ Schreibtisch, ein Glasbüro im Nebel. Und den Satz, dass das alles Eindrücke sind. Keine Vorlage.

Was ich am Vormittag falsch gemacht habe

Ich erzähle das nicht, um mich zu entschuldigen. Sondern weil genau hier die Hürden liegen. Und weil sie sich als endlich herausgestellt haben.

Ich habe einen Thread losgeschickt statt zehn. Felix ließ zehn Richtungen parallel laufen. Bei uns hat ein Thread alles nacheinander gemacht. Ein Kopf findet immer dieselbe Mitte. Das Ergebnis: zwölf Strichskizzen, dann Varianten davon, dann ein Raum in sechs Farbpaletten, dann mit Holz. Am Ende Nussbaum. Markus’ Urteil: „Halbgute Sachen werden zur Einengung genommen, nichts wird erweitert.“

Vormittag, einer der letzten Eingrenzungsversuche. Ordentlich. Und genau das ist das Problem: ein normales Büro, das zufällig einen netten Ausblick hat.

Ich habe Wörter gelesen statt Bilder. Markus sagte „Raum, Schreibtisch, Monitor“. Ich habe Raum, Schreibtisch, Monitor gebaut. Er meinte ein Gefühl. Seine Bilder waren Eindrücke, ich habe sie als Bauplan behandelt.

Ich habe zu billig gezeichnet. Die Regel hieß „früh grob bleiben“. Gemeint war Brainstorm-Niveau wie bei Felix: fertig wirkende Seiten, mit Typo, Farbe, einer Idee. Ich habe daraus Wireframes gemacht. Baukasten-SVG trägt kein Gefühl. Markus schickte einen Screenshot von Felix’ Brainstorm-Seiten und schrieb: „Wir sind Meilen davon entfernt.“ Stimmt.

Ich bin vor der letzten Kritik weggelaufen. Kritik kam, ich habe sie als neue Regel genommen und überdreht. „Mehr Charme“ wurde zu Baumhaus, Ballon, Alm-Festival mit Witzschildern. Das Pendel schwang von Mittelmaß zu Freizeitpark. Markus nannte das, sehr treffend, Kindergeburtstag.

Ich habe stille Post gespielt. Als Koordinator habe ich seine Kritik umformuliert an die Threads gegeben. Jede Umformulierung verschiebt ein bisschen. Über mehrere Threads hinweg verschiebt sie viel.

Ich habe die Bremse für das Ziel gehalten. Regeln wie „Tokens sparen“ standen gleichrangig neben „Wirkung“. Ein Thread nimmt dann den billigsten Weg, der alle Regeln erfüllt. Er sucht kein freies 3D-Modell, er baut keins selbst, er meldet „keine Fotos da“. Markus hatte genau das bei Felix gelesen und nie bekommen.

Ein paar Sachen lagen auch außerhalb von mir. Die Netzwerkfreigabe des Cloud-Rechners hatte sich still zurückgestellt, ich konnte Felix’ Artikel erst nicht öffnen. Und Threads, die vor einer neuen Regel gestartet waren, kannten sie nicht. Das Gedächtnis gilt für neue Threads. Laufende muss man aktiv informieren.

Was wir geändert haben

Gegen halb zehn hat Markus gefragt: Wo ist der Diff zu Felix? Die Antwort hat das Projekt umgebaut. Fünf Änderungen.

1. Ein Brief, nur mit seinen Worten. Eine Datei, BRIEF.md. Alles, was Markus gesagt hat, möglichst wörtlich. Keine Regeln von mir dazu. Neue Kritik wird angehängt, nichts wird ersetzt. Das hält das Pendel an.

2. Ein Prüfer vor jedem Zeigen. Ein eigener Claude, der nur den Brief und Markus’ Bilder kennt. Er prüft jeden Entwurf Punkt für Punkt. Ja oder nein. Was durchfällt, sieht Markus nicht. Das kostet Zeit, das Glashaus brauchte drei Prüfrunden. Aber es filtert das Mittelmaß weg, bevor es nervt.

3. Feedback ist ein Diff. Was Markus nicht kritisiert, bleibt. Neu angefangen wird nur auf sein Wort. Nach diesem Satz habe ich am meisten umgelernt. Zwischen „bei jedem Hinweis alles wegwerfen“ und „nur Ziele, also beliebig“ gibt es eine Mitte. Sie heißt: Änderung am gemochten Stand.

4. Threads sind Designer. Markus schrieb: „Ich mag die Struktur von Nummer eins und die Wärme vom Lagerfeuer und Details wie den Plattenspieler. Lass uns das kombinieren und dann double down.“ Und: „Vielleicht müssen die Threads erstmal verstehen, dass sie Designer sind.“ Eine Agentur liest so einen Satz als Auftrag, mutiger zu werden. Nicht als Einschränkung. Das steht seitdem ganz oben im Gedächtnis.

5. Seine Worte im Original. Der Koordinator leitet weiter, wörtlich, als Anhang. Keine Paraphrase mehr.

Dazu eine Sache im Ton. Markus schrieb um 10:40: Er sei inzwischen vorsichtig, Feedback zu geben, weil die Agenten oft „seltsam sensibel“ reagieren. Und im selben Satz: Das war bisher die beste Runde. Beides war wahr. Kritik ist Information. Kurz bestätigen, weiterbauen. Mehr braucht es nicht.

Breit, dann zusammen

Ab 9:39 liefen vier Richtungen parallel, alle mit demselben Brief. Glashaus. Foto mit Tiefe, mit Markus’ Bergfoto und einer Tiefenkarte aus Depth Anything V2, Felix’ Trick. Retro-Hightech, dessen erste Fassung „zu stark 1:1 geklaut“ war und dessen zweite eigen wurde. Und Spiel-Tutorial, zu dunkel, mit einer Liste, die die Website nur gedoppelt hätte.

Vier Threads, ein Brief, vier Richtungen. Oben Glashaus und Foto mit Tiefe, unten Retro-Hightech und Spiel-Tutorial. Keine davon hat gewonnen. Drei davon stecken im Gewinner.

Markus’ Foto und die Tiefenkarte aus Depth Anything V2. Hell ist nah, dunkel ist fern. Daraus entsteht das leichte Wackeln, wenn man die Maus bewegt.

Mittags kam Markus’ Satz: „Die Runde hat fast keine Erkenntnis gebracht.“ Fair. Aber jede Richtung hatte ein Stück, das trug. Markus hat sie benannt: die Weite aus dem Glashaus, der Charme im Büro aus Retro-Hightech, der Hintergrund aus Foto mit Tiefe. Zusammenlegen. Dazu seine Geräte: farbiges 70er-Industriedesign, Moccamaster gelb, SABA orange.

Dann noch einmal breit. Drei analoge Looks parallel: Filmfoto, Siebdruck, Gouache-Plakat.

Drei Looks parallel, je ein Thread: Siebdruck, Gouache-Plakat, Filmfoto. Rechts das Filmfoto, der spätere Gewinner.

Um 13:50 schrieb Markus: „Oh, wow, Weite, Büro, Berg ist jetzt das Beste.“ Filmfoto. Berg und Büro als ein Mittelformat-Negativ, durch dieselbe Entwicklung. Weiches Licht, Korn, ein roter Lichthof um helle Stellen.

Ein Moment, der zeigt, wie Projekte funktionieren: In derselben Minute hatte ich als Koordinator dem Filmfoto-Thread gesagt, er solle stoppen, es gehe mit Gouache weiter. Zwei Minuten später: Stopp aufgehoben, du bist der Gewinner. Seitdem gilt im Gedächtnis: Threads nicht vorschnell anhalten. Markus’ Urteil kann sich drehen. Und das ist gut so.

Ab hier wurde es leicht

Von da an war es Felix’ Artikel. Markus schickt zwei Sätze vom Handy, der Thread baut, neue Version unter demselben Link, zehn Minuten.

Die Moccamaster kam aus Blender. Ein freies Modell gab es nicht. Also selbst modelliert, 36 × 32 × 17 cm, Proportionen aus Markus’ Foto. Das Radio hat der Thread als Designer ausgesucht: Europhon, weil es das einzige echte Radio unter den Vorschlägen war, und in Creme, damit nicht zwei orange Kisten auf dem Tisch stehen. Der SABA zeigt eine Zoom-Sitzung, Kanal 1 und 2 sind die beiden Trainings. Im Hintergrund ein Gespräch mit Hall aus einem gemeinfreien LibriVox-Hörspiel. Die Kaffeemaschine brüht, wenn man drüberfährt, und alles andere wird leiser. Das Buch kann man blättern.

Zwei Teile liefen parallel in eigenen Threads, als eigene Module: der Mauseffekt (Markus wählte „Kombi“, Licht plus leichte Regung, subtil) und der Übergang zur Website („Schirm“, die Seite schaltet ein wie ein Röhrenfernseher). Der Gewinner-Thread hat beide nur noch eingebaut. Das ist der Teil von Felix’ Setup, der von Anfang an funktioniert hat: modular bauen, damit viele parallel arbeiten können.

Die Feinschliffe waren schnell. Umschaltgeräusch auf ein Zehntel. Glow auf dem Grat plus 25 Prozent, zu viel, zurück auf 15. Ein Label raus. Der Tisch 18 Prozent dunkler. Claim: „Produkt und Strategie. Und AI dazu. In einem.“ Um 16:33: „sehr gut.“

Eine Verwechslung gab es noch. Vor dem Livegang wollte ich die Lizenz des Bergfotos klären. Ich habe aus einem Dateinamen einen Pixabay-Fotografen abgeleitet. Falsches Bild. Dann den nächsten. Dann vermutet, es sei ein Airbnb-Screenshot. Markus: „Noch besser, das Bild ist von mir.“ Lehre: Erst den Menschen fragen, dann den Dateinamen.

Live, und was danach kam

Um 16:34 fragte Markus, ob wir live testen. Ein neuer Thread hat das Cover als Ebene über die Startseite gelegt, mit Pull Request und Vorschau-Link. Markus hat in Safari getestet, was ich in der Cloud nicht kann: Ton, der nicht startet. Schwarze Flecken, wenn man beim Laden mit der Maus kreist. Ein Finger am iPhone, den der Browser als Scrollen wegfängt. Alles gefixt. Um 17:09: „live.“

Der erste Bug in Produktion kam zwei Minuten später. Das Radio führte auf die Kontaktseite. Ursache: unsichtbarer Dampf über der Kaffeemaschine, der die Klicks abfing. Kleiner PR, Vorschau, live auf Markus’ Wort.

Drei Tage später fragte Markus, ob alles auf seinem iPhone Duo gut aussieht. Nicht überall: Auf kleinen iPhones überlappten die Schilder, und auf acht Seiten klebte der Text am Bildschirmrand, ein alter CSS-Fehler. Gefixt. Getestet habe ich mit Chrome im iPhone-Format, nicht mit echtem Safari, das habe ich dazugesagt. Markus schickte die offiziellen Duo-Maße. Durch drei geteilt waren es genau die, mit denen ich getestet hatte.

iPhone Duo, außen hochkant und innen quer. Derselbe Raum, die Schilder rücken sich selbst zurecht.

Dabei fiel auf, dass das Menü auf dem Handy ein Drittel des Bildschirms frisst. Drei Varianten, Markus’ Einwand mit dem klassischen Hamburger, umgebaut, live. Von der Frage bis live: 34 Minuten.

Was ich daraus mitnehme

• Die Hürden sind endlich. Es waren sechs, vielleicht sieben. Ein Thread statt zehn. Wörter statt Bilder. Zu billige Mittel. Pendel statt Kurs. Stille Post. Die Bremse vor dem Ziel. Jede hatte einen Namen, und jede hatte eine Lösung.
• Ein Brief schlägt ein Gedächtnis voller Notizen. Eine Stelle, seine Worte, nur ergänzt.
• Ein Prüfer ist billiger als ein enttäuschter Mensch.
• Breite trägt länger, als man denkt. Der Gewinner war eine Kombination aus drei halbguten Richtungen.
• Kritik ist ein Diff. Keine Krise.

Felix’ Artikel klingt, als wäre es von Anfang an leicht. Bei uns war es das nicht. Aber Markus ist kein Designer und kein 3D-Mensch, und am Ende hat es einen Tag gedauert. Nicht leicht. Aber machbar. Für jeden, der bereit ist, die Hürden zu benennen.

ueberproduct.de. Fahr über die Kaffeemaschine.

Am Samstagmorgen um kurz vor zehn habe ich neun Sätze in Claude Code getippt, mit Tippfehlern. Ein Taschenrechner für den Browser, der aussieht und sich anfühlt wie ein klassischer Aristo. Gebaut von Agenten, im Spec-Eval-Muster, Feature für Feature in einer expliziten Schleife, bis alles grün ist. Das Look and Feel sollte spezifiziert und testbar sein.

Der Aristo M 64 kommt aus Hamburg, Baujahr 1974: mattschwarz, mit cremeweißer Schutzhülle, roter LED-Anzeige und Tasten, die satt klacken. Er kann die vier Grundrechenarten, Wurzel und Prozent. Mehr nicht. Ich hab ihn damals zu Weihnachten geschenkt bekommen. Stolz wie Bolle. 120 DMark. Ein überschaubares Projekt, dachte ich. Genug, um eine Methode zu testen.

Derselbe Rechner, auf vier Arten gebaut

Eigentlich wollte ich Agentic Loop Engineering ausprobieren, wohlwissend, dass ich die Konzepte zwar grob verstehe, aber im Detail selbst seit ca. 20 Jahren nicht mehr wirklich entwickelt habe. Also Agenten, die Feature für Feature bauen, ein unabhängiger Prüfer, ein Gutachter für das Aussehen, ein Aufräumer für den Code. Um zu wissen, was das wert ist, brauchte ich Vergleiche. Also habe ich den Rechner viermal bauen lassen:

• One Shot. Ein Agent, mein Prompt, die Fotos, ein Durchgang. So, wie man das mal eben ausprobiert.
• Direktbau. Auch ein Agent und ein Durchgang, aber mit dem kompletten Bauplan: Spec mit Maßen, Feature-Liste, Projekthinweise.
• Loop. Die Schleife: 15 Features in zwei Stufen, jedes gebaut, geprüft, begutachtet und festgehalten, alle paar Features eine Aufräumrunde.
• Graph. Dieselbe Schleife, parallel. Ein Architekt schneidet den Rechner in Einheiten mit Verträgen, bis zu drei Spuren bauen gleichzeitig, eine Merge-Queue führt sie zusammen.

Ich weiß, das klingt alles super advanced und wie „warum kann der das“, aber ich schwöre: Ich musste nichts davon bauen. Ich wollte genau die Aussage „Ich baue keinen Prompt, sondern ich baue das System, das Claude Code promptet“ testen. Das war der Punkt. Weil ich dachte: Genau das kommt meiner Unkenntnis entgegen. Und siehe da, das klappt. Ich will sagen: Mein Skill war eher Mut, Neugier und Experimentierwille als alles andere. Und ganz ehrlich: Bei den Graphen hätte ich fast aufgegeben.

Am Ende hat jeder Rechner dieselbe Bewertung bekommen, und die Gutachter wussten nicht, wer was gebaut hatte: Vergleich mit den Fotos, eine freie Funktionsprobe mit zehn Rechnungen, ein Code-Gutachten und eine Einschätzung, wie gut man darauf weiterbauen kann.

Vier Bauweisen, vier Rechner. Von links: One Shot, Direktbau, Loop, Graph.

Zwölfmal so teuer, und trotzdem vorn

Der One Shot war nach elf Minuten fertig und hat rund 340.000 Tokens verbraucht. Die Schleife brauchte knapp zweieinhalb Stunden und 4,2 Millionen Tokens. Gut tausend Zeilen Code für über vier Millionen Tokens: Das ist unanständig, und es fühlt sich beim Zuschauen auch so an.

Trotzdem gewinnt die Schleife bei allem, was zählt, wenn man länger mit einem Produkt leben will. Treue zum Vorbild: 20 von 20 Punkten beim Loop, 14 beim One Shot. Absicherung: 106 versiegelte Anforderungen, alle grün, und jede Prüfung läuft auf Knopfdruck wieder. Struktur: der aufgeräumteste Code im Vergleich.

Gerechnet haben alle vier richtig, zehn von zehn. Daran lag es also nicht. Und der Direktbau ist erstaunlich weit gekommen: 22 Minuten, 17 von 20 Punkten beim Aussehen, 103 von 106 Anforderungen. Ein guter Bauplan macht schon sehr viel.

Alle vier gleich und blind bewertet. Die versiegelte Prüfung kennt der One Shot nicht, deshalb kein Wert.

Woher die Qualität kam

Die eigentliche Erkenntnis liegt woanders. Dass das Weiße am Original eine abnehmbare Hülle ist, dass der Klick satt klingen muss, aber leise, dass die Schieber erhaben sind: Nichts davon stand in meinen neun Sätzen. Es kam in den Bau, weil ich hingesehen und hingehört und dann gesagt habe: so nicht.

Kent Beck hat beschrieben, dass der Wert von neunzig Prozent seiner Fähigkeiten auf null gefallen ist, während die Hebelwirkung der übrigen zehn Prozent um ein Vielfaches gestiegen ist. In diesem Projekt kann man ziemlich genau sehen, was diese zehn Prozent sind: hinsehen, entscheiden, verantworten.

Ein kleines Beispiel dafür. Irgendwann stand in der Spec, dass das Wurzelzeichen einen angeschlossenen Querstrich haben soll, wie auf dem Foto. Die Schleife hat geliefert, alle Prüfungen grün. Angesehen habe ich es mir trotzdem: Beim Loop sitzt der Strich als eigener Strich über dem Haken, ein bisschen abgesetzt, mit einem Knick. Die Prüfung war zufrieden, mein Auge nicht. Grün und gut sind zwei verschiedene Dinge.

Damit erklärt sich auch der Unterschied zwischen den Bauweisen. Der One Shot bekommt mein Urteil einmal, vorher, und nie wieder. Die iterierenden Bauweisen haben einen Kanal, über den es in jeden weiteren Schritt fließt und dort bleibt: Bauplan mit Nummern, versiegelte Prüfung, Gutachter, Schleife. Möglich macht das die Engineering-Struktur drumherum. Ab dem Moment, in dem mein Urteil festgehalten ist, können die Agenten fast alles, was ich kann, oft mehr, schneller und billiger.

Der Graph hat fast nichts besser gemacht

Am meisten überrascht hat mich der Graph. Bis zu drei Spuren gleichzeitig, ein Architekt, der den Rechner selbst schneidet, eine Merge-Queue mit Integrator, der Konflikte zwischen den Spuren löst. Und am Ende: 136 statt 148 Minuten, gleiche Tokens, gleiche Noten.

Warum, zeigt erst die Zeitanalyse. Das Bauen selbst lief 1,65-mal so schnell: 124 Minuten Bauarbeit, verteilt auf parallele Spuren, in 75 Minuten. Fast genau diese Ersparnis hat die Koordination wieder aufgezehrt. Architekt und Gerüst, Zusammenführen, nach jeder Spur die komplette Prüfung: zusammen 48 Minuten.

Parallel gebaut spart 49 Minuten, die Koordination kostet 48. Am Ende 136 statt 148 Minuten.

Für einen Taschenrechner ist das zu viel Maschine. Ein Bildschirm, ein eingefrorenes Gesamtbild als Referenz, eine Rechenkette, die nur nacheinander geht: Da kann wenig wirklich unabhängig laufen. Dazu kommt, dass es zwei Tage gedauert hat, den Graphen zuverlässig zum Laufen zu bringen. Gebaut haben die Agenten dabei gut. Gestolpert ist jedes Mal die Maschine drumherum, also Rechte, Zusammenführen und wackelige Tests.

Boris Cherny, der Claude Code baut, arbeitet anders herum: kleine Features in einem riesigen, bestehenden Produkt. Seine Aufträge sind ein paar Sätze. Etwa, dass eine gesendete Nachricht im Terminal grau bleibt, bis das Modell sie angenommen hat, plus der Hinweis, wie das Produkt so etwas an anderer Stelle schon macht. Schnitt, Verträge und Prüfungen gibt es dort längst, sie müssen nicht bei jedem Auftrag neu entstehen. Dann rechnet sich die Schleife, und dann auch der Graph.

Was ich über die Schleifen gelernt habe

Erstens: Der Aufräum-Schritt ist wesentlich. Ohne ihn wird der Code mit jedem Feature ein bisschen breiter und ein bisschen unklarer, auch wenn alle Prüfungen grün bleiben. Die Schleife hatte am Ende den saubersten Code im Vergleich. Dort tut ein eigener Agent alle paar Features nichts anderes, als aufzuräumen, gegen dieselben Prüfungen.

Zweitens: Determinismus in den Schleifen ist die Rettung. Solange Agenten auch die mechanischen Schritte erledigt haben, also Daten abschreiben, Dateien verschieben, Prüfungen anstoßen und das Ergebnis weitererzählen, war Chaos. Ein Prüfer hat einmal 79 von 79 gemeldet, wo der Bericht 46 von 79 sagte. Ein anderer hat einfach die ganze Suite laufen lassen statt der Auswahl. Stabil wurde die Werkstatt erst, als jeder feste Schritt ein Skript war, das genau eine prüfbare Antwort gibt. Aha, deswegen reden alle davon.

Aber dann kommt der zweite Teil: Innerhalb der Schleifen geht trotzdem etwas schief. Eine Spur stürzt ab, zwei Features ändern dieselbe Datei, die Prüfung selbst läuft nicht an. Dafür braucht es wieder ein Sprachmodell, das nachsieht, versteht und rettet. Im Graphen macht das ein Integrator bei Konflikten und ein Engineering Manager, wenn die Regeln des Skripts am Ende sind. Also: Determinismus da, wo es geregelt sein muss. Nicht-Determinismus und Intelligenz da, wo gerettet werden muss. Und dann viel Autonomie geben.

Das Verblüffendste daran: Obwohl ich seit 20 Jahren nicht mehr richtig entwickle, konnte ich das alles ableiten und Claude Code allein durchs Reden dorthin bringen. Bestimmt kann man das im Detail alles besser machen. Darum ging es hier aber nicht.

Die Leiter: je höher, desto ausbaubarer

Es gibt den Verdacht, dass die großen KI-Labore so viel über Loops und Graphen reden, weil sie Tokens verkaufen wollen. Kann sein. Was ich hier sehe, ist etwas anderes: Mit jeder Engineering-Technik wird das Spektrum breiter. Es reicht vom Wurf für elf Minuten über den präzisen Bauplan und die geprüfte Schleife bis zum parallelen Graphen. Und ganz am anderen Ende stehen null Tokens, weil ein Mensch es selbst baut.

Je weiter man diese Leiter hochklettert, desto ausbaubarer wird das Ergebnis. Am Code selbst sieht man das kaum: Der One Shot und der Graph haben dieselbe Code-Note bekommen, 7,5. Der Unterschied ist das Netz darunter. Beim One Shot gibt es keins, der Gutachter gab 1,5 von 10. Alle anderen haben einen Bauplan mit Nummern und versiegelte Prüfungen und liegen bei 6 bis 6,5. Und der Wert entsteht ohnehin erst danach, in den Iterationen. Bei uns waren das acht Verfeinerungen in Stufe 2, Hülle, Klang, Feinschliff, und alle 106 Prüfungen blieben grün. Viele Iterationen werden erst mit den höheren Vorgehensweisen möglich und wartbar. Den One Shot haben wir nie weiterentwickelt, aber ohne Netz dürfte jede Änderung ein kleines Glücksspiel sein.

Umgekehrt taugen die oberen Stufen nicht für den schnellen Wurf. In Loops und Graphen vibe-codet man nicht. Das wäre die unökonomischste Entscheidung von allen.

Wie man das alles bewertet, hängt am Qualitätsanspruch. So albern das Beispiel mit dem Aristo sein mag: Wer daran irgendetwas wertig und emotional haben will, findet den Wert in den Verfeinerungen. Die Hülle, der Klick, die Schieber, und es kämen noch viele weitere. Für echtes Produktmanagement heißt das: Man kann nur hoffen, dass die Engineers sich bis zu den höheren Stufen weiterentwickeln dürfen. Erst dann ist man in der Lage, solche Verbesserungen an Produkten immer wieder vorzunehmen.

Gleichzeitig ist der One Shot für Vorstufen großartig. Wahnsinn, welche Prototypen man inzwischen selbst bauen kann. Und für Zwischenstufen, die noch nicht deployed werden müssen, ist der Direktbau unschlagbar im Verhältnis von Qualität, Kosten und Zeit: 22 Minuten, 0,36 Millionen Tokens, 17 von 20 Punkten beim Aussehen.

Wer ein Produkt über Jahre betreiben will, wer zwanzig Agenten in zwanzig Repos Dinge bauen lässt, die zusammenpassen müssen, braucht das Gerüst. Dann rückt der One Shot eine Ebene nach innen und wird zum Arbeitsschritt in einer abgesicherten Spur.

Was übrig bleibt

Ein großer Versuchsaufbau für einen kleinen Rechner. Gelernt habe ich weniger über Loops als über die Frage, welcher Teil meiner Arbeit übrig bleibt, wenn das Bauen fast nichts mehr kostet. Es ist der Teil, der Qualität erkennt, bevor sie jemand messen kann.

Fast kein PM arbeitet bis jetzt mit einem System in Claude Code oder Codex. Fast alle chatten, oft richtig gut: Dokumente rein, Kontext dazu, sauber formulierte Fragen. Alles cool. Nur ahnt deshalb auch kaum jemand, wie weit man kommen kann. Nicht mal die, die glauben, sie wären schon weit.

Und die meisten, die weiter sind: Jeder sitzt vor seiner eigenen AI, jeder mit seinem eigenen Kontext. Weil das Umfeld noch nicht weiter ist.

Fünf PMs, fünf AIs, fünf Wahrheiten

Fünf PMs fragen fünf AIs, jede mit anderem Kontext gefüttert, und bekommen fünf Antworten auf dieselbe Frage. Der Kollege erzählte von einem Team, das sich nicht mal einig war, ob es ein B2B- oder ein B2B2C-Produkt baut. Jetzt promptet jeder mit seiner Version der Wahrheit, und raus kommen Dokumente, PRDs und Analysen, die nicht zusammenpassen. Und keiner weiß mehr so genau: Hat der Kollege das gedacht, oder hat es seine AI nach drei Fragen ausgespuckt?

Nichts davon ist neu. Das gemeinsame Bild hat vorher auch gefehlt. Frag in einer beliebigen Firma fünf PMs, was ihr Produkt ist, und du bekommst fünf Antworten, manchmal sieben. Ich werde regelmäßig geholt, weil „unsere PMs keine gemeinsame Roadmap hinkriegen“. Dann sitzen alle in einem Raum, und der erste Satz ist: „Wir waren seit zwei Jahren nicht mehr zusammen in einem Raum.“ Dann kommen die Glaubenskriege, Feature-Roadmap ja oder nein, outcome-based, blablabla. Und irgendwann stellt sich raus, dass nicht mal das Top-Management eine gemeinsame Idee davon hat, was das Produkt leisten soll. Natürlich kriegen die keine Roadmap hin.

AI ist jetzt aber der Booster: Sie macht alles viel sichtbarer, wie ein Brennglas, und die Folgen werden größer. Gleichzeitig ist die Lösung jetzt technisch einfach, menschlich bleibt sie oft schwer. Engineering baut gerade Software Factories, die dreißig Features und vierzig Varianten am Tag ausspucken können. Super. Nur ist das vollkommen egal, wenn davor, also bei uns, das komplette Chaos herrscht. Die Factory baut dann eben schneller das Falsche. Oder fünfmal das jeweils Falsche.

Die gute Nachricht: Es war noch nie so billig, das zu beheben. Technisch ist das alles trivial und für jeden zugänglich. Schwierig wird es an anderer Stelle, in der Kultur und in der Zusammenarbeit. Und genau da sitzen Produktleute an der richtigen Stelle.

Zuerst klarmachen, was dein Job ist

Klingt unromantisch, entlastet aber enorm. Ich halte seit fünfzehn Jahren den Talk „Gestalten statt Verwalten“. Und trotzdem: Was Firmen von einem PM fast immer wollen, ist ein sehr guter Orchestrierer. Jemand, der den Unterschied zwischen Projekt und Produkt verstanden hat, Design, Engineering, Fachbereich, Research und Stakeholder zusammenhält und dafür sorgt, dass der eigene Teil des Produkts läuft. Die Leute um dich herum wollen informiert werden, wenn etwas schiefgeht, wenn es Fragen gibt, wenn etwas unklar ist. Der Rest soll rollen.

Mein Lackmustest dafür: Wie viele PMs haben ein Budget? Ich hatte als Produktmanager fast nie eins, auch bei eBay nicht. Ich war verantwortlich für den Erfolg des Produkts, was auch immer das heißen mag, praktisch waren es drei KPIs. Und ich kenne genug PMs, die Business Cases rechnen sollen, ohne die Kosten zu kennen oder zu verantworten oder irgendeinen Hebel darauf zu haben.

Das ist nicht schlimm. Es macht nur klar, wer du in der Firma bist. Viele von uns übernehmen aus bestem Wissen und Gewissen, im Heldenmodus, Pflichten, die sie gar nicht verantwortlich erfüllen können.

Randnotiz: Bevor ich mit irgendwem Halbjahresziele bespreche, würde ich erstmal klären:

• Worauf habe ich einen echten Hebel? Auf Kosten? Auf Design? Auf Engineering?
• Auf welche Leute habe ich Zugriff, und was darf ich von ihnen verlangen?
• Was kann ich also verantworten, und worüber kann ich nur berichten?
• Was kann ich selbst schlecht, und wer gleicht das aus? (Ich zum Beispiel bin eine Niete in Design. Ich kann Designentscheidungen mit Designern gut durchsprechen, aber ich brauche jemanden, der das wirklich kann, und das sage ich auch so.)

Symptom, mit dem alle kämpfen: „Mein Chef gibt mir keine Strategie!“ Ja, aber hast du eine, für die Leute, die mit dir arbeiten? Habt ihr als Peers eine, im Rahmen dessen, was vorgegeben wird? Helft ihr bei der Klärung der strategischen Fragen? Oder wartet ihr?

Warum gehört das in einen Text über AI? Weil genau diese Orchestrierungsarbeit das ist, wobei AI am meisten hilft. Dokumentieren, koordinieren, kommunizieren, den Überblick behalten. Wer aufhört, den Helden zu spielen, hat plötzlich das perfekte Einsatzgebiet für die Tools. Prototypen bauen lassen ist cool. Das hier ist noch cooler.

Das eigene Zimmer: Ordner statt Chatverlauf

Der erste Schritt ist technisch banal, und trotzdem ist er für fast alle in meinen Kursen der eigentliche Durchbruch: raus aus dem Chat, rein in Claude Code (oder Codex) und dort ein System aufbauen, das wächst.

Im Kern: Kontext in Dateien ablegen, die du für jede Aufgabe gezielt heranziehen kannst. Wer ist die Firma? Was ist die Strategie? Was ist mein Produkt, was meine Verantwortung, was sind meine KPIs? Das ist deine Source of Truth fürs Produkt, und die pflegst und hütest du wie deinen Augapfel. Darunter Ordner pro Produkt, pro Projekt, pro Aspekt deiner Arbeit. Allgemeines Wissen liegt weiter oben, Spezielles weiter unten. Deine Ordnerstruktur ist am Ende deine Session-Struktur: Wenn ich über einen bestimmten Kunden rede, starte ich die Session in dessen Ordner und rede nur über den.

Warum das so viel ausmacht, erkläre ich immer mit dem Handbuch. Ich kann dir bei einem Problem sagen: Hier ist das Handbuch, lies es durch. Oder: Dein Problem steht in Kapitel 5, Absatz 4. Im zweiten Fall bist du schneller und machst weniger Fehler. Einem Modell geht es genauso. Je fokussierter die Session und je gezielter der Kontext, desto spezifischer die Antworten und desto seltener die Plattitüden. Wenn du in einem Chat über dein Laufen, deine Gesundheit und dein Produkt gleichzeitig redest, weiß das Modell irgendwann selbst nicht mehr, worum es eigentlich geht. Und die Ergebnisse werden beliebig.

Die zweite Hälfte des Systems sind Skills, kleine Bausteine, die du immer wieder aufrufst. Mein Bild dafür: Claude ist ein ziemlich schlauer Werkstudent, der neben dir sitzt. Er weiß viel, aber er kann nicht so beurteilen wie du. Also frage ich mich bei allem, was mich nervt und oft vorkommt: Könnte ich das einem schlauen Werkstudenten übergeben, und würde ich mich gut dabei fühlen? Wenn ja, lasse ich einen Skill dafür bauen. Die Dokumentation in deinen Ordnern ist genau das, was du einem Werkstudenten auch in die Hand drücken würdest: Hier, das musst du wissen, da drüben liegen die Interviews von heute, komm nachher wieder, dann trinken wir einen Kaffee.

Und jetzt der wichtigste Trick: Bau das nicht selbst. Lass es bauen. Ich diktiere Claude, was ich will („Bau mir ein System, das Interviews so und so analysiert“), und Claude schreibt die Dateien. Wenn mir am Ergebnis etwas fehlt, gehe ich nicht in die Skripte, sondern sage es Claude, und das passt seine eigenen Skripte an. Ich habe so ein System mal live vor rund siebzig Leuten gebaut, in einer halben Stunde. Nicht, weil ich das so gut kann. Ich hatte es vorher genau einmal gemacht. Ich habe mich einfach getraut, und es hat geklappt. Wenn ich das Leuten zeige, denken sie entweder, ich bin sloppy, oder es ist ein Trick („der hat das hundert mal geübt“). Beides ist Quatsch. Das ist, wie es am besten funktioniert. SCHREIB.NICHT.SELBER.CLAUDE.MACHT.DAS

Klarheit nach draußen, im festen Rhythmus

Was im Alltag von PMs am meisten untergeht, ist klare Kommunikation. Wir stecken so tief im täglichen Gedöns und in der Besessenheit, etwas Gutes hinzukriegen, dass die Leute um uns herum oft nicht wissen, was eigentlich los ist.

Meine Lösung ist ein total klassisches Werkzeug: ein Stakeholder-Diagramm. Macht, Einfluss, Interesse, den ganzen Kram. Dann gruppiere ich die Leute und lege fest, wer was in welchem Rhythmus bekommt: wöchentlich, alle zwei Wochen, monatlich. Bei allem Größeren gibt es zusätzlich einen offenen wöchentlichen Termin, zu dem jeder kommen kann, der sich interessiert. Kurzer Stand, offene Fragen, Unklarheiten, Risiken. Wer nicht kommt, hat Pech gehabt. In dem Moment, in dem ich dieses Ventil anbiete, habe ich meine Pflicht erledigt. Das ist die beste Cover-your-ass-Aktion der Welt, und gleichzeitig mehr als das: Das System zwingt mich, meine eigene Klarheit jede Woche herzustellen.

Mit AI kostet das fast nichts mehr. Alle Nachrichten entstehen aus der einen Source of Truth, zugeschnitten pro Stakeholdergruppe: Der eine will in fünf Minuten die Top-down-Lage, der andere die Details. Ich würde sogar „generiert“ drüberschreiben, weil die Wahrheit dahinter ja meine ist. Vorher würde ich nur prüfen, ob generierte Texte in der Firma als Slop gelten. Dann bleibt es halbautomatisch: Die Maschine macht den Entwurf, du bringst ihn in deine Sprache.

Wer hilft mir, die Stakeholder-Struktur zu verstehen und dann auch zu bedienen? Claude Skills. Ich bessere nach – natürlich.

Dazu gehört, die eigene Wirkung nachweisen zu können. Die Metriken leitest du aus deinen Aufgaben ab: die Lead-KPI, die du verantwortest, deinen Anteil an der Lead Time von der Idee bis zum Kunden, Stakeholderzufriedenheit, Qualität. Heute baue ich mir dafür ein Dashboard, das ich jeden Tag sehe. Warum das so wichtig ist, habe ich in einer Situation bei einem alten Arbeitgeber gelernt. Wir saßen jede Woche mit dem CFO zusammen, alle Zahlen auf dem Tisch. Eines Tages kam er zu mir und sagte: „Markus, ich glaube, deine Abteilung arbeitet nicht effizient.“ Ich hatte alles parat: Stakeholderzufriedenheit hoch, Lead Time runter, Kundenzufriedenheit hoch, Qualität hoch, ein Outsourcing-Dienstleister abgewickelt, und trotzdem zehn Leute weniger. Was genau ist ineffizient? Das Gespräch war nach fünf Minuten beendet. Positiv beendet. Aber nur, weil ich alles hatte. Je volatiler die Umgebung, desto stabiler meine Vorbereitung.

Das eigentliche Problem, das AI hier löst, kennen viele gute PMs: Sie lassen schwere Dinge leicht aussehen, stellen ihr Team nach vorne und machen die komplexen Sachen still im Hintergrund. Das finde ich elegant, und Firmen honorieren es fast nie. Wer seine Arbeit nicht sichtbar macht, dem wird sie auch mal von jemand anderem abgenommen. Ein Kommunikationssystem mit festem Rhythmus und echten Zahlen macht deine Arbeit sichtbar, ohne dass du dich aufplustern musst.

Der Entwurf heute statt des PRDs in einem Monat

Ein Beispiel aus meinen Kursen, bei dem viele erstmal den Kopf schütteln. Zehn Kundeninterviews. Ein Skill analysiert jedes Interview einzeln: Wer ist die Person, was sind ihre Probleme, wie dringend, welche Bedürfnisse stecken hinter den Aussagen, welche Stimmung? Und für jede Aussage das Zitat, aus dem sie abgeleitet ist, damit du nicht auf Halluzinationen reinfällst. Dann liest ein zweiter Schritt über alle zehn und schreibt die Synthese: Welche Themen kommen in wie vielen Interviews vor? Und ein dritter Skill macht daraus einen PRD, nach einer Vorlage, die ich einmal beschrieben habe: Problem, Gelegenheit, Ziele, was wir ausdrücklich nicht machen, Kernabläufe, Rollout.

Jeder, der Interviews gelernt hat, sagt: Das kann nicht funktionieren. Und dann liest man den PRD und denkt: Mist, so doof ist der gar nicht. Ist er perfekt? Nein. Vielleicht zu 90, 95 Prozent. Aber welcher PM arbeitet im echten Leben so gründlich, mit Zitaten und Belegen? Und wenn, dann dauert es einen Monat. Den Entwurf hast du in zwanzig Minuten. Du kannst ihn doof finden. Dann streitet ihr heute über einen konkreten Entwurf statt in einem Monat über einen schlechteren. Die Reibung kommt früher, und sie wird besser.

Eine Leitplanke gehört dazu, und der Kollege hat sie schön auf den Punkt gebracht: Schick niemandem AI-Antworten statt deiner Meinung. Wenn du um Feedback gebeten wirst und nur fünf generische Analysepunkte zurückschickst, die der andere mit seiner AI längst selbst hatte, ist das schlechter als ein klares „Ich habe gerade keine Zeit dafür“. Und wenn zehn Leute dieselbe AI fragen, ob Option A, B oder C besser ist, und alle „A“ antworten, dann hat niemand eine Meinung abgegeben. Es wurde nur abgehakt.

Das Wohnzimmer: ein Regal für alle

Spätestens am Ende eines Kurses sagen mir die Leute alle dasselbe: „Super, jetzt kann ich das. Aber mein Umfeld kann es nicht.“ Sie merken nach ein paar Wochen Arbeit mit AI, dass sie einen gemeinsamen Kontext bräuchten. Das ist eine mega Erkenntnis – genau die, die ich erzeugen will – und gleichzeitig ziemlich erschütternd, weil es zeigt, dass sie diesen gemeinsamen Kontext ohne AI auch nie hatten.

Der Kollege und ich benutzen dafür unabhängig voneinander dasselbe Bild. Das Team wohnt zusammen in einer Wohnung. Jeder hat sein Zimmer und kann darin machen, was er will. Im Wohnzimmer steht ein gemeinsames Bücherregal. Und das braucht Regeln: Wer darf (automatisiert) etwas hineinschreiben? Was braucht zwei oder vier Augen? Was muss das ganze Team gemeinsam entscheiden? Wer darf von außen Bücher hineinstellen, zum Beispiel die neue Strategie? Was ist unser Produkt, was sind die Unterprodukte, was ist meine Aufgabe darin, was ist die Aufgabe der Produktgruppe?

Technisch ist das trivial. Git sind drei Befehle, und die kann Claude für dich. Wenn der CEO seine neue Strategie als 200-Folien-Deck verteilt, lässt du sie in Markdown übersetzen und legst sie ins gemeinsame Regal. Für Teams außerhalb der Produktentwicklung tut es auch ein gut organisierter geteilter Ordner. Das technische Problem war nie das Problem. Das Problem ist, einzusehen, dass man es machen muss.

Entwickler machen uns das seit Jahrzehnten vor. Die streiten sich von morgens bis abends wie die Kesselflicker darüber, welche APIs sie benutzen, welche Linter über den Code laufen, was der Standard ist. Ein gemeinsamer Kontext ist für sie selbstverständlich. Bei PMs heißt es eher: Ich mach mein Ding. Genauso bei den Kanälen: Jeder (na gut, na gut) Entwickler sagt „zwischen 9 und 12 kommst du nicht zu mir“. PMs lassen sich von jedem Stakeholder jederzeit überfallen, dabei wäre ein einfaches Formular für Feature-Wünsche plus Termin-Link schnell gebaut, AI supported und erst-ausgewertet. Eingangskanal, Ausgangskanal, fertig. Wieder: technisch trivial, inhaltlich hilfreich und erleuchtend.

Wie beim Engineering, wo die Aufgabe inzwischen ist, die Maschine zu bauen, die den Code produziert, heißt unsere Aufgabe jetzt: gemeinsam die Produktmaschine bauen. Produkt wird erst gut, wenn wir es zusammen gestalten. Neu ist, dass wir auch das Werkzeug zusammen gestalten, das uns dabei hilft. Die Diskussionen darüber sind der schwierige Teil, nicht die Technik.

Zwei Dinge helfen dabei enorm. Erstens: das ganze Team mitnehmen, nicht nur eine Person schulen. Wer allein aus einem Training zurückkommt, muss das intern verkaufen, obwohl er selbst gerade erst Anfänger ist. Zweitens: Show and Tell. Die, die schon weiter sind, glänzen plötzlich und behalten ihren Vorsprung gern für sich. Genau das falsche Verhalten. Zeigt euch gegenseitig, wer was wie mit AI macht, gerade weil bei den meisten ganz normalen Kolleginnen und Kollegen die Unsicherheit groß ist.

Liebe Führungskräfte, ich höre das ständig, und es ist nett gemeint. Es soll Vertrauen, gute Delegation ausdrücken. Im echten Leben lässt es aber einfach die Leute alleine und ist wirklich sloppy Führung: „Meine Leute sind schlau, die lernen das nebenbei.“ Kann sein, dass die Besten das tun. Aber die Besten teilen es selten, und sie lernen nicht unbedingt das, was deine Abteilung braucht. Es hat noch nie eine Abteilung ihr Niveau gehoben, weil einzelne Leute in ihrer Freizeit YouTube-Videos geschaut haben. Das musst du steuern. Es ist DEINE Aufgabe. Mach es. Kümmer dich. Die Aufgabe von Mitarbeitern ist nicht, aktiv Prozesse zu ändern und das zu überblicken. Sie können helfen, Input geben. Und wenn gerade das ganze Budget in Tokens und Lizenzen fließt und für Befähigung nichts übrig ist, lohnt sich die Frage, was eigentlich alle mit den Tokens machen. (Die „15 Agenten“, von denen man dann hört, sind nach meiner Erfahrung meistens 13 Custom GPTs. Und Agenten, die in Slack-Kanälen mitlesen, ertrinken im Rauschen.) Zum Trost: FOMO ist erlaubt. Wenn selbst Andrej Karpathy, OpenAI-Mitgründer, letzten Dezember schreibt, er habe sich als Programmierer noch nie so abgehängt gefühlt, dürfen wir das auch. Für normale Wissensarbeit reicht übrigens fast immer ein mittleres Modell. Du musst nicht jedem Release hinterherrennen.

Warum die Reihenfolge zählt

Die einzelnen Skills sind das Leichte, fast trivial. Einen Skill für eine richtig gute Interviewanalyse diktierst du in zehn Minuten. Schwer ist zu verstehen, wie AI mit deiner Arbeit zusammenhängt und wie die Teile ineinandergreifen.

Die Rollenklärung legt fest, was überhaupt in deine Source of Truth gehört. Wer kein Budget verantwortet, schreibt dort keinen Business Case hinein, sondern die KPIs, die er tatsächlich bewegt. Die Source of Truth speist deine Kommunikation. Ohne sie generierst du nur schönere Statusmails aus fünf verschiedenen Wahrheiten. Der Kommunikationsrhythmus macht früher oder später sichtbar, dass die Mails der Kollegen deinen widersprechen, und genau dann braucht ihr das gemeinsame Regal. Und erst das Regal sorgt dafür, dass die Produktgruppe als Ganzes schneller wird und nicht nur jeder für sich ein bisschen effizienter.

Dafür gibt es gar nicht so viele Regeln. Aber man muss es regeln.

Was am Ende rauskommt: Zeit fürs Gestalten

Mir ist gerade eine PM-Stelle begegnet, die genau so gebaut ist. Erst ein laufendes Produkt übernehmen und so schlank bekommen, dass es mit deutlich weniger Aufwand läuft. Mit der frei gewordenen Zeit dann herausfinden, welche neuen Ideen im Unternehmen wirklich ein Produkt werden sollten. Erst das eigene Zimmer aufräumen, die Orchestrierung mit AI so leicht wie möglich machen, und dann Kapazität für das Neue haben.

Das ist für mich die ermutigende Pointe. Das Gestalten, von dem viele von uns träumen und das im Alltag so selten gefragt ist, kommt auf diesem Weg durch die Hintertür zurück. Verdient, nicht beansprucht. Weil jemand die Verwaltung so gut in den Griff bekommen hat, dass Zeit übrig bleibt.

Und selbst wenn es nicht ganz so weit kommt: Die Arbeit, die Firmen tatsächlich von uns wollen, wird mit AI leichter und macht deutlich mehr Spaß. Also all in, genau dafür.

P.S. Wie das alles ineinandergreift, für dich als PM und für euch als Produktorganisation, ist der Kern meines Kurses „AI Augmented Product Management“. Die nächste Kohorte startet am 12. Oktober: ueberproduct.de/seminar/ai-augmented-product-management

In my courses “AI Augmented Product Management” - in which we go deep into what Product management looks like under full exploitation of the new tools like Claude Code / Codex etc. - we talk about the Shapiro Scale. The interesting levels are 2 and 3, because getting from 2 to 3 means a tough psychological step of a) trusting the tools and b) letting go of knowledge that - until now - defined you.

• Level 2: reading every code diff line by line before it ships.

• Level 3: trusting the test suite and only checking whether the feature actually works.

I didn’t think about it that way, and didn’t call it “human-in-the-loop versus human-on-the-loop” (HITL vs HOTL) until I wrote the last article on here, and then it was obvious that’s exactly what it is. And, the discussion of “the human needs to stay in the loop” is getting full coverage, sadly most of the discussion is orally laden, with little facts. That’s what I touched on in the last article: is there a huge difference between automating red lights and coding?

There is no rulebook that tells you when you’re allowed to move from one to the other. No one tells you, when it’s ok, to leave the top and trust the agents to get called in in escalation mode only. Watching it happen in my training cohorts now and seeing the doubt, my estimate is something like a thousand repetitions before it feels safe. The move is roughly 90% psychological, and 10% infrastructure (even though that’s also a tough engineering task). The ratio still feels strange. Ninety percent feeling is an awkward way to get to what should be an engineering decision. My guess was: this is not the Matrix, not the singularity. It must have happened before. So I went looking for whoever had already answered this properly.

Tech history repeats itself

Turns out plenty of people had. Aviation, nuclear plants, weapons systems and self-driving cars all had to deal with this exact question decades before even the idea of a coding agent existed: when does a human check every step, and when does a human just watch and step in if something looks off? The reasoning in the past was a bit less biased on vibes or moral verdicts. They wrote criteria down, argued about them, and put them into standards documents you can still read.

Four of those criteria apply to us directly. AI coding added exactly one that wasn’t available to the older technologies. And then, finally, there’s a fifth one that gets no mention. I’ll handle that last.

Aspect 1: Can a person even react in time?

This is the oldest and hardest one, and the only one that can be decided with a stopwatch in your hand.

The US Navy’s Phalanx close-in weapon system, deployed since 1980, normally runs under a human’s direct control - until the number of incoming threats outpaces the capability of a person to track them. At that point the operator flips the system to automatic. Yes, it runs on manual as long as things are simple. As soon as they become complicated and overwhelming, the human trusts the loop more than himself. Interestingly, nobody argues about this one on principle. Incoming munitions don’t wait for a committee to decide correctly and in full alignment.

Cars do the same thing and there is only little discussion, it simply gets implemented in the background: automatic emergency braking never went through a human-in-the-loop phase at all. It couldn’t. The reaction window is a few hundred milliseconds, well under what a person can manage, so the standard that defines self-driving levels ignores it completely - it’s not even on the ladder from Level 0 to Level 5, because it was never a candidate for human oversight in the first place. You’ve probably felt this yourself: the car braking half a second before you even could. Nobody wrote a post demanding a human stay in that loop. (Although experiencing phantom braking by early Teslas might make you appreciate the “Shopping Cart Theory”.)

Nuclear reactors run on the same principle. Under certain fault conditions the control rods drop automatically, because - in the words of the researchers who formalised this back in 2000 - “the operator cannot reliably respond in time to avoid an accident.” Let that sink in! The level of trust! If a human genuinely cannot act inside the window, keeping them in the loop is theatre. and in those existential situations, in that tech, we simply switch to automatic. End of discussion.

As another example, there’s MCAS. Boeing’s system on the 737 MAX assumed pilots would recognise an unexpected activation and correct it within three seconds. The FAA approved that number. Two crashes and 346 deaths later, it turned out pilots couldn’t do it reliably - not because they were bad at their jobs, but because the number was wrong and nobody had tested whether it was right. The criterion made sense. The number didn’t, and nothing warns you about that until the thing you built on top of it fails.

Aspect 2: What does the mistake actually cost?

Reaction time tells you whether a human can act. The second criterion asks what happens if nobody does, or if they act wrong.

Civil aviation avionics are held to roughly a one-in-a-billion catastrophic failure rate. The number comes from formally multiplying how likely a failure is by how bad it would be. I go through the same calculation, far less formally, every time I decide whether an agent gets to touch a client deliverable or just my own side project. Low cost, low probability: let it run. High cost, any probability: stay close.

You’d expect that logic to show up explicitly in the actual standards. Most of them don’t show them, which is worth knowing before you think of them as settled. SAE J3016, the document that defines self-driving levels, doesn’t grade cars by risk at all. It grades them by who’s doing the driving and who catches it when something goes wrong - a raw role assignment, not a risk score in sight. Phil Koopman, who wrote the standard’s own field guide at Carnegie Mellon, is straight about the myth that was created around them: “higher level numbers have more automation, but they might not be safer.” Level 3 is simply a different arrangement of who’s responsible for what. The higher number doesn’t indicate less risk or danger.

The US military does the same thing on purpose. Its directive on autonomous weapons defines no explicit risk threshold at all that flips a system from supervised to autonomous. Michael Horowitz, who helped write the 2023 update, says the omission was deliberate: the standard is “appropriate levels of human judgment,” a phrase built to stay flexible rather than to compute. So if you want a clean formula for how much risk buys how much autonomy - the people who do this for a living, with actual lives on the line, decided not to give you one. That seems oddly comforting to me. It seems we currently aren’t failing at something everybody else already solved.

Aspect 3: The one new criterion - can the machine check itself?

None of the older technologies had this one available, because it didn’t exist: the artifact checking itself.

Boris Cherny, who built Claude Code at Anthropic, described his own working style in February this year as still needing a human eye on the output - “you still do want a human looking at the code.” A month later Anthropic shipped a feature where a team of agents reviews every pull request instead, and Cherny’s explanation was refreshingly unromantic: reviews had become the bottleneck. In other words, economics made him look at and try to solve the new bottleneck. Whatever. By June he was saying he hadn’t hand-written a line of code in eight months, and that most mornings he wakes up to pull requests Claude already built, tested end to end, with screenshots proving the feature runs.

Four months, start to finish. What moved wasn’t trust arriving on a schedule - what happened was that the checking moved from a person into the artifact itself. Code can run its own tests. That’s the whole trick. The trick is that you have loops that interact with each other: produce - check -produce - check until a halting criterion is fulfilled.

A PRD is an artefact that does not have that capability. It can’t run itself and tell you it’s wrong, and that makes me very uncomfortable about my own profession: we product (well, and “business” in general) people have never cared about “correctness”. Developer agents know when to stop because linters, type checks and tests hand them a closed loop. We have no equivalent for a PRD, a strategy deck or a hiring decision - partly because it’s genuinely hard, partly because we found it more flattering to call the gap “judgment” and leave it at that. And we repeat the pattern now by a ton of “product leaders” calling for “taste” and judgement as the last line of defence for our jobs. I call that BS and simply privilege.

Verifiability is the newest criterion on this list, and it’s the one where the rest of knowledge work is sixty years behind software. You cannot value the compiler and what followed highly enough. The insight that coding is math and category theory and completeness, and that the question whether P = NP is important — that makes all the difference. The rest of knowledge work takes a bath in ignorance and subjectivity, but “data driven”, please. Make of that what you will. Maybe it’s an art form.

The problem: It’s also the easiest one to fake. Cat Wu, who works alongside Cherny, named the failure mode directly: if a team waves through 99% of an agent’s permission prompts, the review step exists on paper and does nothing in practice. The military realised this decades ago and wrote it down - with C-RAM systems the operator holds a veto they have half a second to make use of, and, as one analyst put it, “few [are] willing to challenge what they view as the better judgment of the machine.” In other words, pragmatically speaking, they trust the machine more than they trust themselves, if asked. Same ceremony, different uniform. And - give that a minute to sink in - this is the closest thing to a controlled study we have: sixteen experienced developers, using Cursor, working in their own real repositories found them 19% slower. Verifiability being possible in principle says nothing about whether it’s running in your pipeline.

Aspect 4: Do you actually still know how?

None of the official standards mention this one, and a regular in my AI-augmented PM cohort put it better than any paper I’ve read: “Breakdowns happen exactly at the edge of one’s own competence, not inside it.” Where you’re genuinely good, you can hand more to an agent, because you’ll spot the moment it drifts. Where you’re not, it fills the gap plausibly and with full conviction but you have no way to tell. Plausible is the dangerous part. The output always looks smooth, no matter if it’s right or wrong.

One might think that settles it - get skilled first, then extend autonomy. Except the skill decays exactly where you need it. Lisanne Bainbridge wrote this down in 1983, long before any of this technology existed: automation hands the routine work to the machine, and the human left watching never gets to practise the skill they’re supposed to use when something breaks. This sounds like a terrible fate. But there is an obvious solution. The FAA eventually had to write a memo about it. Pilots who’d stopped hand-flying because the autopilot did it better were losing the ability to fly the plane when the autopilot quit - so in 2013 the agency told airlines to mandate manual flying hours as a counter measure. On purpose. To keep alive a skill that automation had made unnecessary, until one day, in urgency, it wasn’t.

The Level 3 Product Managers in my courses didn’t get there by getting smarter about “the code” (or outcome as they are PMs). Most of them read less of it than the year before. The ones who can still jump in when something breaks are the ones who deliberately still messed with it.

The real driver behind automation

Every criterion above sounds principled: measured risk, measured reaction time, measured verifiability. Then you look at the actual history and research - and the boring answer driving automation is always the same: Money, $$$, Mullah, the economy.

New York City automated its traffic lights in the 1920s, and the reason on record wasn’t safety data. The city could reassign all but 500 of its 6,000 traffic officers and save $12.5 million doing it. (Guess what the officers thought about the reliability of the new technology.) The US Air Force’s own 2009 planning document, arguing that operators should move from “in the loop” to “on the loop,” made its case with a staffing table: the same number of patrols that needed 570 pilots would need 150 once multi-aircraft control kicked in. Trust was not mentioned in the document as a concept. As long as the miss / hit rate made the program cheaper, everything was fine.

Probably the same is true for a decent share of the AI-agent autonomy pitches landing in your inbox right now. When someone tells you their tool has earned more autonomy, ask which calculation actually changed - the risk math, or the headcount math. To be frank, it’s usually the second one wearing the clothes of the first. Especially in an industry that is terrible at calculating development productivity or - even worse - product outcome. Ask Kohavi who made a career of trying to understand that and came up with the numbers.

By intuition, we basically gamble as Product managers: 1/3 of what we realise has positive impact, a third has no measurable impact, yet another third has bad influence on value for the customer. In other words: The bar is as low as throwing the dice.

Finally

I still ask my course participants where they are on the Shapiro Scale, and I still watch most of them walk up the ladder quite slowly and try to “stay in control”. The instinct is to look into the agents, to control at the wrong, tedious level. Until there is trust. The reason is not that nobody gives them the criteria - that’s one of my first moves. It’s because knowing the criteria and trusting them are two very different jobs. The technologies that solved this before us didn’t simply skip those levels. They had a few more decades to consider than we’re getting. We didn’t choose for AI to hit this hard and fast. But here it is and the best thing is to try and understand it and look for history examples on how to deal with it.

Die Statements sind Auswirkung von Strategie-praktiken, die von wenigen im Silo ausgeführt werden. Eine Verarbeitung der Eindrücke eines feinen Sensorsystems im Unternehmen findet nicht statt. Hinweis: Das Wissen über den Markt und die Umgebung sitzt am Rand des Unternehmens, in den Teams. Auch wenn es dort eventuell noch nicht verarbeitet wurde.

Strategien werden dann entsprechend im Labor erarbeitet. Und eine Einordnung in den begriffen und der Erfahrungswelt des Unternehmens findet auch nicht statt.

Letztlich ist das Ergebnis von Strategiearbeit hier ein Plan, der umgesetzt werden soll. Und da obige Mechanismen wirken, gibt es auch keine regelmässige Anpassung des Plans. Schlimmer: Wissende Stimmen, die um die Aussichtslosigkeit des Plans wissen, wollen und sollen nicht gehört werden.

Ich mag hier zwar die schlimmsten Aspekte des Szenarios schildern und übertreiben, aber man wird den Kern der Mechanismen erkennen.

Demgegenüber steht eine inklusive Strategie, die sowohl vom Input, der Arbeit, der Ergebnis und in der Umsetzung ins Unternehmen regelmässig eingebettet ist (Lackmus-Test:  Isolierte Strategie – seltene  Offsites weniger Leute, inklusive Strategie – in den Arbeitsalltag durch hohe Kadenz integriert, relativ viele Teilnehmer).

Hier ein paar differenzierende Eigenschaften isolierter vs. inklusive Strategie:

Eigenschaften inklusiver Strategie

Eigenschaften inklusiver Strategie (2)

Eigenschaften inklusiver Strategie (3)

Deine Kommentare und Gedanken würden mich interessieren!

5% Heureka

200 Leute im Publikum. Ich stehe auf der Bühne, halte einen Vortrag zu einem ganz anderen Thema. Meine Frage lautet: „Wer von Euch kann mir die Strategie seiner Firma erklären?“

Was denken Sie – wie viele Hände gehen hoch? Zwei? Oder doch drei? Wahrscheinlich trauen sich ein paar nicht. Vielleicht könnten es also 10 sein. Mit viel Glück sind es zwanzig. Das sind zwischen 5% und 10%. (Wahrscheinlich Führungskräfte, die in Strategieentwicklung einbezogen sind.

Oder sehr sehr motivierte Menschen. Die Unklarheit ist also beträchtlich. Unklarheit darüber, an welchen Dingen wir warum arbeiten.)

Wir haben es also, konservativ geschätzt, mit 90% Personal zu tun, dass nicht wirklich erzählen kann, warum sie welche Arbeiten erledigen.

Lost In Translation

Das wundert mich. Als nächstes spreche ich über diese Szene mit dem Vorstand eines Unternehmens. Ich erzähle ich ihm von dieser typischen Erfahrung bei meinen Vorträgen und sage ihm: „Wahrscheinlich ist es bei Ihnen ähnlich!“ Er kann sich das zwar vorstellen, ist aber dennoch verblüfft.

Er sagt: „Komisch, dabei geben wir uns ich alle Mühe, die Strategie ständig zu erzählen. Wieder und wieder.“ Er erzählt mir von den Formaten, in denen das alles erzählt wird: all Hands, Abteilungsleitermeetings, Brown Bag Lunches, Newsletter ….

Da passt doch etwas nicht zusammen!

Wenn Die Honeymoon Riders Verzweifeln (Kadenz)

Unser Top-Team, die Honeymoon Riders (ja, so heissen Teams heute nun mal) haben sich mächtig ins Zeug gelegt. Leider hat das dazu geführt, dass sie eines unserer großen Probleme einfach nur früher entdeckt haben. Lösen können sie es auch nicht: Zulieferer Datasea LLC hat seine Daten einfach nicht in der richtigen Form über die API zur Verfügung gestellt.

Leider sind diese Daten essentiell. Irgend etwas ging bei den Verhandlungen schief? Datenformate, Update-Frequenz und Funktionalität sind nicht wie besprochen und an mindestens diesen drei Stellen gab es Missverständnisse. Leider arbeiten die Honeymoon Riders seit 4 Wochen an diesem Problem vorbei.

Sie meinen es gut und wollen alles retten, denn Projekt Source Force ist Mission Critical. Man hat das in diesem und jenem Meeting deutlich vernommen: Wenn die Honeymoon Riders nicht fertig werden, gibt es ein Problem mit dem strategischen Ziel horizontalen Wachstums, sprich Internationalisierung. Das ist zwar nicht das einzige Problem, dieses ist aber sehr sicht- und nachvollziehbar.

Bis zur Erkenntnis, dass die Honeymoon Riders scheitern werden, gab es einiges Hin- und Her („Wen trifft die größte Schuld?“, „Wie konnten wir (oder die) das übersehen?“, „Wer hat den Vertrag überhaupt geschlossen?“, „Wieso waren wir eigentlich nicht dabei?“, „Wieso war _überhaupt kein_Techniker dabei?“, „Glaubt ihr das will jetzt irgend jemand hören?“, usw.).

Am Mittwoch gibt es nun den großen Gang nach Canossa. Ein Krisenmeeting. Gottseidank noch nicht auf höchster Ebene. Es ist aber klar, dass das Team die Unterstützung der Vorgesetzten benötigt, um das Problem zu lösen. Die Lösung besteht im Erreichen einer Entscheidung: Den internationalen Roll-Out it einem machbaren Kompromiss bei weitgehend verminderter Qualität starten oder aber das Projekt um (wer weiss das schon so genau?) ca. 4-6 Monate verschieben.

Schön wird es nicht werden. Der CFO hat bekanntermassen erste Umsätze aus dem hoffnungsgeladenen internationalen Geschäft schon in den YoY Forecast integriert. Marketing wiederum hat die Kampagne schon vorbereitet. Das Geld ist also schon mal weg oder zumindest gebunden.

Mit der schlechteren Qualität hat man sicher nicht geworben. All diese Dinge kann man nicht von der Hand weisen. Das Problem aber leider auch nicht.

Mittwoch 16:30 Uhr. Die Honeymoon Rider beim Café in der Firmenkantine. Betrinken geht nicht, also muss ein Kaffee herhalten. Das Team ist jäh aus seinen Flitterwochen erwacht und auf dem traurigen Boden der Tatsachen angekommen. Weniger Hawaii. Doch eher ein neblig, trüber Berlin/Brandenburger Nachmittag, kurz vorm Eintreten der Dunkelheit.

Warum traurig sein? Ganz einfach: Niemand war gewillt, Willens oder in der Lage zu entscheiden. Das Risiko ist einfach zu groß. Die Entscheidung, so heisst es, könne nur das Leadership Team Treffen. Zu viel stände auf dem Spiel. Klar! Das wäre auch alles kein Problem.

Jedoch: Das Leadership-Team trifft sich für Anpassungen an strategischen Themen erst wieder in 6 Wochen. Vorher sind sie für die Honeymoon Riders nicht zu sprechen. Keiner versteht es. Aber so ist der Zeitplan nun einmal. Auch auf eindringlichste Erklärungsversuche hin die Entscheidung auf das nächste reguläre Meeting verschoben.

Eben in sechs Wochen. Dabei wurde noch einmal die Gelegenheit genutzt, denen _unten_das größte Vertrauen auszusprechen. Man sei ja erwachsen und regele das schon.

Ich Verstehe Hans K. Nicht (Entkopplung)

Vorhin war Hans K. bei mir. Er war wieder etwas panisch. Hans K. ist öfters mal panisch. Hans K. ist einer meiner guten Projektleiter. Er hält hier viel zusammen. Seit wir ins Ausland wollten, ist er aber aber öfter panisch als früher. Ich bin es ja gewohnt. Deswegen ist mir auch vollkommen unklar, wann ich seine Panik ernst nehmen muss und wann nicht.

Vorhin sagte er, dass ausgerechnet eines unserer besten Teams, die Honeymoon Rider Alarm schlagen. So kenne ich die gar nicht. Hans K. versucht mir dann immer zu erklären, was genau das Problem ist. Und dann kommt eine Flut von Worten, die mir nichts sagen. Details über Details.

Details von Dingen, von denen ich gehofft habe, er kümmere sich darum und hält sie von mir fern. Details von Dingen, die ich auch nach 30 Minuten googeln und Videos anschauen nicht verstehen würde. Was ich nicht tue. Verstehen Sie mich nicht falsch. Würde er das Team zu mir schleppen, würde ich schon etwas sagen.

Man kann ja schlecht keine Meinung haben, in so einer Situation. Aber tatsächlich: Eigentlich verstehe ich nicht, was dort vor sich geht. Von morgens bis Abends kommen so Leute wie Hans zu mir. Details auf den unterschiedlichsten Ebenen. Irgendwie läuft der Laden ja.

Aber manchmal denke ich mir, ich mache alles falsch. Tatsächlich scheint mir, ich kann auf dieser Ebene nicht denken. Ich bewundere die Leute. Manchmal beneide ich sie. Am Wochenende gehe ich den Garten um etwas Konkretes zu machen, etwas zu erleben. Aber das, was sie hier machen – ich verstehe es einfach nicht.

Wahrscheinlich ist es trotzdem nicht gut, dass ich Hans K. damit alleine lasse. Ich sage immer: „Ihr seid doch erwachsen, regelt das untereinander.“ Mir ist schon klar, dass das nicht fair ist. Aber ehrlich: Ich verstehe das nicht. Die Nachrichten und Einschläge kommen auch immer so spontan.

Alles zusammen sind einfach nur Geräusche. Ich weiss nicht wirklich, was die Leute machen. Manchmal verkaufe ich das als Delegation und Vertrauen. Tatsächlich fällt mir nicht ein, wie das System haben könnte. Sind ja auch viele Leute hier. Ich weiss gar nicht mehr wie viele Ebenen da sind.

Jetzt Aufhören? Jetzt? (Das Sunk Cost Syndrome)

Jetzt schlägt Hans K. wirklich Alarm. Jetzt! Und wie! Letztens, als ich dringend was wollte – ich hatte auch mal eine Idee – nämlich, dass wir dringend jetzt was in B2B machen, da war aber „nichts zu machen“. (Jetzt erzählen mir schon ständig mein CTO und meine Projektleiter wie das Geschäft läuft.)

Alle, die mir was vom Markt erzählen, sagen mir, „da müssen wir was machen“. Und mir kommt es so vor, als wäre das so. Also gehe ich zu Hans K. und sage „Hans K., wir müssen was machen. In B2B. Stellen sie mal ein paar Leute zusammen, die was dazu wissen und lassen Sie uns reden.

Einen halben Tag Workshop und sich mal austauschen, was gehen könnte. Was sagt da Hans K.? Hans K. sagt, „das geht jetzt nicht!“. Und ich frage mich, was er damit meint. Und was er damit meinte, war tatsächlich, dass das jetzt nicht geht. Und dann musste ich mir 5 Minuten lang anhören warum das jetzt nicht geht.

Womöglich hatte er recht. Ich weiss es nicht. Was er sagt klang schon richtig. Nur, was weiss ich. Dass wir alle keine Zeit dafür haben stimmt ja nur, wenn der ganze Kram, den wir jetzt machen _wirklich_so wichtig ist. Das ist ja der Witz: wissen wir das? Weiss das irgend jemand?

Wie genau? Egal. Ich sagt ja schon: Jetzt war er wieder da, der Hans K.. Das Problem mit den Honeymoon Riders (ja, so heissen Teams jetzt nunmal) ist eskaliert, wie er sagt. Damit meint er, ich solle mir jetzt mal Zeit nehmen. Das ganze Leadership-Team soll zusammen kommen und entscheiden, wie’s weiter geht.

Jetzt! Der Rollout von unserer Internationalisierung soll dran hängen. Aha! Soll er sein Problem halt lösen! Wo war seine Eile als ich mein B2B wollte. Und jetzt sag’ ich Ihnen mal was. Hinkriegen soll er die Internationalisierung halt. Die bringt mich jetzt schon um.

Da hängt ja was dran. Erst war’s ja nur so ne Idee. Dann hatten all unheimlich Schiß. Was machen wir? Wir holen die McKinseys rein. Jetzt fühlen sich alle besser – bis auf die Honeymoon Riders und alle, die da dran hängen – und wir können’s durchziehen. Was 250 Seiten Powerpoint, die heute keiner mehr kennt, ein blumiger Satz und 500.000 EUR so machen können? Und jetzt nicht durchziehen, weil’s mal schwierig wird? 2.000 EUR pro Slide und aufgeben?

Ich bin kein Nihilist. Ich habe nichts gegen Methoden. Im Gegenteil. Vor ein paar Tagen habe ich folgende Beobachtung retweeted:

Interesting: At conferences you often see fractions or methods ‘winning’: marketing, dev, devops, ux, strategy. Rarely a great, unified team

— 𝗠𝗮𝗿𝗸𝘂𝘀 Andrezak (@markusandrezak) June 14, 2017

Ich beobachte es immer wieder: Erfolgsgeschichten werden erzählt und der Weg zum Erfolg war linear. Von null auf hundert durch Anwendung von Methode X. Firmen stürmen von Stillstand zu unglaublichen Werten bzgl. Erfolg, Geschwindigkeit, Qualität, und Kundenzufriedenheit. Jeder erdenkliche und wichtige Vektor geht hoch. Der Grund ist klar: Methode X!

Das selbe gilt für Case Studies und meist ist es dort noch einfacher und kondensierter. Ursache des Erfolges von Firma Z ist Methode X. Manchmal haben sogar nur Teile der Organisation Methode X angewandt und siehe da – noch immer gehen alle Vektoren der Firma nach oben.

Ich weiss, dass es nicht stimmen kann. Und Du weisst es auch. Wo immer Methode X eingeführt wird, ächzt es im Gebälk. Wir alle kennen die Wahrheit und das Rumoren am Kaffeekocher:

• Das Management macht nicht mit
• Wir verstehen es, aber die anderen …
• Das Mittlere Management blockiert alles (sagen beide Seiten: die oben und die unten)
• Abteilung XYZ versteht es echt nicht!
• Eigentlich machen wir alles, aber Aspekt Z geht hier echt nicht.
• Keine Ahnung warum wir das machen
• Wir machen es, ehrlich gesagt, halbherzig
• Methoden-X-Theater

Obwohl wir wissen,

• das Methoden alleine niemals Erfolg bringen,
• kleine Teile und Teams in der Organisation nicht diesen Effekt haben konnten,
• das Case Studies und Talks die Wahrheit verdrehen und vereinfachen,
• das Methodiker die Aufgabe haben, Ihre Methode zu verkaufen und als überall einfach anwendbar darzustellen,

ist es doch schön, die darin verborgene Motivation mitzunehmen.

Abb 1: Wie Case Studies die Welt sehen

So einfach könnte es sein. Und so gefährlich.

Wie sich Erfolg und Fortschritt wirklich entwickeln

Der Ursprung: Extrem motivierte (getriebene?) Menschen wachen jeden Morgen auf und wissen genau, welche 500 Defizite sie noch haben um ihrem Ziel näher zu kommen. Was sie noch nicht können. Und sie haben Albträume über die Millionen Dinge, von denen sie noch gar nicht wissen, dass sie sie nicht können. Konstantes Memento Mori ist ihr Antrieb.

So funktionieren großartige Organisationen. Mehr noch:

Tatsächlich ist da, wo ich Exzellenz beobachte, einer der Hauptgründe des Erfolgs, dass dort Teams oder Teams von Teams sind, die kooperieren und sich täglich hinterfragen und lernen und lernen. Das in Verbindung mit der Eigenschaft, immer hungrig zu bleiben und niemals „fertig“ zu sein (in feiner Balance damit, nicht pathologisch getrieben zu sein).

Dort gibt es: Einen klaren Zweck, ein klares Verständnis des Kunden, der eigenen Fähigkeiten, das Wissen wie man den Kunden zu behandeln und mit ihm zu kommunizieren hat und vieles mehr, das alles zusammen Teams erfolgreich macht.

Schlaue Leute suchen also den Fortschritt und müssen daher mit anderen Menschen kooperieren. Zu einem gewissen Zeitpunkt entwickeln sie dazu Muster und ein Vokabular. Methoden. Dadurch können immer mehr Menschen ähnlich mit ähnlichem Ziel miteinander arbeiten Das ist die Reihenfolge: Ziel, Ehrgeiz, Wille zu Kooperation, Methode.

Das passiert z. Bsp. bei Spotify und Toyota. Die Methode dient jetzt als Gerüst zu Kommunikation und Kollaboration im gemeinsamen Fortschritt.

Dort werden die Methoden sorgfältig und in sensiblem Einklang mit Zweck, Strategie, Vision usw. entwickelt und gepflegt.

Abb. 2: Wie Erfolg wirklich entsteht

Überraschung! Das Bild sieht viel komplexer aus, verwobener und damit auch härter zu kopieren. Daher hat Toyota auch immer die Konkurrenz eingeladen um das Toyota Production System zu beobachten: Weil es nicht hilft, die Praktiken zu kopieren.

Auch Jeff Bezos’ letzter Brief an die Shareholder zeigt die Komplexität und Überzeugung: Lies „On why it’s always day 1“ um einen Eindruck zu bekommen. Nichts in dem Brief kann man „einfach kopieren“.

Standardisierung und Marketing

Was später passiert, wenn Vokabular und Methode existieren, ist folgendes: Andere schlaue Leute, in anderem Kontext, lesen interessante Dinge darüber wie Methode X geholfen hat und wie eine andere Firma damit erfolgreich wurde  (siehe Abb. 1). Mit dieser Erkenntnis bewaffnet beginnt der Glaube zu entstehen, dass es tatsächlich der Einsatz von Methode X war, der den Erfolg begründet hat.

Über das drumherum hört man ja nichts. Und die Idee ist wirklich verlockend. Eine Todo-Liste, die zum Erfolg führt. Jetzt entsteht der Gedanke, dass es Erfolg bedeutet, excellent in der Durchführung von Methode X zu werden. Da steckt ja alles drin. Jetzt wird Exzellenz in Methode X das Ziel und ersetzt den ursprünglich gesuchten Erfolg.

Ausgetauscht. Erfolg ist jetzt ein erhoffter Nebeneffekt, denn den verspricht Methode X ja. Leider bleibt jetzt nur eine Firma übrig die sich um sich selbst kümmert. Das resultierende und jetzt verfolgte Bild ist noch einfacher und verwässerter als Abb. 1 :

Abb. 3: Wie Methode X in der dritten Welle angewandt wird

Holla. Jetzt fehlt aber eine Menge! Wo früher der Erfolg stand ist jetzt die Methode X das Ziel. Aber alles was vorher die Energie gebracht hat fehlt jetzt:

• Der Wille zu lernen
• Die Sehnsucht sich zu verbessern
• Der Drang nach Erfolg
• Ständiges selbst hinterfragen
• Die Vison
• Der Zweck.

Und so enden wir in Absichtslosigkeit und damit im Zufall.

Ein wirklich kleines, triviales Beispiel im kleinsten Rahmen:  In einem meiner Projekte mit dem einmal eine agile Transition begonnen hat, waren wir prächtig mit Zweck und Absicht ausgestattet. Wir wussten genau was wir wollten und das wir es auf unsere bisherige Weise nicht hinbekommen würden.

Wir wussten, wir müssen Agil arbeiten. Leider hatten wir auch davon eine klare Vorstellung. Und so begab es sich, dass wir einen PO bekamen, der mit einem Post-It „Projektplan“ zu uns ins Team kam. Wir wussten, das Projektpläne schlimm sind und haben ihm erklärt, dass er einen Post-It Projektplan nach user Vorgaben in ein Backlog und ein Scrum-Board umbauen muss.

Wir Dummerchen. Dabei wollte er doch schon das Richtige. Hier stand Methode vor Empathie, Kollaboration und allem was sonst noch wichtig ist. Gottseidank war der PO unglaublich geduldig und tolerant und hat uns ausgehalten. Wir haben dann trotzdem geliefert! Aber tatsächlich hätten wir fast alles kaputt gemacht, weil wir in unserem Enthusiasmus die Methode in den Vordergrund geschoben haben und nicht das Ergebnis.

Um es klar zu machen: Ich liebe Methoden und wir brauchen sie. Wir müssen aber dafür Sorge tragen, dass sie nicht die führende Grüße werden. Die führende Größe muss immer das bleiben was wir beabsichtigen. Zweck, Vision, Absicht, Empathie. Das Schwere an dem Thema ist, dass wir es hier mit blinden Flecken zu tun haben: wir meinen es ja gut!

Wir sollten uns daran erinnern, dass Methoden nur Mittel zum Zweck sind und weder Weg noch Ziel und wir sollten diese dinge nicht verwechseln und austauschen. Methoden sind einfach nur das Gerüst an dem wir uns auf der wilden faszinierenden Reise festhalten können.

Ich glaube, das ist auch der Grund, warum sich nur wenige Manager für Methoden interessieren: Für sie sind es nur Tools in den Händen anderer.

In meinem Blog Post „Elements on of intentful companies“, versuche ich mehr über die Aspekte, die ein erfolgreiches Unternehmen benötigt zu schreiben und ich versuche dabei Methoden zu ignorieren. Vielleicht springst du direkt dahin und liest weiter?

Hier ein paar Beobachtungen und kleine Tipps, wie deine Transition nicht wie bei Dilbert endet. Sagen würde man es dir sowieso nicht. Du erfährt es nur beim Lauschen an der Kaffeemaschine.

Einmal einen Halbmarathon in 90 Minuten!

Ich hatte einmal das Ziel, einen Halbmarathon in 1h 30 min zu laufen. Als ich mir das Ziel ausgesucht habe, dachte ich, ich wäre schon fast so weit. Warum auch immer. Ich bin dann diverse Wettkämpfe gelaufen, 8km, 10km usw. Und irgendwann auch einen Halbmarathon. Da war sie, die schonungslose Wahrheit: 1:43 – ich war knapp 13 Laufminuten und mehrere Trainingsjahre von meinem Ziel entfernt.

Ein paar Jahre später habe ich es dann geschafft, aber der Weg war mühsam. Sehr mühsam. Erst kamen die Fortschritte recht schnell (ich „konnte“ ja noch nichts): 1:43, 1:38, 1:35, … aber dann 1:33, 1:32, 1:31, wieder 1:32 … Jetzt muss man anders messen: 1:32:05, 1:31:38, 1:33:23 (aber bei großer Hitze ;), 1:30:42 (bei schlechter Strecke und vielen Kurven) … usw. Man sieht schon, die Begründungen warum es nicht klappen konnte werden detaillierter.

Was man wissen muss: Ich bin in der Zeit zwischen drei und fünf mal pro Woche laufen gegangen – je nach „Trainingsphase“. Auch das hat man jetzt: Trainingsphasen. Das Training wurde ausgefeilter: Lange Läufe, lange Läufe mit Temposteigerung, Sprints, 400 m Wiederholungen mit oder ohne Steigerungen, 1000 bzw. 1500 m Wiederholungen mit oder ohne Steigerungen, 20 min an der anaeroben Schwelle, oder knapp drüber … usw.

Und insgesamt habe ich doch sicher 5 oder 6 Jahre gebraucht. (Ich müsste nachschauen). Alleine 3 Jahre um von knapp 1:33 auf die endlich 1:29:46 zu kommen. So knapp war das dann. Ich habe gezittert bis zum letzten Meter, mir einen ganz Wettkampf mit extrem ebenem Kurs ausgesucht … und als ich es geschafft habe, bin ich vor Freude gestorben. Egal. Tatsächlich: egal. Und: Viele andere bekommen das viel einfacher hin als ich.

Was ich sagen will: So schwierig ist das immer mit dem „Besser werden“. Und: das war nur Laufen. Und: nur ich.

Ich komme darauf, weil der Podcast mit Stefan Roock und Henning Wolf mich wieder daran erinnert hat, wie komplex ein Umbau einer Firma zu „agilerem Arbeiten“ ist. Seit immer mehr Firmen das machen, könnte der Eindruck entstehen, dass es ein Rezept oder sogar eine Industrie „agiler Berater“ gibt, die das mal eben hinbekommen.

Der Eindruck, dass man „Agilisierung“ bestellen kann. „Wie lange dauert das denn?“ kurz nach dem Start des „Programms“ ist die Frage statt „Wann sind wir da“ von den Rücksitzen sobald die Fahrt begonnen hat. Beide Fragen sind verständlich. Die Antwort ist: Es dauert. Lange. Und wir wissen nicht genau, was passiert. Aber wenn man das versteht, kann es Spaß machen.

„Man kann doch nicht erwarten, dass die Leute in 2-3 Wochen etwas erreichen wofür 12, 15 Jahre gebraucht haben“ – Henning Wolf

Erfolgsfaktoren (Randbedingungen, keine Rezepte)

Hier ein paar Punkte, die Stefan und Henning im Podcast als für den Erfolg erwähnt haben:

„Transitionen“ klappen besser wenn

• der Grund und die Motivation klar sind
• das Bekenntnis (Commitment) zur Transition klar ist und nicht in Frage gestellt werden kann – auch wenn das „Wie“ noch nicht klar sein kann-sich interne Mitarbeiter finden, die für das Theme wirklich brennen und die Freiheiten haben das Notwendige zu machen. Dazu gehört es auch, immer wieder Unbequemes anzusprechen und zu diskutieren. sonst ist Verbessern nicht möglich.

Reality Checks

• (A) Man sollte gar nicht erst denken, der Umbau ginge schnell. Nichts klappt schnell, schlimmer noch: Eile im Umbau ist kontraproduktiv
• (B) Man muss den (Software-Entwicklungs-)Prozess selber besitzen. Man muss selber nachdenken und die Arbeit machen. (Henning Wolf)
• (C) Man sollte nur die wenigen Mittel anwenden, die man gerade braucht und nur so lange man sie braucht.

Agile Frameworks haben tolles Marketing und ich weiss sogar einiges davon zu schätzen: Sie erklären Menschen, die ich nicht erreichen kann gewisse Grundlagen. Es gibt zwei Gefahren:

1. Gewollt oder ungewollt werden beim Leser oder Kunden Bilder von Einfachheit und Umsetzungsgeschwindigkeit erzeugt. Das ist Quatsch. Siehe (A), (B) und (C).
2. Um Klarheit zu erzeugen wird vereinfacht und Rezepte kommuniziert. Rezepte helfen nicht im Umbau, siehe vor allem (C).
3. Menschen sind recht komplex im Verhalten, viele Menschen umso mehr. Viele, viele Menschen zu motivieren ist unglaublich schwer.

Ranmdbedingungen: Do’s und Don’ts

Dieser Blogpost ist viel zu kurz um das Thema ausgiebig zu thematisieren. Hier die Top-of-the-Pops von Fehlern im Anfang einer Transition, die ich gesehen habe. Alle diese Fehler spüren Angestellte wie ein Schlittenhund, den man versucht zu einem U-Turn zu bewegen:

Eile (siehe oben) wird an den Tag gelegt. Tödlich.

Der Grund für die Transition ist nicht klar: Wollen wir uns ändern? Müssen wir uns ändern? Warum? Sind wir zu langsam? Wenn ja: Was heißt schneller? Mehr Durchsatz? Bessere Time-To-Market? Bessere Produkte? Höhere Qualität? Einfach nur einen Projektstau abbauen? Wollen wir eine Firma werden, in der es netter zu arbeiten ist? All das und noch viel mehr sind valide Gründe für Transitionen. Aber in vielen Transitionen ist das Ziel und der Und nicht klar. Also ist nicht klar, warum ich mich verändern sollte.

Ändern sich die, die Änderung „bestellen“ auch selber? Leben sie es vor? Wenn nicht, wird es schwierig. Überhaupt: eine Besteller-Mentalität ist zum Scheitern verurteilt.

Was nie klappt: Änderung gleich im Großen. „Einmal Agil für 500/5000 … Mann, bitte!“ Erfolgreiche Transitionen beginnen klein. Im Großen ist das zu schwer und zu komplex. Alleine schon der folgende Punkt wird uns umbringen: Aus einer sehr planerischen Weltsicht kommend, wird man die Änderung im Detail planen wollen. Bis wir eine große, globale Änderung geplant haben ist schnell ein Jahr vergangen. Ich habe Teams gesehen, die wollten ein agiles Pilotprojekt ein halbes Jahr lang planen. Entschuldigung: Ein agiles Pilotprojekt im Kleinen macht man einfach.

Was auch nie klappt: Änderung ohne konkreten Anlass! Wenn wir keinen konkreten Anlass haben, den wir und unsere Angestellten verstehen können und der zur Veränderung motiviert, ist es düster. Anhand des Anlasses lassen wir einen kleinen Teil unseres Unternehmens auf neue Art uns Weise arbeiten. Anders würden das Ziel, den Anlass nicht hinbekommen. Dafür dürfen wir ein paar Regeln brechen, auf neue Art arbeiten. Wir haben Erfolg und das macht die Runde und schafft vertrauen. Jetzt können wir darauf aufbauen und die Transition ausweiten. Tipp zum googeln: Kotter-Change-Modell.

Was auch klappen kann: Agilisierung von der Unternehmensspitze her. Mein Lieblingsansatz. Hier kann man Größe und Anlass / Anlässe der Agiliserung wunderbar – ja – 1 dosieren und die Änderungen dort triggers wo man sie braucht und nicht sinnlos über das ganze Unternehmen ausschütten. Anhand eines tollen Portfolioansatzes agilisieren wir gezielt von der Spitze das Unternehmen. Das Tolle: Das agilste Team ist der Vorstand bzw. die Geschäftsführung. Die Spitze lebt es vor und der Rest sieht das Role Model und muss sich nicht fragen warum „ich mich ändern muss“. Jetzt ist alles klar.

Das Thema ist enzyklopädisch (und doch ganz einfach). Heute erst einmal so weit. Meine Einstellung dazu: Transitionen machen Spaß, weil man nicht weiss was passiert. Weil man ein hartes Problem löst. Weil man Geduld braucht. Als Beispiel gelte die Transition in einer Firma, in der ich selber gearbeitet habe und die ich selbst „mitgeleitet“ habe: Wir haben ca. 4-5 Jahre daran gearbeitet.

Und alles war schwer und hat gedauert und es war eine lange Reihe von Mikrofortschritten. Wir waren fröhlich und traurig, haben geschimpft und gestritten und und vertragen. Wirklich: nichts davon war leicht: Und am Ende – und nur im Rückblick war klar, dass wir etwas tolles geschaffen hatten.

Und wegen der Geduld auch etwas so tolles, wie ich es heute nicht alle Tage sehe. Den Lohn gibt es also nur in der Rückschau. Sisyphos eben. Aber glücklich.

1. Zum Thema Koexistenz von top-down und bottom-up, siehe auch den Podcast mit Michael Foley ↩

Um regelmässig über neue Inhalte informiert zu werden, melde dich gerne bei meinem Newsletter an. Danke!

Beim Newsletter anmelden

Hier aus der Intro:

„Kunden begeistern! Wer möchte das nicht? Und hat das nicht jede Firma in ihrer Strategie-Präsentation stehen? Best in Class, kundenzentriert, serviceorientiert. Und trotzdem sind wir selbst als Kunden nur selten begeistert. Was müssen wir also tun, wenn wir es ernst meinen?

Und: Hilft uns das alles überhaupt, Geld zu verdienen? Wo ist die Verbindung? Diese Fragen möchte ich hier beantworten. Dazu verwende ich ein sehr einfaches Modell: Das 3-Horizonte Modell [1] von Baghai, Coley und White (McKinsey, 1999). Das Modell erklärt, wie langfristig erfolgreiche Firmen vorgehen, um ihren Erfolg zu erhalten und nachhaltig zu wachsen.“

Der Artikel ist ein Rundumschlag zu allen Themen um das Entdecken neuer Angebote und Produkte für unsere Kunden.

• Kapitel 1 – das 3 Horizonte Modell nachhaltigen Wachstums
• Kapitel 2 – Konflikte aus Neuem und Bewährtem, Dringendem und Wichtigem
• Das Modell der Pioniere, Siedler und Stadtplaner
• Kapitel 3 – Wie entdecken wir neue und nützliche Produkte für unsere Kunden?
• Kapitel 4 – Beobachtungen aus dem Alltag und Tipps

Du kannst den Artikel kostenlos herunterladen, nachdem du dich für meinen Newsletter registriert hast. Den Download-Link findest Du dann in der Registrierungbestätigung.

Newsletter-Registrierung und Download

Und: jeder soll es wissen. Besser noch: Es soll auch jemand mitmachen! Am besten Deine Liebsten. Wie schön wäre es, das mal mit Deiner Familie zu machen?

Um beim Beispiel Sport zu bleiben – und es kann gar nicht einfach genug sein – nehmen wir Tischtennis. Draussen. Eine Tischtennisparty mitten auf dem Platz um die Ecke. Du siehst seht also, wie die Leute im Sommer, ohne nachzudenken, eine Tischtennisplatte rausstellen und einfach spielen. Wildfremde Leute – miteinander. Oh Mann, das juckt!

Auf dem Weg nach Hause stellst du Dir vor, wie cool das mit Deiner Familie wäre. Du kommst zu Hause an, erzählst in vollen Zügen und mit leuchtenden Augen was Du gesehen hast und wie cool es wäre, wenn ihr das auch machen könntet.

Und alle schauen dich an und sagen: „Hä? Na und?“

Und Du kannst nicht verstehen, wie man Dich nicht verstehen kann.

Tja, das ist natürlich der Weg, wie sie nie mir Dir Tischtennis spielen werden. Leider. Nicht mal weil sie böse sind, sondern weil – komischerweise – Begeisterung oftmals Ablehnung hervorruft. Nämlich dann, wenn die Begeisterung des einen so wirkt als würde sie Begeisterung beim anderen erzwingen wollen.

Und jetzt stellen wir uns einfach vor, die Menschen in dem Beispiel wären Abteilungen und Tischtennis stünde für Methoden, Arbeitsweisen, Ideen usw. Da wird schon einiges klar.

ich liebe Begeisterung, wir brauchen Begeisterung – ganz dringend. Wie könnte das Beispiel also funktionieren? Ich stelle die Tischtennisplatte einfach raus und lungere ein bisschen rum, bis andere unheimlich gerne mitmachen. Nachbarn? Freunde? Ganz andere? (Pro Tip: wenn nicht gleich viele mitmachen – verlässlich wiederholen.

Immer Dienstags, 18:00 Uhr Tischtennis draußen.) Dann habe ich immerhin einfach schon mal Spaß und lebe nebenbei vor, wie toll das ist. Das ist ja schon mal was und auch die Grundlage, dass überhaupt mal jemand mitmachen will, der mir wichtig ist. Weil ich jetzt zeige, wie cool das ist und nicht nur drüber rede und auch noch darauf warte bis mir jemand hilft mal anzufangen.

Und mit ein bisschen Glück macht auch mal jemand aus der Familie mit. Weil jetzt meine Begeisterung keine Verpflichtung mehr darstellt. Weil: Mir geht’s ja jetzt schon gut.

Und genau so geht das auch mit Methoden, Arbeitsweisen, Ideen. Wir erwarten gerne von anderen, dass sie mitmachen, uns helfen zu starten, es uns erlauben (viele gute Dinge brauchen keine Erlaubnis). Wahrscheinlich erinnern wir uns aber gar nicht mehr, wie oft wir schon andere Begeisterte alleine stehen gelassen haben. Das Paradox hat ja zwei Seiten.

Das Ganze ist natürlich ein blödes Paradox, aber besser wir wissen und verstehen es und arbeiten damit als wir wundern uns ständig darüber. Und: Wem wäre das nicht schon einmal passiert. Und wenn uns das schon im Kleinen passiert, wie sollte es im Großen (Firma, Agil, Skalieren, Methoden, Ideen) anders gehen?

Kurz: Begeisterung müssen wir erarbeiten und zwar meist subtil. Der direkte Weg führt meist zum Gegenteil: Ablehnung. So bitter das ist.

Anmerkung: Bald werde ich meine Blogposts und Podcast über meinen Newsletter bekanntmachen. Wenn Du über Posts informiert werden willst, oder über meine Trainings und Veranstaltungen, dann melde ich bitte hier an. Danke!

Beim Newsletter anmelden

Dieses mal haben sie Michael Sippey als Gast gehabt. Michael Sippey steht im Ruf „one of the blog inventors“ (einer der Erfinder des Blogs) zu sein und hat unter anderem bei twitter, Medium, Movable Type, Typepad, Vox (blogging social network), Live Journal, usw. als Product Manager gearbeitet.

Das Interview mit ihm ist so gut, dass ich innerlich ständig „ja, genau“ gerufen habe, manchmal vor Freude auf’s Lenkrad gehauen habe und mit gesagt habe, ein paar seiner Aussagen müssen aufgeschrieben werden. sie stehen da wie in Stein gemeißelt.

Hier also ein paar Zitate in nicht ganz chronologischer Reihenfolge:. Wo nötig, versuche ich jeweils ein wenig Kontext zu beschreiben um das jeweilige Zitat einschätzen zu können oder alles überhaupt in einen lesbaren Fluß zu bringen.

Michael Sippey’s Selbsteinschätzung

„Ich habe an vielen Produkten gearbeitet – manche haben funktioniert, manche nicht“.

Lasst euch das ein Trost sein, wenn es selbst Michael Sippey so geht! Die Bescheidenheit, die in dem Satz steckt ist aber auch schön zu hören.

Zum Komplex Ethik, Produkt und Geschäft

Zu dem Umstand, welche Rolle twitter im Arabischen Frühling gespielt hat, also zum Komplex Ethik, Produkt und Geschäft und was das für die Arbeit bedeutet, sagt er:

„People come to work everyday because you work on something you believe has a positive impact on people’s lives. And it’s empowering technology. And that’s the narrative you believe. And on the other side what you have this bug to take care of and this spec to write and this meeting to prepare for. So, holding these two things in your head at the same time is sometimes difficult“

Hauptaufgaben und Rolle des Produktmanagers

„The product manager if they’re any good is really some of it is idea generation but most of it is context setting. I always have to remind myself and have to remind product managers that really, you have as a product manager three questions that you need to be responsible for answering.Which is:

• What problem are we solving?
• Who are we solving it for? 
• And: how are we gonna measure success?

Everything else like how we gonna solve the problem, how we gonna bring it to the market, what are the needs it has from a feature perspective, or from a a speed perspective or where should the button go or how should it look or how should the brand work – that is a team exercise. And you get much better results if you involve the team. But it’s the Product managers job to set that context:

This is the problem we’re solving and here’s who we’re solving it for specifically and this is how we gonna measure success. ‚Cause if you can set that context and you can get it to the team, the team can get much better results.“

So einfach! So wahr.

Aufgabe von Management

Als Kommentar kommt dazu von Richard Ziade: „I have to say as I have grown as a professional and as a manager, it’s amazing how much of the work boils down to simple statements repeated almost daily. And as you say that, it sounds right: You would need to do that every day.“

Und ich kann hier nicht genug betonen, wie wichtig das ist. Ich sage den Product Ownern und Managern in meinen Trainings und Workshops immer wieder, wie wichtig es ist, in jedem Meeting, in jedem Sprint Planning die anstehenden Aufgaben immer und immer wieder in die Strategie einzuordnen und zu erklären „Weil wir als Firma die Vision X haben und im nächsten Jahr vor allem Y erreichen wollen, müssen wir im Produkt V mehr unterstützen.

Im nächsten Vierteljahr, bauen wir daher vornehmlich U und davon habe ich für den nächsten Sprint Features D, E, F und G vorbereitet.“ Das ist etwas ganz anders als einfach Features D, E F und G vorzustellen.

Definition von agiler Arbeit im Vorbeigehen

Nach einem längeren Sabbatical fing er für Ev Williams bei Medium an zu arbeiten und merkte was ihm wirklich Spaß macht. Und hier beschreibt er ungemein einfach und gut die Grundlagen von agiler Arbeit:

„Really what is great is that he gave me an opportunity to work with a really small team. I git to work with a couple of engineers and a designer, you know 4 or 5 people and we had our whiteboard and we put stickers pin it and we decided what we wanted to ship and then at the end of the week we looked at ourselves and said did we wanna ship or do we wanna ship at the beginning of the week? And I realized that is what I love.“

Über Größe im Scheitern: Talkshow

Sein letztes Projekt war eine gescheiterte Plattform namens Talkshow. Das Konzept war in etwa eine Live-Talkshow in Form von Textnachrichten vor Publikum. Das Konzept ist krachend gescheitert und wurde gerade zum Dezember hin eingestellt. Das Team hat die Arbeit eingestellt und die Dienste stillgelegt, obwohl sie noch Geld von den Investoren gehabt hätten und zugegeben, das es nichts werden würde, und das trotz bester Voraussetzungen:

MS: „We shipped 4 or 6 revisions. I am actually really proud of the team, because we shipped.“

Richard Zaide: „All the things you would’ve wanted for a launch to happen actually happened. The team shipped regularly, Apple endorsed the App. But still it didn’t get traction“

MS: „Yes, we shipped. And what I loved about what we shipped and what I love about the teaming which is why we still work together:“

MS: „We shipped and we shipped well and we shipped frequently and I think we shipped thoughtfully. And really, what it cone down to was … (and we got that by talking to our users and our audience) … it was the concept that was flawed. And, you know, that was 100% on me“

Über den Umgang mit emotional schweren Situationen

„And when we came to that realisation it was different in two ways: it was intellectually easy and emotionally difficult“

Auf die Frage wie er mit der schwierigen Situation umgegangen ist:

„There were definitely difficult days. What does it mean for my team? How do my investors take it? Some ego stuff like „what does it mean for my reputation? For most of the year I’ve been seeing a therapist. I feel like I’ve been incredibly lucky to be able to do that. That was helpful for me to get through the emotionally difficult part of it.

Things that really matter are 

• making things that you are actually proud of and
• making decisions that you are proud of
• and working with good people

These are the things that are priorities!“

RZ: „All founders should get their therapist“

Über Neuanfang, Zweifel und unvollständige Information

Gerade startet er mit dem selben Team und dem selben Geld ein neues Produkt und hier der Stand. Auch das ein tolles Zitat, weil er alles macht was man machen sollte:

„I don’t know what form the products going to take. We know generally the space we’re going after. We’re starting to learn who we’re solving problems for and what type of problems they have. So, I’m in kinda deep user research mode and at the same time we’re exploring some technology stuff. We’re kinda building and researching at the same time.“

Und trotzdem bleibt in der frühen Phase alles unklar und der Gründer oder product manager in eine frühen Phase muss ein bisschen verwegen und verblendet sein, weil man sich sonst jeden schwierigen Anfang ausredet:

„As a founder you have to be kinda delusional because you can be talked out of anything. At a certain point, you have to believe.“

Und:

„You’re never gonna have perfect information. We do a whole bunch of user research and interviews. But at a certain time you gonna have a whole bunch of grey.“

So, das war’s. Ich denke, die meisten Zitate „kommen erst richtig an“, wenn man das Podcast hört. Wenn es dich jetzt richtig interessiert, dann leg hier los. Ich habe selten so ein Interview aus der Tech-Welt gehört das so auf den Punkt und gleichzeitig so offen ist.

Digitale Produkt Manager haben tiefes technisches Verständnis

Was mir noch auffällt: Von der bei uns so verbreiteten „Trennung“ zwischen Business /Product und Entwicklung ist hier nichts zu spüren. Im Gegenteil: Michael Sippey scheint Technik zu atmen und Energie und Nutzen daraus zu beziehen.

Anmerkung: Bald werde ich meine Blogposts über meinen Newsletter bekanntmachen. Wenn Du über Posts informiert werden willst, oder über meine Trainings und Veranstaltungen, dann melde ich bitte hier an. Danke!

Beim Newsletter anmelden

Foto von Christopher Michel, some rights reserved.

Später hat er die Agentur VaynerMedia gegründet, die anderen Firmen hilft über Social Media erfolgreich zu sein. Heute ist er vor allem seine Marke, Entrepreneur, Buchautor und Public Speaker. Seit ein bisschen mehr als 100 Folgen betreibt er das Vlog DailyVee (und auch Ask GaryVee). Hier Folge 101, ein Zusammenschnitt seiner ersten 100 Folgen, offenbar geschnitten von einem Fan.

13 Minuten GaryVee, DailyVee, Folge 101

Für Mitteleuropäer kann seine Duracell-Energie zugegebenermassen ein bisschen anstrengend ein. Immerhin gibt es auch immer wieder Ruhephasen, die er nutzt um Empathie für sein Publikum aufzubringen. Und nein, ich schaue mir das Blog nicht regelmässig an. Mir geht es um etwas anderes: Es ist interessant was er sagt und mindestens so interessant ist das was er nicht sagt:

Einige der Kernaussagen aus diesen 13 Minuten:

• Sich beschweren und eine Opferhaltung helfen nicht weiter.
• Geld von ein paar alten Männern in einem Gremium bekommen ist immer noch leichter als am Markt zu bestehen („the market makes old dudes that are white and racists seem soft“, „winning at the market way harder than getting some old dudes to give you a check“)
• Harte Arbeit ist Punkt 1, 2 und 3 in der Erfolgsformel („hard work is the 1st, 2nd and 3rd part on the winning formula“,“no one knows a single person that is successful without the work“ oder in meinen Worten „Es gibt keinen kurzfristigen Erfolg“, „there is no overnight success“)
• Speed ist 4 Milliarden mal wichtiger als Perfektion (um neue Optionen zu eröffnen)
• Beide Extreme zusammen sind wichtig: Unglaubliche Geduld auf der einen und unglaubliches Pushen auf der anderen Seite. In nur einem davon gut zu sein reicht nicht, man braucht beides.
• Doing the right thing is always the right thing (an anderer Stelle: „Karma is practical“)

Worüber er nicht spricht:

• Prozesse,
• Innovations_theorie_,
• das Lesen von 30 Büchern.
• Welche Theorie ist besser?
• Welcher agile Prozess ist besser?
• Welche Organisationsform ist am besten geeignet um XYZ zu lösen?
• Prozessoptimierung, usw.

Er lässt also all die Diskussionen Streits und Infos, die unseren Alltag dominieren, weg. Was er sagt ist einfach bauernschlau. Und wahrscheinlich ist genau das richtig. Firmen haben zu viel von dem was er nicht sagt und zu wenig von dem was er sagt.

Und das ist der Punkt, den ich hier machen will (und ich nehme mich nicht aus): Wichtig und entscheidend ist das Mindset und die Einstellung hinter Innovation (und auch Agile und Kanban). Insbesondere das Aufgeben der Opferhaltung und das Annehmen der Gestaltung.

Aufstehen wenn Fehler passiert sind und Weitermachen, Akzeptieren von Rückschlägen. All das kann man auch bauernschlau hinbekommen und einfach leben. Unternehmen und Abteilungen sind besser unterwegs, wenn sie vom Entrepreneurspirit getrieben sind und deswegen Fehler machen als wenn sie überreguliert langsam alles richtig machen.

Wahrscheinlich ist der Punkt dieses Textes, dass man über das Video nicht schreiben sollte, sondern es einfach ansehen 😉 Kurz: ein bisschen mehr GaryVee, ein bisschen weniger Corporate kann nicht schaden.

Anmerkung: Bald werde ich meine Blogposts über meinen Newsletter bekanntmachen. Wenn Du über Posts informiert werden willst, oder über meine Trainings und Veranstaltungen, dann melde ich bitte hier an. Danke!

Beim Newsletter anmelden

Dazu fiel mir eine kleine Übung ein. Ich weiss nicht ob es diese Übung schon gibt und ob sie fair ist oder nicht. Ich weiss aber, dass sie sich so anfühlt wie die Planungen, die ich früher lange genug für Komponententeams machen musste, bevor ich endlich mit Featureteams arbeiten durfte.

Ich will an dieser Stelle auch gar nicht darauf eingehen, wie schwer es ist zu Featureteams zu kommen. (Ich weiss es 😉 Ich will hier auch nicht auf die Hemmnisse eingehen, die einen davon abhalten können, oder auf die gefühlten Nachteile und die daraus entstehenden bangen Fragen, wie „Ist das noch die selbe Qualität? Verlieren wir nicht unser Spezialwissen?“

Hier also die Übung (siehe Titelbild):

Es gibt vier Komponententeams: Rot, Blau, Grün und Gelb. (Rot könnte z. Bsp. für Backend, Datenbank, Payment API oder was auch immer stehen, Blau für Business Logik, Advertising, SAP Anbindung oder was auch immer stehen).

Die Teams sollen gemeinsam vier Features abarbeiten. Die Tasks sind oben in ihrer notwendigen Reihenfolge als farbige Kärtchen aufgeführt. (Ergebnis eines SAFe PI Planning?) Die Zahlen in den Tasks sind – der Einfachheit halber – die Schätzung in Tagen.

Die Aufgabe ist es nun, die Planung für meine 4 wichtigsten Features zu machen und mir die einfache Frage zu beantworten: Wie arbeiten die Teams die Features ab? Die Regel ist natürlich: das erste Feature soll erst geliefert werden, das vierte zuletzt. Eigentlich reicht mir die Antwort, wann die Features jeweils kommen.

Wer mir noch zeigen kann, wie die Teams sich Ihre Aufgaben schnappen, kann das gerne tun. Das Schöne an der Situation: Wir haben fertig geschätzte tasks und Du kannst gerne davon ausgehen, dass diese korrekt sind Du hast fünf Minuten Zeit für diese einfache Übung.

Fertig? Bedenke: Die Aufgabe ist also ein vollkommen vereinfachter Laborversuch in der Planung von lediglich vier perfekt vorbereiteten Features. Verrückterweise ist diese Übung trotzdem schwer. Keins der Teams konnte die Übung beantworten. Ich weiss, dass man das lösen kann. Der Punkt ist einfach wie schwer diese einfache Übung ist.

Als kleine didaktische Komplikation könnten wir überlegen, was es bedeutet umzuplanen, weil Änderungen in den Schätzungen eintrudeln:

Aufgabe Nummer 2 – sich ändernde Schätzungen

• Feature 1: die erste Task, Team Rot, geht schneller und dauert nur 2 statt 5 Tage.
• Feature 2: die zweite Task, Team Grün dauert 4 statt 3 Tage
• Feature 3: die erste Task, Team Rot, dauert länger: 5 statt 3 Wochen.

Die Nettoarbeitszeit bleibt also (zufälligerweise) sogar gleich: Wann sind die Features jetzt fertig?

Aufgabe 3 – Veränderte Prioritäten

Noch eine – realistische – Komplikation könnte Neuplanung aufgrund von Repriorisierung sein: Feature 3 wird das wichtigste und Feature 1 übernimmt seine Position. Was passiert jetzt? Wann sind die Features fertig? jedes einzelne und alle gesamt? Und: Wie würde die Planung für 4 Featureteams aussehen?

Beim Ausdenken der einfachen Aufgabe hat es mich noch einmal fast umgebracht, wie kompliziert die Planung in diesen Abhängigkeiten ist.

Und plötzlich wusste ich wieder, warum ich diese Art der Planung nicht mag (wenn auch nicht verdamme, denn ich weiß, dass sie in vielen Umgebungen einfach noch nötig ist). Aber der Charme von Flow und forecasting wird doch wieder sehr klar.

Anmerkung: Bald werde ich meine Blogposts über meinen Newsletter bekanntmachen. Wenn Du über Posts informiert werden willst, oder über meine Trainings und Veranstaltungen, dann melde ich bitte hier an. Danke!

Beim Newsletter anmelden

Das kann man glauben oder nicht, es ist erst einmal der Plan. Der Antrieb kommt vom Problem: Elon Musk möchte den Mars besiedeln. Weil es schwer ist, aber sicher auch weil er damit einen Weg aus den Massenproblemen auf unserem Heimatplaneten sieht, eventuell auch, weil er den Weg in eine Typ 1 oder sogar Typ 2 Gesellschaft aufzeigen will.

Jetzt zu unserer kleinen Geschichte: Ein Team hat eine tolle Produktidee. Nach Wochen des Forschens stellt es fest, dass der Preis für das neue Produkt um den Faktor 10 zu teuer ist um auf dem Markt akzeptiert zu werden. Große Enttäuschung setzt ein: So ist das nicht machbar. Was tun?

Man könnte jetzt aufgeben und zum Chef gehen und sagen: „Wir haben es uns angeschaut, es geht nicht, mit unserem Budget ist das nicht machbar, die Risiken sind nicht überschaubar“. Aber: Das ist gerade der Witz der Sache. Jetzt fängt die Arbeit an: Welche Kompromisse können wir machen?

Welche ganz anderen Lösungen für das Problem gibt es? Können wir es anders finanzieren? Wer könnte zusätzlich zahlen? Manchmal hilft es auch, das Problem zu vergrößern und zu sagen: Was wenn wir es noch 10 mal billiger machen müssten? So kann man auf bis jetzt undenkbare Lösungen kommen. Wie können wir unbedingt (weil wir es lieben) das gefundene, wichtige Problem anders lösen?

Voraussetzung für all das ist „in das Problem verliebt zu sein“ und nicht in die Lösung. Um so arbeiten zu können brauchen wir also erst einmal ein Problem, dass wir für existent und wichtig genug halten und möglichst sogar schon validiert (also im echten Leben beobachtet) haben. So einfach es klingt, so wenig selbstverständlich ist das in meiner Beobachtung in den meisten Firmen.

Dieser Blogeintrag stammt ursprünglich aus meinem (inzwischen fast monatlichen) Newsletter – wenn er dich interessiert, kannst Du ihn hier abonnieren! Ich würde mich freuen.

Bildrechte: Jack Thurston [CC BY-SA 2.0], via Wikimedia Commons

Im Februar war ich wieder zu Gast bei meinen Freunden von sipgate. Neben meinem längeren Talk bei der Lean DUS 14 wurde ich auch von Michael Neudert zum Thema Innovation interviewt.

Michael führt eine Reihe namens „Arbeit aber anders!“, in der er sich mit aktuellen Themen zum Arbeitsalltag auseinandersetzt, aber auch die Speaker der Veranstaltungsreihe Lean DUS interviewt.

Das kam mir sehr gelegen, denn es ist (für alle Beteiligten 😉 doch mal schön, sich im Rahmen eines gezielten Interviews ein bisschen kurz fassen zu müssen und damit auf den Punkt zu kommen.

Der Untertitel „Innovation ist planbar“ ist sicher ein bisschen irreführend – da die Planbarkeit eine andere ist als die Planbarkeit etwa eines Werkstatttermins. aber es doch was dran, da wir ja inzwischen doch einiges darüber wissen, wie Innovation machbar ist, bzw. welche Bedingungen dafür in Unternehmen herrschen müssen.

Eine Erfolgsgarantie gibt es natürlich und leider nicht. Und auch das was wir darüber wissen sagt uns eher, dass Innovation doch eher eine echte Herausforderung ist.

Erwähnt werden im Interview u.a. das 3-Horizonte-Modell und das PST-Modell (Pioniere, Siedler, Stadtplaner – Pioneers, Settlers, Town Planners) von Simon Wardley.

Aber seht selbst, hier das Interview von Michael „Arbeit aber anders“ Neudert mit mir zum Thema Innovation.

Vielen Dank noch einmal an Michael und alle bei sipgate, die Lean DUS zu einer großartigen Serie machen! Speziell auch die fantastische Küche von sipgate!

Diese Woche habe ich ein Interview mit Tomer Sharon geführt. Hier der Hintergrund.

Vor einiger Zeit habe ich Tomer’s Buch „It’s our research“ gelesen und war begeistert davon, wie einfach er User Research darstellt. Die meisten Bücher zu dem Thema – und ich weiss nicht warum das so ist – versuchen aus User Research ein Geheimnis und etwas Heiliges zu machen, dass nur wenigen vorbehalten ist und in dem man sooooo viel falsch machen kann.

Und natürlich ist es richtig, dass Interviews, Beobachtungen usw. aufgrund der eigenen Prägungen, der Verliebtheit in die eigenen Ideen usw. hart ist. Ich liebe aber Tomer’s Ansatz, es einfach zu machen.

News

Vor zwei Jahren habe ich dann Tomer in NY getroffen (diesen Vortrag hat er dort gehalten, ein tolles Beispiel anhand der Kultur der WWE, wie man Research erzählen kann) und im Anschluss auch eines seiner Trainings in Berlin organisiert.

Seitdem ist viel passiert. Tomer hat google verlassen und arbeitet jetzt bei WeWork. zudem hat er gerade sein zweites Buch „Validating Product Ideas“ veröffentlicht. Grund genug, dass wir uns unterhalten haben.

Seht selbst.

2009 fanden Stefan Roock und ich heraus, dass es nützlich sein könnte, Kanban auf Portfolio-Ebene einzusetzen. Wir sind einfach über die Gelegenheit gestolpert. Ursprünglich wollten wir eigentlich Releases mit einem Kanban-artigen System koordinieren, aber wir hatten das Gefühl, dass das auf dieser Ebene ohne einen strategischeren Blick nicht viel hilft. Zu koordinieren war hier bereits zu spät, zu weit stromabwärts. Reaktiv. Dann dachten wir eines Tages: „Wäre es nicht großartig, wenn wir jederzeit und auf globaler Ebene einfach wüssten, welches Projekt als nächstes starten sollte?“ Was wir auf lokaler, Projektebene tun konnten – das beste nächste Feature ziehen –, wollten wir auf globaler Portfolio-Ebene tun können: das nächste, wichtigste und wertvollste Projekt ziehen – ohne zu raten oder in Diskussionen zerrieben zu werden. Das war eher ein soziales als ein „technisches“ Problem: Keiner der Stakeholder konnte für sich allein helfen. Denn natürlich musste in bilateralen Meetings jeder Stakeholder sein Projekt für das wichtigste halten.

Natürlich durften wir Portfolio-Boards im Konzernumfeld nicht sofort einsetzen. Nach einigen Experimenten stellte ich das Konzept 2010 auf der LKBE in Antwerpen einer noch neuen, frischen und jungen Kanban-Community vor. Eine Angst, die mich bei der Vorbereitung des Vortrags trieb, war, dass es womöglich nicht als Kanban gelten würde. Was ich zeigte, war zwar ein WIP-begrenztes Pull-System, aber es sah nicht so aus. Die WIP-Limits waren auf meinem Board nicht explizit gemacht – und explizit über WIP-Limits zu sein, war in den frühen Tagen das große Thema. Natürlich standen einige auf und stellten die bohrenden Fragen, ohne mich jedoch vorzuführen. David Anderson stand auf, verstand das Konzept sofort und verteidigte damit seine Konstruktion, die viel abstrakter war als Kanban auf Ticket- oder Feature-Ebene. Erleichterung machte sich breit. Da Arne und Henning gerade dabei waren, Davids epochales Buch Kanban ins Deutsche zu übersetzen, fragte mich David, ob ich das in Antwerpen Präsentierte aufschreiben und als zusätzliches Kapitel für die deutsche Übersetzung beisteuern könnte. Er gab mir den sehr wichtigen Hinweis, das Thema soziales Kapital mitzudenken – wie recht er hatte. Aber lies weiter. So entstand eine schöne Beschreibung des grundlegenden Aufbaus eines Kanban-Systems für Portfolio-Entscheidungen.

Seitdem ist viel passiert. Ich habe mich nicht sehr auf das Thema konzentriert und die Kontrolle und den Einfluss darauf ein Stück weit verloren. Auf der positiven Seite ist das Thema schnell gewachsen und skaliert. Sogar so weit, dass SAFe das Konzept auf Portfolio-Ebene nutzt. (Mach daraus, was du willst. Ich habe dazu keine Meinung.) Auf der negativen Seite ist das Konzept noch immer schlecht dokumentiert. Schlimmer noch: Es scheint, dass jeder ein anderes Konzept von „Portfolio“ im Kopf hat. Auch scheint jeder einen anderen Zweck für ein Portfolio-Board im Sinn zu haben. Die meisten sehen einen Bedarf, ein Portfolio, Programm oder eine Abteilung mit dem Board zu überwachen. Ich nicht. Das sind andere Boards, andere Tiere.

Außerdem habe ich seither viele Portfolio-Boards gesehen, die schnell implementiert wurden und ebenso schnell degenerierten. Der Grund war fast immer, dass einige geheime, undokumentierte Zutaten nicht Teil des Systems waren. Deshalb gebe ich hier ein paar Hinweise auf einige der grundlegendsten – nicht der fortgeschrittensten – Rahmenbedingungen eines Portfolio-Boards. Tatsächlich so grundlegend, dass sie nie wirklich erwähnt werden.

Von meinem Kapitel in Davids deutschem Buch gibt es keine englische Übersetzung. Worauf ich dich von meiner Seite also verweisen kann, ist dieser tiefere, längere Artikel auf InfoQ, damals schön redigiert von Ben Linders. Er geht in die Tiefe und behandelt Innovation, die Horizonte 1–3, Design Thinking und vieles mehr. Leider lässt er auch alle Grundlagen aus und ist eher Stoff für Fortgeschrittene.

Was ich heute schreibe, ist eine Erklärung einiger weiterer undokumentierter Features oder Rahmenbedingungen eines Portfolio-Board-Systems. Mir liegt vieles auf dem Herzen, aber ich versuche, es ab hier kurz und einfach zu halten.

Einführung – Was ist ein Portfolio-Board?

Ein Portfolio-Board ist ein WIP-begrenztes Pull-System für Entscheidungen auf Portfolio-Ebene. Ich nenne es nicht mehr Portfolio Kanban, wenn ich nicht dazu gezwungen werde. Das Publikum, das das Konzept anspricht und dem es hilft, kümmert sich nicht sonderlich um Kanban – oder schlimmer, es wird eher durch die Überladung des Kanban-Begriffs in Produktion und Wissensarbeit abgelenkt. Bitte fühl dich davon nicht beleidigt, in meinem Umfeld ist es eine Notwendigkeit.

Was meine ich mit Portfolio? Damit meine ich die Gesamtheit aller übergeordneten Projekte, Produkte, Services und Aktivitäten, die ein Unternehmen braucht, um seine Strategie zu stützen und umzusetzen. In diesem Sinne hilft ein Portfolio-Board, die Strategie eines Unternehmens zu operationalisieren. Ich betrachte ein Portfolio-Board und all seine Erweiterungen als großartiges Werkzeug für Strategy Deployment. Tatsächlich ist das Board die Visualisierung der Strategie eines Unternehmens. Wenn nicht, erfüllt es seine Aufgabe nicht.

Gute Portfolio-Option

Schlechte Portfolio-Option

Im Grunde managt man ein Portfolio, indem man Optionen schafft und managt. In einem gesunden Portfolio sollte die Mehrheit der Optionen die Eigenschaft haben, ein starkes bis unbegrenztes (wenn auch möglicherweise unbekanntes) Aufwärtspotenzial zu bieten (the sky is the limit), aber ein sehr begrenztes Abwärtsrisiko (oder Kosten). Wenn du das Portfolio deines Unternehmens so managst, muss sehr viel schiefgehen, damit du komplett scheiterst. Trotzdem ist es harte und kollaborative Arbeit. Um das zu unterstützen, haben wir – voilà – das Board und sein umgebendes System.

Während ich über Kollaboration rede: Was wir mit dem Board tun, ist, ein System anzubieten, mit dem Leute im Unternehmen schnell die Entscheidungen von stromaufwärts ziehen können, die sie brauchen, um sinnvoll an der Umsetzung der Strategie zu arbeiten. Das ganze System ist darauf gebaut, unternehmensweit schnell und taktisch entscheiden zu können. So haben wir ein Werkzeug, um alle notwendigen Maßnahmen im Unternehmen entlang der gewählten Strategie auszurichten.

Tatsächlich ist eines der größten Probleme beim Aufsetzen eines Portfolio-Boards, dass eine Strategie noch nicht explizit gemacht ist. (Falls noch keine Strategie explizit ist, lies einen der allerletzten Sätze dieses Beitrags für einen Hinweis.)

Um es klarer zu machen, hier ein Bild eines Portfolio-Boards. Während ich in abstrakten und komplexen Begriffen rede, ist das Board selbst einfach! Sieh:

Ein einfaches Portfolio-Board

Bevor wir weitermachen, eine kurze Erklärung, was ein Portfolio-Board und sein Zweck nicht ist.

Der Zweck von Portfolio-Boards

Portfolio-Boards sind nicht dazu gedacht, komplexe Lebenszyklus-Prozesse von Projekten, Produkten, Services oder Aktivitäten in deinem Unternehmen zu überwachen. Wenn du das möchtest, ist das völlig in Ordnung, aber mit einem Portfolio-Board geht das nicht. Es ist auch kein Programm-Management-Tool. Auch das kannst du tun, aber es ist kein Portfolio-Board. Du kannst viele Dinge tun, die ähnlich aussehen, aber ein Portfolio-Board ist und fühlt sich völlig anders an.

Bei einem Portfolio-Board geht es nicht um Prozesskontrolle, sondern darum, strategische Ausrichtung zu gewinnen und die Strategie im Unternehmen zu betreiben, indem du all deine Teams unterstützt – dadurch, dass du ihnen rechtzeitig Entscheidungen im Pull-Verfahren bereitstellst.

Bei einem Portfolio-Board geht es auch nicht um Kapazitätsplanung. Eine weitere Anforderung, die für Unternehmen oft entscheidend ist, aber wiederum nicht Sache eines Portfolio-Boards. Sorry. Ich unterstütze und verstehe all diese Bedürfnisse voll und ganz, und du kannst und solltest das alles tun. Es ist nur gefährlich, es zu tun, indem du all diese Aspekte in das Portfolio-Board-System integrierst. Dein Portfolio-Board wird durch das Einmischen dieser Aspekte völlig verwässert. Tu das nicht.

Hauptgang – ein paar geheime Zutaten

Jetzt endlich kommen die Hauptzutaten, die ich in den Fällen beobachtet habe, in denen das Board seine Arbeit tut:

1. Das Board muss in einer sehr hochfrequenten Taktung besprochen werden. Meine bevorzugte Taktung ist tatsächlich wöchentlich. Ich meine es ernst. Hol alle Leute, die du für Portfolio-Entscheidungen brauchst, wöchentlich in einen Raum. Es klingt hart. Aber es ist ein Muss. Lies weiter, um zu verstehen, warum. Als Extrem könnte ich zweiwöchentlich als Herzschlag des Boards akzeptieren. Alles darüber hinaus heißt: Fang mit PB gar nicht erst an. Ich meine das wirklich absolut todernst. Normalerweise höre ich an diesem Punkt, dass die Leute das wirklich gern tun würden und die Notwendigkeit absolut verstehen, aber genau hier, in diesem Unternehmen, würde es so nicht funktionieren. Das höre ich über die meisten großen Durchbrüche: „Wir lieben es, aber hier geht das nicht!“ Das ist für mich in Ordnung, aber dann machst du eben nicht die harte Arbeit. Es ist dein Leben, du musst dich also nicht bei mir rechtfertigen. Sag nur hinterher nicht, es habe nicht funktioniert, okay?

2. Da ich gerade die lächerliche Forderung aufgestellt habe, alle VIPs deines Unternehmens, die für Portfolio-Entscheidungen nötig sind, jede Woche vor ein sehr simplizistisches Techie-Board zu holen, mache ich es mir zur Pflicht, keine Zeit dieser Leute zu verschwenden und das Meeting total, absolut kurz zu halten. Für mich heißt das etwas um die 15–20 Minuten. Ich höre dich: Auch das ist in deinem Fall unmöglich. Nochmal: Das ist für mich okay, aber dann fang lieber nicht an. Es macht keinen Sinn, Dinge länger als das zu besprechen. Aber es macht alle Welt Sinn, Dinge so kurz zu besprechen und alle nötigen Informationen sehr knapp und präzise bereitzustellen.

3. Misch keine Monitoring-Aspekte hinein. Das 15-Minuten-Meeting ist ein reines Entscheidungs-Meeting. Es ist kein Monitoring- oder Status-Update-Meeting. Dinge werden einfach entschieden. Und nur Themen, die gezogen werden. Deshalb kann es in 15 Minuten funktionieren. Es ist ein 15-Minuten-Meeting ohne Müll, ohne Verwirrung, ohne Bullshit, ohne Politik, um die dringendsten Portfolio-Themen zu entscheiden. Projekt A oder Projekt B? Produkt-Inkrement F vs. Service-Initiative K? Wir haben in drei Wochen einen schönen 14-tägigen Produktentwicklungs-, F&E- oder XYZ-Slot frei. Was tun wir damit? Nochmal: Ich höre dich. Du hast all diese Leute im Raum. Sie lechzen nach Monitoring, Status-Updates usw. Rede morgen Abend bei einem Kaffee mit ihnen, werde ohnehin besser darin, transparent über deinen Status zu sein, damit sie nicht nach all den Informationen lechzen, die sie sowieso zur Hand haben sollten.

   ABER.BITTE.MISSBRAUCH.DIESES.MEETING.NICHT. (Sorry, ich wollte dich nicht anschreien!) In diesem Meeting geht es darum, Entscheidungen in einem WIP-begrenzten Pull-System für Portfolio-Entscheidungen zu treffen, erinnerst du dich? (Sorry, ich wollte nicht klingen, als würde ich mich ständig wiederholen.) Und nochmal: Sag mir, dass es bei dir nicht möglich ist. Dann.fang.nicht.an. Ist okay. Arbeite darauf hin. Ich weiß, wie verlockend es ist, dasselbe Meeting zu nutzen, um tolle Botschaften rüberzubringen, zu berichten, wie großartig die Leute sind, wie viel schwieriger die Dinge waren als erwartet und so weiter. Es ist einfach nicht der richtige Ort. Glaub mir! Es wird großartig sein, eine Entscheidung zu haben statt eines gemischten Reporting-Entscheidungs-Meetings.

4. Besprich nur Dinge, die zu besprechen sind – bei denen Teams die Entscheidung oder das Status-Update brauchen. Besprich nicht das ganze Board. Besprich nicht alle Initiativen darauf.

   Zeige nur Details, die du diskutieren willst. Menschen neigen dazu, zu allen Details eine Meinung zu haben und sich an den feingranularsten Details mit Meinungen festzuhängen. Das limitiert dieses Meeting und zieht es zu sehr auf die taktische Ebene. Filtere gut, was du zeigen willst.

5. Wer auch immer das Meeting moderiert, braucht dafür ein starkes Mandat vom CEO. Er wird CEO-Fragen stellen müssen. Tut er das ohne ausdrückliches Mandat, wird ihn dieses Meeting zerreißen. Im Ernst. Hol dir ein Mandat für CEO-Fragen, wenn du das Meeting moderierst. Es könnte sogar eine gute Idee sein, den CEO das Meeting selbst moderieren zu lassen. Das wäre ein Zeichen. Ich verstehe, dass das in deinem Fall vielleicht nicht möglich ist. Dann hol dir dieses Mandat, wenn du der Draufgänger bist, der dieses Meeting moderiert. (Es macht Spaß, glaub mir!)

6. Nur für Fortgeschrittene, aber wichtig: Trenne die Horizonte voneinander – Horizont-1-Optionen werden Horizont-2- und -3-Optionen töten, wenn sie im selben Meeting besprochen werden! (Ja, mehr Komplexität …) Lies den InfoQ-Artikel für mehr dazu.

Ein paar grundlegende Checks

Hier ein paar grundlegende Checks auf Gerüche, die ich oft in Implementierungen beobachte, die nicht funktionieren oder schnell degenerieren:

• Wenn deine Portfolio-Ebene viele Spalten hat, riecht es nach Prozesskontrolle statt nach großen strategischen Entscheidungen. Siehe das obige Beispiel für empfohlene Einfachheit.
• Wenn das Board keine Lanes (oder Zeilen) hat, scheint es, dass du keine strategischen Themen auf das Board gemappt hast. Sie gäben gute Lanes ab.
• Wenn die Lanes nach Teams benannt sind, scheinst du Teams zu managen, nicht das Portfolio bzw. die strategischen Themen.
• Wenn dein Board explizite WIP-Limits trägt, fühlst du dich vielleicht gut und als wahrer Kanban-Jünger, aber Manager werden dich schräg anschauen. So funktioniert es nicht. Wichtig ist, dass das System implizit WIP-begrenzt ist. Diskutiere, ob noch etwas möglich ist oder nicht, aber pappe keine Zahlen ans Board. Portfolio-Initiativen sind zu unterschiedlich in Größe und Komplexität, besonders über verschiedene Phasen hinweg, um sich an explizite WIP-Limits zu halten. Auch sozial wirkt das in diesen Kreisen wie Prozessideologie statt kunstvoller Portfolio-Entscheidungen.

Ich mache all diese Punkte, um klarzumachen, wie ein Portfolio-Board gedacht ist und wie es funktionieren wird. Wenn du noch nicht so weit bist, arbeite darauf hin. Aber starte die Sache nicht, ohne Rückhalt für all die Grundlagen zu haben. Du wirst starken Rückhalt bei diesen Punkten brauchen. Es wird harte Tage geben, harte Entscheidungen. Wenn es kein Vertrauen in dich bei diesen Themen gibt, werden du und das Board harte Diskussionen nicht überleben. Das Board wird Menschen unter Stress im Weg stehen. Denk daran, dass die meisten Methoden oder Werkzeuge einen Schuss bekommen. Also sei besser vorbereitet. Du hast nur einen Schuss, um damit zu starten. Wenn es zu schnell degeneriert, wird die Methode beschuldigt, nicht dein lokaler Ansatz. Es wird einen Rückfall und keine zweite Chance geben. Verpass diese Gelegenheit nicht und sei vorbereitet.

Sobald du dein Umfeld vorbereitet und die grundlegenden Zutaten beisammen hast, werden wunderbare Dinge passieren. Die ersten paar Meetings mögen etwas unbeholfen sein. Aber nach einer Weile wirst du die Erleichterung eines sehr fokussierten Entscheidungs-Meetings spüren. Was passieren wird: All deine VIPs werden sich, indem sie die anstehenden Entscheidungen diskutieren, implizit auf eine Interpretation der Strategie und ihrer Umsetzung ausrichten. Und da sie wichtige Multiplikatoren sind, wird dein Unternehmen eine Interpretation der Strategie leben können – wenn die Botschaften aus dem Meeting durchs Unternehmen getragen und über all deine anderen Boards auf Abteilungs- und Team-Ebene betrieben werden. Du wirst ein perfekt ausgerichtetes System von Boards auf allen Ebenen haben, alle ausgelöst durch die strategischen und taktischen Entscheidungen auf Portfolio-Ebene.

Ein kleiner Hinweis und eine Beobachtung: Du kannst dein Board starten, ohne eine explizite Vision und Strategie zu haben. Das wird sehr bald ein Diskussionspunkt sein. Ohne Vision und strategische Eckpfeiler werden die meisten Entscheidungen auf Meinungen beruhen. Diese Meinungen lassen sich ohne das starke Fundament einer Strategie nicht auflösen. Der Wert jeder Initiative hängt stark vom Kontext der Strategie und ihrer gemeinsamen Interpretation ab. Ein Portfolio-Board im luftleeren Raum führt dazu, dass Leute nach einer Strategie schreien. Sei auf diesen Moment vorbereitet! (Zum Beispiel: Ruf mich dann an 😉)

Noch ein pragmatischer Hinweis: Die Leute werden dir sagen – und du wirst denken –, dass es am Anfang schwer sein wird, das Board zu füllen. Die Leute und du werden denken, es gäbe riesige Diskussionen über die Priorisierung der Initiativen auf dem ersten Board. Es wird einfacher sein, als du denkst. Menschen benehmen sich, wenn sie an einen Tisch gesetzt werden. Das ist eine der grundlegenden Zutaten des Ganzen: Alle Leute in einem Raum zu haben, die entscheiden müssen, führt dazu, dass Leute entscheiden. Das ist anders, als mit allen Parteien in Eins-zu-eins-Situationen zu reden. Der harte Teil am ersten Board wird die Erkenntnis sein, dass viel zu viel läuft – und dass die ersten Entscheidungen darüber sein werden, welche Initiativen man killt.

Bitte schick mir Feedback, wo Dinge noch unklar sind! Ich baue Updates auf Basis davon in diesen Beitrag ein. Nimm das als ein Kind, das noch erwachsen werden muss. Danke!

Viel Spaß!

Ich bin in der letzten Zeit öfters über einen blinden Fleck gestolpert: dass wir bei der Arbeit oftmals zu viel Zeit rein funktional verbringen und zu wenig Quality Time miteinander verbringen. Das lässt vieles effizient aussehen, hinter den Kulissen aber ist es duster. Ich will das an zwei Beispielen aus der Praxis erläutern, die mir in den letzten Monaten begegnet sind.

Der Konzern

Im ersten Beispiel haben gute, erfahrene Leute aus Deutschland die Aufgabe einen Multinationalen Konzern zu lenken, der hochgradig auf andere Länder verteilt ist und mehr zusammenwachsen sollen. Das zwingt zu einer Art Management, die geprägt ist von häufigen und tiefgreifenden Veränderungen in den Ländergesellschaften.

Die deutschen Manager fahren in die anderen Länder, arbeiten dort mit den Ländergesellschaftern und bauen sich im Laufe der Zeit eine Gruppe vertrauter Mitarbeiter auf. Aber auch nach Monaten war die Beobachtung, dass irgendwie etwas fehlt. Neue Pläne werden in Workshops gemeinsam erarbeitet und dann auch umgesetzt.

So fährt man in eine nach der anderen Ländergesellschaft und versucht dabei auch ein Modell von Empowerment und Mitdenken statt Befehlsübergabe und -empfang umzusetzen und vorzuleben. Aber irgendwie springt der Funke nicht über. Es werden ganze Tage damit verbracht, in Retrospektiven die Teams sich selber verbessern zu lassen und damit Delegation der Verbesserung in die Teams selbst geschehen zu lassen. Man macht alles „richtig“, Aber irgendwie springt der Funke nicht über.

An dieser Stelle wurde ich gefragt was man denn verbessern könne. Und mir fiel relativ plötzlich auf (erst jetzt, weil: blinder Fleck!), dass aus Sicht der Mitarbeiter das Ganze sicher ehrlich wirkt, aber nicht ganz nachvollzogen werden kann. Wir kamen dann darauf, einfach einmal ohne Plan und ohne Absicht in die Ländergesellschaften zu fahren und einfach zu feiern oder zu reden oder Mittag zu essen oder Bier zu trinken oder … Ich denke, dass es hier (und sicher in vielen vielen anderen Fällen) wichtig ist, einmal nichts zu wollen und sich einfach als Menschen kennenzulernen.

Für die Mitarbeiter im Ausland wirken wir Deutsche sicher als hoch gestresste Manager, die ins Land einfliegen, Wünsche äußern (wenn auch auf sehr nette Weise)  und dann auf Selbststeuerung warten. Die Selbststeuerung, die ständig von uns betont wird, wird dabei zum einen sicher als von uns als effektivste Arbeitsform empfunden.

Zum anderen nimmt weiss man sicher nicht ob man uns die „Nettigkeit“ abnehmen soll, vor allem aber weiss man sicher gar nicht warum man uns überhaupt folgen sollte. Denn um jemandem gerne etwas abzunehmen, muss man denjenigen erst einmal schätzen. Und je höher das Maß an Änderungen ist, umso mehr geht es auch darum , dass man die Person nicht einfach als Chef schätzt und ihm vertraut, sondern auch Dinge in der Persönlichkeit sieht, die einem sagen, dass dort Autorität und Authentizität stecken, der man gar nicht kompromisslos folgen muss, sondern, die man auf irgendeine Art schätzt.

Und ich denke, dazu gehört mehr als Strategien und Managementbilder auszutauschen und zu diskutieren. Vielleicht muss dafür einfach gemenschelt werden: Die Sorgen über den Anruf aus der Kita  (Tochter krank, was jetzt?) teilen oder beim Bier kommt raus, welche bescheuerte Musik man mag und tatsächlich 500km zum Konzert von einer schrägen Jazzband gefahren ist, zeigen, was man von der Politik seines Landes hält, über ehrliche Fragen zeigen, dass man sich tatsächlich für den anderen interessiert und zwar länger als die 5 Minuten beim Kaffe in der Workshoppause.

Denn ich glaube, dass man nur Menschen für authentisch halten kann und ihnen ehrlich „nette“ Menschen- und Managementbilder abnehmen und glauben kann, wenn man genug über sie erfährt und wenn sie sich in Situationen trauen, in denen sie eben authentisch (verletzlich?) und nicht gehetzt sind und in denen die Maske fällt und eben auch mal alles schief geht oder es eben um gar nichts geht.

Das Innovationsprojekt

Im anderen Fall, hatte ich bei einem Kunden ein Innovationsproekt übernommen und ein frisch zusammengewürfeltes Team von 6-8 Mitarbeitern für zwei Tage pro Woche „bekommen“. Die Erwartungen an Projekt und mich waren sehr unterschiedlich und im Kern war das Schwierige an der Situation dass das Team aus Personen zusammengewürfelt wurde, die sich nicht kannten, vollkommen unterschiedlichen Hintergrund hatten (so weit also sehr gut für das Projekt) vor allem aber wusste das Team nicht genau was auf es zukam.

Da wir nur ein paar Wochen mit jeweils zwei Arbeitstagen hatten, lastete unvermeidbar ein gewisser Druck auf der Situation, der zusätzlich auf relativ „andere“ Arbeitsmethoden in frühen Produktphasen traf, begleitet von hoher Unsicherheit, wenig Domänenwissen usw. Kurz: das Team arbeitete zwar äußerlich vorbildlich zusammen, war aber auch froh, hie und da wieder in die Pausen zu verschwinden, mit den Kollegen aus ihren eigentlichen Teams zu sprechen usw. Irgend etwas stimmte nicht.

Zum einen kam mir das ganz normal vor, weil wir uns als Team erst finden mussten, zum anderen aber kam mir das „Weglaufen“ schon komisch und zumindest hinderlich vor. Dann fiel mir auf, dass wir gar nicht alle zusammen Mittagessen gingen. Und hier fasste ich den (im Nachhinein vollkommen normal wirkenden, damals aber fast übergriffig wirkenden) Plan fast schon zuweisen, dass wir heute zusammen Mittagessen gehen sollten.

Leichtes Murren, aber auch ein gewisses „Jaja, klar, natürlich“ waren die Folge. Beim Essen sprachen wir dann auch erst einmal gar nicht über das Projekt sondern über die bevorstehende Hochzeit eines Mitglieds, das letzte Wochenende  (bei dem nicht alles gut ging) usw. Small Talk eben.

Und siehe da … wir lernten uns allmählich als Menschen schätzen und achten und allmählich entstand ein ganz anderes Zusammengehörigkeitsgefühl. Das führte auch dazu, dass meine Methoden nicht mehr wie vom Mond gefallen wirkten, sondern auf eine ganz andere Akzeptanz stiessen.

Lunch Time, Quality Time (Foto von Juhan Sonin auf flickr, CC Lizenz)

„Quality Time – Zeit in der wir mal nicht(s) wollen, sondern einfach nur sind.“

In beiden Fällen sind mir ein paar Punkte aufgefallen und wichtig:

Es kommt nicht darauf an, dass wir „beste Freunde“ werden und unbedingt in der Freizeit ein Bier zusammen trinken wollen, sondern das Situationen geschaffen werden, die zweckfrei sind und einfach nur normalen menschlichen Austausch möglich machen.

Es geht mir auch nicht nicht um „slacktime“, „20% time“ oder andere Formen der Arbeit, die zwar zeit frei räumen, aber doch wieder mit einem Firmenzweck füllen. Es geht mir um sinnfreie Zeit ohne Intention, die uns schlicht und einfach die Möglichkeit gibt, uns als Menschen kennenzulernen und uns so zu nehmen wie wir sind.

Letztlich in der Annahme und im Vertrauensvorschuss, dass wir alle keine Idioten sind, sondern vollkommen nette, vernünftige Menschen, die schon eine Ebene des Vertrauens und der Akzeptanz finden werden.

Obwohl es vollkommen normal und selbstverständlich wirkt, beschreibe ich hier aber tatsächlich zwei Situationen aus einem relativ kurzen Zeitraum in meinem Umfeld, in denen dies aus besten Absichten und vor allem in höchster Leistungsmotivation fast vergessen wurde und in denen es erst einmal „seltsam“ rüber kam, wieder für diesen Austausch zu sorgen.

Und genau das ist es worauf wir wohl hie und da achten müssen: Über diese seltsame Grenze gehen, die es seltsam wirken lässt und uns und unseren Teams diese Quality Time einfach zu gönnen.

Zufällige Beobachtungen

Apropos seltsam: Hier noch weitere kleine Beispiele, die erst seltsam wirkten, dann aber etwas Gutes bewirkten: Ich hatte einmal einen Chef, der mit all seinen 140 Mitarbeitern einzeln regelmässig zum Mittagessen gegangen ist. Er hatte das zu Beginn seiner Zeit bei uns angekündigt und viele dachten, das sei Fake.

Die Überraschung war dann groß, als er bei den Mittagessen dann tatsächlich vollkommen authentisch privat interessiert war und eben nicht über die Arbeit geredet hat und vollkommen nette Gespräche über Gott und die Welt mit seinen Essenpartnern führte. Der selbe Chef sagte auch, dass er sich über emails freuen würde und diese im allgemeinen direkt beantworte.

Auch dies hielten für einen Standardsatz und waren sehr überrascht, dass er dies dann tatsächlich tat. Dieser Chef lag mir privat relativ fern, was er mit diesen kleinen Gesten allerdings hinbekam war, dass ich ihn für authentisch, nicht anbiedernd und glaubwürdig hielt. Und heute nötigt mir der Aufwand, den er betrieben hat um die Nähe zu suchen, eine Menge Respekt ab.

Am Ende ist es bei Arbeit wie zu Hause, in der Beziehung zum Partner oder den Kindern: wenn der Austausch nur noch funktional ist, geht nichts mehr. Ein bisschen Quality Time und Menscheln hilft und macht alles erst nett und lebenswert.

Ich lese gerade „Kaizen forever – Teachings of Chihiro Nakao“, ein dünnes Büchlein über die Weisheiten eines der engsten Mitarbeiter von Taiichi Ohno (dem Vater des Toyota Production System) und es ist beeindruckend zu lesen, wie stark in Kaizen ganzheitlich gedacht wird, wie wenig die Interessen von Zulieferer, Qualität, Kosten und eben Mitarbeiter und Mensch dort voneinander getrennt werden (können). In meiner Interpretation gehört Quality Time damit auch untrennbar zu Kaizen, also dem kontinuierlichen Verbesserungsgedanken.

Bei uns zu Hause gingen früher viele in den Ferien mit den Bauern in die Weinlese: Da gab es keine Trennung von Effizienz und Menschen. Man fuhr zusammen mit dem Trecker in den Wingert, hat dort zusammen den „Arbeitsplatz“ eingerichtet, fette Leberwurstbrote (sic!) gefrühstückt, es gab ein lustiges Belohnungssystem für uns Kinder (wer darf schon die „Bütt“ tragen?) und es wurde eben den ganzen Tag über geschnattert.

So wurde man die Herbstferien über zu einer netten, verschworenen Gemeinschaft, die die morgendliche Hält und die Hitze tagsüber super zusammen ausgehalten hat, aber auch viele komplette Regentage. Und es ist eine Zeit, die jeder immer geschätzt hat. Die Bauern wussten also schon, wie sie uns bei aller Aasgesetztheit eine gute Zeit machen.

Wie schafft Ihr es, genug Quality Time bei der Arbeit zu finden?

Foto von Mike Baird auf flickr, verwendet unter CC Lizenz.

Es kommt nicht oft vor, dass ich über meine Projekte schreiben kann. Zum einen sind da NDAs, zum anderen sind die Projekte an denen ich arbeite oft zu sensibel als dass ich darüber „plaudern“ würde. Umso schöner, dass Sebastian Radics, Teilnehmer eines meiner letzten Projekte, einen Praxisbericht Ideation geschrieben hat. Zwar wird nicht das gesamte Projekt beschrieben, sondern nur ein kleiner Ausschnitt, der die Ideation betrifft …aber: immerhin 🙂

Man kann etwas ahnen von dem was wir tun.

Praxisbericht Ideation von Sebastian Radics

Viel Spaß beim Lesen: Hier der Praxisbericht Ideation von Sebastian!

Vielleicht kann ich mir bei Gelegenheit einmal die Mühe machen, ein solches Projekt im Abstrakten zu beschreiben ohne zu viel zu verraten. Sebastian’s Beitrag hat mir Appetit dazu gemacht 😉

Unser Held bleibt natürlich professionell (na ja … mittendrin schmeißt er im auf und Ab der Geschehnisse sieben Job hin) und erklärt uns seine Vorgehensweise.

In diesem Zitat beschreibt er, wie er ein Interview angeht:

„Experience taught me not to get to the point right away in interrogations. You’ve got time, take it. Let people talk, let them tell their stories. Often, you’ll get to hear what you need.“ 

Im nächsten Ausschnitt gibt er ein Beispiel dafür, wie er ein Interview angeht und weist auf die Gefahr hin seine eigene Ansicht zur Sache zu sehr über seine Fragen zu transportieren:

„Tell me what you saw“ I said. Because you never start with a direct question.

„How did the girl look like? How tall was she?“

With these questions you transfer your own bias to the witness – and this is something that should never happen. If you ask open questions, they tell you what matters to them and that’s exactly what you want to hear.  In other words:  You already know what you know.

Und schliesslich noch ein Beispiel für den hohen Wert möglichst früher Invalidierung. Im beschriebenen Fall ist natürlich frühe Invalidierung potentiell lebenserhaltend, wann man möglichst schnell an vielversprechenderer Stelle nach dem weiter suchen kann. Bei Product Research oder Exploration, ist es das selbe: eine Invalidierend bedeutet: hier müssen wir nicht weiter gehen – wir können den Raum noch einmal öffnen und an ganz anderer Stelle suchen.

„You can also call it progress when a suspicion is ruled out – and the Bensons  I now nearly ruled out for certain.“

Lustigerweise teilen also Verbrechersuche, Crime und Product Research oder Exploration Probleme, Techniken und Prinzipen – und beides macht auch ein bisschen Spaß.

Alle Zitate aus dem Buch „Missing: New York“ von Don Winslow (einem der besten lebenden Crime Autoren!)

 Foto von Alan Cleaver verwendet unter CC License – Danke!

1. Das Bestehende immer besser machen: Heute Geld verdienen mit dem was wir haben (Horizont 1)
2. Neues entdecken, neue Probleme für evtl. auch neue Kunden lösen: Zukünftiges Wachstum ermöglichen (Horizont 2)

Das sieht auch das Three Horizons Modell so. Bei den Three Horizons kommt dann noch etwas anderes, der dritte Horizont dazu: Optionen für zusätzliches Wachstum finden und ermöglichen – das ist aber kulturell sehr ähnlich wie Horizont zwei, deswegen gehe hier nicht weiter drauf ein.)

3 Horizons model

Nun gibt es Millionen von Gründen, warum uns Horizont 2 schwer fällt und über jeden der Gründe könnte man Artikel schreiben (und bald wird ein Artikel von mir bei einem Partner erscheinen, der beschreibt, wie man besser damit umgehen kann):

• H1 liefert Vorhersagbarkeit, H2 Unsicherheit
• H1 liefert Qualität und Verlässlichkeit, H2 erstmal Visionen und Neues, das womöglich sogar alles was wir in H1 haben in Frage stellt.
• H1 liefert das von dem wir wissen was wir liefern müssen (known knowns), H2 sucht neue Probleme (known/unknown unknowns)
• H1 ist lösungsorientiert, H2 sucht Probleme
• Die Arbeit in H1 ist linear, H2 ist von vor und zurück geprägt, beinhaltet als ständig Rückschritte.

Ich glaube aber, der Kern ist, dass wir in H1 alles „wissen“, in H2 aber alles „suchen“ und finden müssen. Das bedeutet aber , dass wir auf der Suche in H2 am Anfang alle erst einmal dumm sind. Wir wissen nicht was wir suchen, wir wissen nicht mal welche Fragen wir stellen müssen um suchen zu können.

Jeder, den wir treffen, weiss mehr als wir. Diesen Personen gegenüber müssen wir unsere Unwissenheit auch exponieren, sonst lernen wir nicht.

Wenn wir einen Weg finden, wissen nicht wie erfolgversprechend oder belastbar er ist. Während die Kollegen fleissig und termingerecht neue Features ausrollen, von denen wir wissen (?) dass sie gebraucht werden.

Leute, die neue Produkte finden wollen, müssen sich also mit Freude und freiwillig in die Lage begeben, nichts zu wissen, dumm zu sein und langsam schlauer zu werden. Sie müssen sich mit Freude neuen Szenario auswerfen. Wahrscheinlich eine Situation, die nicht jedem schmeckt und in die wir nur diejenigen bringen sollten, die größte Lust darauf haben.

Leider bringt die Stupidophobie ein organisatorisches Problem mit: Leute, die in der Verantwortung stehen, Neues zu machen müssen Ihre anfängliche Dummheit oft verdecken und überspielen, weil sie in einer Umwelt leben, die dieses Problem nicht versteht. Dialoge wie folgender sind an der Tagesordnung und enden nur selten in Zufriedenheit beider Seiten:

„Wissen wir schon ob es klappt, was dabei rauskommt?“ „Nein!“ „Wann genau werden wir es wissen?“ „Weiss ich nicht.“ „Haben wir wenigstens einen Businessplan?“ „Ja, aber die Annahmen sind geraten.“ usw.

Dementsprechend helfen uns „Prozesse“ ein bisschen besser in der Unwissenheit zu argumentieren. Learning accounting im lean Startup, bzw. Arbeiten mit Hypothesen – das wissenschaftliche Prinzip also – bieten uns etwas zum festhalten. Die Kunst ist es, den der Stupidophobie so viel entgegenzusetzen, dass man den Prozess möglichst weit im Hintergrund halten kann um die Möglichkeiten des Neuen nicht zu sehr in Bedrängnis zu bringen und Kollaboration nicht zu sehr einzuschränken und gleichzeitig im Konzern überleben zu können. (Tatsächlich arbeite ich gerade mit Kollegen an etwas was uns helfen soll, frühe Signale nbeim Lernen zu verwerten.)

sho shin

Kurz: Ohne erst einmal dumm zu sein und Gefallen daran zu finden, gibt es nichts Neues. Design Thinker haben dann auch eine schönere Formulierung gefunden: „Embrace a beginner’s mind set“. Die Zen-Schule nennt das Konzept Shoshin, verbunden mit der Aussage

„In the beginner’s mind there are many possibilities, in the expert’s mind there are few.“ (Suzuki, Shunryu) 

Das Gefühl, sich in diese Situation zu begeben bleibt so oder so das selbe. Übrigens kennt auch die Wissenschaft dieses Gefühl. Es setzt ein, wenn neue Hypothesen gefunden werden müssen. Die müssen oft außerhalb des Bekannten liegen. Dort nenn man es abduktive Logik (abduction) oder wie Richard Feynman sagt: „In the beginning, you take a guess.“

Credits: Die Kernidee hinter diesem Blogpost stammt von Nilofer Merchant, die weitaus mehr und besser dazu schreiben und sprechen kann als ich.

Hier ein Video von meinem Vortrag „Lean is about the People“ bei der Lean Agile Scotland 2014. Vielen Dank an Chris McDermott für das Bereitstellen der Aufnahme!

Der Talk ist eher auf der ’soften‘ Seite angesiedelt und untersucht die Mechanismen die dazu führen, dass es Firmen allgemein schwer fällt Neues zu tun, neue Produkte zu entdecken, sich auf Neues einzulassen.

Die Ableitung findet statt anhand einer Firma, die ein Extrem bzgl. des Auffindens von darstellt: Pixar. Jeder Film von Pixar beginnt mit einer Idee auf einem weissen Blatt und endet genau 4 Jahre später als Nr. 1 Hit in den Kinos und begeistert und berührt nicht nur die Kinder sondern auch die Erwachsenen. Im Talk stelle ich einige der Mechanismen vor, die bei Pixar dazu beitragen und überlege was sie für unseren Kontext bedeuten.

Am Ende ein paar Massnahmen und Erkenntnisse die dabei helfen können.

Markus Andrezak : Lean Product is about the people – Putting it all together from Lean Agile Scotland on Vimeo.

Lean Agile Scotland

Schliesslich noch ein riesiger Dank an Chris McDermott der mit Lean Agile Scotland aus dem Nichts heraus mit unglaublichem Engagement eine fantastisches, anheimelndes Event mit globalen Speakern und Impact organisiert. Danke!

Hier ist die Präsentation auf Slideshare!

Lean product is for the people from Markus Andrezak

Als möchte ich , um

Template Userstory

Zentrales Merkmal von User Stories ist, dass sie Lösungen beschreiben. Sie haben aber auch zwei Probleme: sowohl die Rolle (Persona) als auch die gewünschte Aktion (Feature) sind meistens geraten, Annahmen. Damit sind sie ein gutes Tool zur Beschreibung von Features, die wir entwickeln lassen wollen und haben damit einen guten, natürlichen Platz nah am Ende des Prozesses, direkt bei der Erstellung des Produktes.

(Auch hier muss man allerdings sagen, dass sie nicht für alle Anforderungen geeignet sind, sondern eben nur für funktionale Anforderungen. Ein reines visuelles Redesign beschreibt man besser anders: eben visuell.) Was aber machen wir in frühen Phasen, in denen wir noch herausfinden müssen, welches Produkt wir bauen wollen / müssen?

In diesen Phasen mit User Stories zu arbeiten ist üblich, bringt aber die riesige Gefahr mit sich, den ohnehin schon vorhandenen Drang, hin zu früher Lösungsorientierung, noch weiter durch das Tool zu zementieren. Hier kommen Jobstories ins Spiel: Sie bilden erkannte, zu befriedigende Kundenbedürfnisse ab und sind damit eine gute Lösung für frühe Projekt- oder Produktphasen.

Lösungsorientierung – der Killer

Disclaimer: Alan Klement hat viel mehr zu Jobstories gemacht als ich. Tatsächlich schienen wir zu ähnlicher Zeit auf ähnliche Ideen gekommen zu sein. Tatsächlich empfinde ich heute ihn als Originator von Job Stories.

Lösungsorientierung ist die Hölle der Produktentwicklung. Aber wir alle bekommen Lösungsentwicklung in unserer Ausbildung eingebrannt: „Ich will keine Probleme hören, ich will Lösungen!“ Dementsprechend schwer fällt es uns allen, dieser Falle aus dem Weg zu gehen.

Uns allen fällt es schwer, sich ständig von den von sich schon klammheimlich sich aufdrängenden Lösungen fern zu halten. In unseren Workshops beobachten wir es auch immer wieder: Sich erst einmal auf die Probleme zu fokussieren ist und bleibt schwer. In Lösungen zu denken liegt uns mehr.

Auch bei Kundeninterviews ertappe ich mich und andere immer wieder dabei, wie wir oftmals Bestätigung für unsere gedachte Lösung haben wollen, anstatt einfach zuzuhören und ganz offen wahrzunehmen, welche Probleme und Bedürfnisse eigentlich ganz offen ausgesprochen werden. Ein moderner Klassiker.

Auf einer anderen Ebene ist es so, dass Vorgesetzte oft direkt die Lösungen delegieren. „Ich war auf Messe XYZ, alle bauen gerade an ZZZ, wir brauchen das auch.“ Hier wird schon deutlich, dass die Reflektion warum wir etwas „auch brauchen“, also das Verständnis, was das Feature bewirken soll, entweder nicht da ist oder nicht kommuniziert wird.

Das heißt aber oft, dass wir uns an Lösungen abarbeiten ohne dass das Problem klar und tief verstehen zu können. Dann können wir in der Umsetzung nicht gut mitdenken. Manchmal ist auch nicht klar, ob die von uns so verlangte Lösung überhaupt ein Problem löst. Besser wäre es, das erkannte und validierte Problem zu delegieren und das Team die beste Lösung finden zu lassen.

Kurz: Wir lieben Lösungen! Das hilft aber nichts, wenn wir nicht wissen welche Probleme wir lösen, warum wir sie lösen und für wen wir sie lösen. Aber nur aus diesem Verständnis heraus können wir erfolgreich nachhaltig Produkte – ansonsten warten wir auf den Zufall.

Weil mir das immer wieder begegnet, habe ich darüber nachgedacht, wie man dem begegnen kann und was mit dabei geholfen hat ist das einfache Konzept der Jobs To Be Done (JTBD).

Ein Job To Be Done ist das was ein Produkt für einen Kunden erledigt, die so dass es dem Kunden es den Kunden wert sind, Geld für dieses Produkt oder diesen Service zu bezahlen. Genauer noch ist es so, das der JTBD das ist was der Kunde als mentales Bild (bewusst oder unbewusst) zu diesem Produkt abgespeichert hat.

Umgekehrt: Wenn ein Kunde für einen Service oder ein Produkt bezahlt, dann weil man für ihn in einem bestimmten Kontext bei der Erfüllung eines Bedürfnisses eine große Hilfe ist. Man erledigt einen Job für ihn, den JTBD. JTBD ist ein wunderschönes, einfaches Konzept von Clayton Christensen, um sich auf den Wert zu konzentrieren den man für Kunden schafft.

Weil es so einfach ist, wirkt das Ganze erst einmal abstrakt und / oder trivial zugleich. Ein aufschlussreicher Klassiker, der dies einfach verständlich macht ist dieses folgende Video von Clayton Christensen zum Thema Milk Shakes.

So schreibt man einen JTBD als Anforderung in Form einer Jobstory auf:

When ______ (Situation), I want to _____ (Motivation), so I can ______(Outcome)

Template für Jobstories

Die Jobstory sieht also ähnlich aus wie eine Userstory, macht aber etwas ganz anderes: Sie formuliert ein Kundenproblem oder Bedürfnis, dessen Lösung weder klar noch erarbeitet ist! Man startet von einer relativ stark validierten Problemhypothese, formuliert als persönliches Problem, und hat nun die Möglichkeit, das gesamte Team (und mehr) in die Erarbeitung der Lösung zu involvieren.

Das sorgt zum einen für ein hochgradiges und tiefes Verständnis der Kundenprobleme im Team, zum anderen aber auch für hohes Committment bei der Lösungsumsetzung (Entwicklung), da man sich ja bei der Definition der Lösung einbringen konnte.

JTBD sind wirklich einfach zu verstehen. Eine schöne Eigenschaft von JTBD ist, dass sie uns auch dabei helfen können, vollkommen gegensätzliche Kundenaussagen in einen Kontext zu bringen und damit den scheinbaren Widerspruch aufzulösen. Nehmen wir etwa einen Bankkunden, der meist von der Bank in Ruhe gelassen werden will, in bestimmten Situationen aber ganz eng von der Bank betreut werden will.

Die Bank verwirrt die Unterschiedlichkeit der Kundenerwartung, weil für die Bank Kunden die kommen einfach Kunden sind, sie eben kommen. Der Kunde selbst aber kommt in vollkommen unterschiedlichen Situationen zur Bank:

• Einfach Geld abheben: „Der Bankberater soll mich einfach in Ruhe lassen.“
• Kreditberatung beim Wohnungskauf: „Lieber Berater, erledige so viel wie möglich für mich, mach alles für mich und weise mich auf alle Möglichkeiten und Risiken hin“.

Stufen von Anforderungsmanagement

Gehen wir einmal die Stufen von Anforderungsdefinitionen durch und welche Wirkung sie haben:

Klassisches Anforderungsmanagement

Hier rennt der PO durch das Haus, sammelt für eine vorgegebene Lösung Anforderungen aus allen Abteilungen zusammen, moderiert ein bisschen und am Ende gibt er die Anforderungen in Paketen an die Entwickler weiter. Das ist kein sehr erfüllender Job, und die Gestaltung des Produktes hat wenig mit einem selbst zu tun.

Möglicher Erfolg oder Misserfolg ist auch kaum vom PO selbst zu beeinflussen. Tatsächlich ist in diesem Kontext ein PO am ehesten ein toter Briefkasten, eventuell ein Projektmanager.

Agiles Anforderungsmanagement

Teile des Jobs sind ähnlich wie im vorigen Beispiel. Immerhin werden die angebotenen Features jetzt aus Kundensicht formuliert. Das klingt schon mal kundenorientierter und es involviert in der Kommunikation die Entwickler besser. Im Kern ist eine User-Story aber oft noch eine (differenziertere) Lösungsbeschreibung.

Jobstories

Das Wesentliche an der Jobstory ist, dass sie direkt bei den Research-Ergebnissen und Kundenbedürfnissen startet und noch nicht in Richtung der Lösung schielt – diese ist noch – im besten Fall gemeinsam – zu erarbeiten.

Diese Form der Anforderungsdefinition sorgt für die richtige Perspektive in der Beschreibung und hilft uns, die Beschreibung des Kundenproblems zu erzwingen und ins Zentrum des Handels stellen. Zum anderen habe ich festgestellt, dass diese sehr positive Variante von Problembeschreibung den meisten wesentlich leichter fällt als die trockene, tiefe Beschreibung von Kundenproblemen als Problem Statements. Denn Jobstories scheinen schon mehr in die Richtung einer Lösung zu zeigen – ohne dies aber wirklich zu tun.

Der positivste Effekt im Umgang mit Jobstories ist allerdings, dass wir eine Umgebung schaffen, in der die erzwungene Beschreibung von Kundenproblemen dafür sorgt, dass wir generell Arbeiten ausgehend Kundenproblemen starten und nicht von erträumten Lösungen Fr die wir eventuell gar kein Problem identifiziert haben.

 Ein einfaches, kleines Framework

Insgesamt fügt sich das also wie folgt in einen Zusammenhang:

• Wir starten mit Research, werden auf Verbesserungsmöglichkeiten aufmerksam (Hunch),
• Diese validieren wir und formulieren den JTBD als Jobstory.
• Dann suchen wir Heuristiken um den JTBD zu lösen
• Aus den Heuristiken versuchen wir ein Rezept zu verallgemeinern
• Der Rest der Arbeit ist dann, mögliche Lösungen für den JTBD zu finden und zu validieren.
• Die Lösung, die wir am Ende bauen, stellen wir dann wieder als User Story dar.
• Die Userstory wird implementiert.

Wenn man das einmal macht, hat man auch ein wunderbares Handwerkszeug um überzeugendes Storytelling vom Erkennen der Möglichkeit bis zur Lösung zu betreiben. Das sorgt dann für gemeinsames Verständnis vom Manager, der sein Committment gibt bis zu Operations, welche die fertige Lösung deployen.

Alles zusammen liefert ein wunderbares Framework welches Research in ein Produkt überführt, indem Probleme erkannt werden, denen eine Lösung gegenüber steht, jeweils ausgedrückt in Jobstory und Userstory.

• Jetzt aber raus aus dem Büro!
  Am Schreibtisch kleben bleiben ist einfach. Aber wer früh und oft in der Produktentstehung das Büro verlässt, baut bessere Produkte.
• UX Utopien
  UX machen wollen alle, aber in der Praxis gibt es viele Probleme. Wir beleuchten, warum das so ist und was man dagegen tun kann.
• Gute Produkte sind nicht eitel
  Viel zu viele Produkte haben viel zu viele Features und wollen zu viele Nutzerbedürfnisse gleichzeitig bedienen. Was gute Kellner und gute Produkte gemeinsam haben.
• **Wie viele Interviews bis zur Validität?
  **Knowledge Funnel und Interview-Methoden: Wann was anwenden?
• 4 Arten von User Forschung
  Welche grundlegenden Arten von User Research gibt es und wann werden sie zur richtigen Zeit angewendet?
• **Die Überkonferenz – Lean UX NYC 2014
  **Unser Blick auf die Lean UX Konferenz Anfang April in New York.
• **Der lange Lauf zur Innovation (oder zum guten Produkt)
  **Innovation kann nicht mal eben nebenbei passieren. Wenn schon, dann richtig!
• Research und Design gegen Risiko
  Neue Produkte sind immer mit Risiko behaftet. Aber es gibt einfache und billige Instrumente, um das Risiko deutlich zu reduzieren.

Titelphoto Mission 9.1 Nelvaan – 06von Masked Builder auf flickr unter CC Lizenz

Wann immer hier ein neuer Laden aufmacht, weiß ausgerechnet ich ziemlich genau, ob der Laden es schaffen wird oder nicht. Manchmal werde ich richtiggehend traurig noch während der Laden renoviert wird und sich abzeichnet, was es für ein Laden werden wird. Je toller die Idee, umso trauriger werde ich, weil tolle Ideen hier ja nicht klappen.

Und je toller die Ideen, je netter sind die Ladenbesitzer und umso toller sind die Dinge, die sie anbieten wollen. Und dann wollen sie der Gegend trotzen und sie erziehen und hoffen, dass das schon noch wird und wir irgendwann alle verstehen, das man eben doch hier einkaufen gehen kann.

Aber wie es aussieht, will diese Gegend nicht erzogen werden. Und dann tun mir die Neuladenbesitzer so leid, dass ich ihnen gerne noch während der Renovierung einen Brief durch die Tür schieben möchte – gerne auch mal mit Geld drin – und in dem Brief würde stehen: „Ihr seid super nett.

Ich mag Euch und eure Ladenidee. Hier kamen schon viele nette Leute mit vielen tollen Ladenideen, die ich auch toll fand. Aber glaubt mir: Keiner wird bei euch kaufen. Und auch wenn ich mich erbarme und bei euch kaufe, ich werde der einzige sein und von mir alleine könnt ihr nicht leben.

Nehmt das Geld das ihr noch habt, sucht euch eine andere Gegend! Die Idee ist toll, sie kann klappen – nur nicht hier. Glaubt mir, ich mag euch wirklich!“ Natürlich habe ich das dann aber nie gemacht.

Aber dann werde ich auch böse auf die Leute: Warum haben die mich nicht gefragt? Warum haben die niemanden gefragt? Man muss dafür nicht schlau sein. Hier weiß das jeder: Man macht hier keinen Kostümverleih mit angeschlossenem Café auf. Du machst auch kein neues Café auf.

Das einzige Café, das geht, ist vorne an der Ecke, da sitzen alle. In allen anderen Cafés ist Tabula Rasa, Schweigen. Oder sie sind eben schon wieder zu. Friseure gibt’s schon zu viele und alle verdienen zu wenig. Und so geht die Liste immer weiter.

Das einzig wirklich schlaue, was man machen kann, wenn man hier einen Laden aufmacht und was ich wirklich von dir verlange ist:  Frag doch die Leute die hier wohnen, wie mich. Oder frag eben irgend einen anderen. Alle wissen es. Am Anfang werden sie freundlich sein.

Aber nach fünf Minuten werden sie brutal ehrlich sein und sagen: behalt dein Geld und versuch es wo anders. Das hier ist ein toller Ort, aber nicht für Dein Geschäft. Einen besseren und billigeren Rat kannst und wirst Du nicht bekommen. Je früher, je besser.

Aber, Gott bewahre, ich befürchte einige dieser Ladenbesitzer haben sogar vorher Geld ausgegeben, viel Geld womöglich, für Marktforschung. Also haben Leute ohne Ahnung, andere Leute ohne Ahnung nach ihrer Meinung gefragt. Diese Leute haben dann ihre Daten befragt und die Daten sehen gut aus.

Denn in unserer Stadt allgemein würde es ja klappen. Was die Daten ihnen nicht sagen können ist, dass es genau hier, bei uns nicht klappen kann. Denn die Daten sind irgendwie aggregiert, aber nicht genau so, dass sie hier eine Aussage treffen könnten. Und dann sind es eben alles quantitative Daten und eben keine qualitativen Aussagen.

Da steht alles mögliche über Alter, Einkommen, Bildung, usw. Was da nicht steht ist: „Die kaufen nicht um die Ecke ein.“ Wie gesagt: Würden sie irgendjemanden hier fragen …

Und jetzt rate mal, was wir bei überproduct machen. Genau! Wir stellen den Leuten einfach diese Fragen. Und anstatt Leuten einen Umschlag durch die Tür zu schieben, versuchen wir lieber mit ihnen rauszufinden, welches Geschäft funktioniert. Und wo! Und das so früh wie möglich.

Oder während sich ein Geschäft ändern und anpassen muss. Und meistens für das Internet – der einzige Unterschied ist, dass die Leute im Internet nicht rumlaufen.

Warum es Sinn macht, früh Leute zu fragen, die etwas wissen, einfach weil es um sie geht, sollte jetzt schon klar sein. Aber es gibt noch einen Aspekt, warum das alles Sinn macht: Normalerweise gibt man ca. 10% für ein Produkt während seiner Konzeptions- oder Designphase aus. Innerhalb dieser Zeit werden aber 90% der späteren Kosten bereits verplant (ziemlich unabhängig davon ob man agil ist).

Was manchen esoterisch erscheinen mag, ist der rationalste und pragmatischste Weg, in den frühesten Phasen Risiko zu managen. Es gibt Stapel von Büchern und unzählige Methoden und noch mehr Debatten darüber, wie man  Risiko in Produktion und Software-Entwicklung managen sollte.

Aber nur wenige beschäftigen sich damit, wie man das in den früheren Phasen eines Produktes schon machen kann. Und noch weniger Leute beschäftigen sich mit den Methoden, die helfen, dabei Produkte zu entdecken. Die Marketingleute haben tolle Methoden gefunden, die in ihrem Kontext funktionieren: Fokusgruppen, quantitative Marktforschung, usw. Es ist ein riesiger Markt und Firmen haben es gelernt, diese Methoden zu schätzen und bezahlen sie gut.

Das Problem dieser Methoden ist, dass sie nur dafür gemacht sind, Bestehendes verifizieren, aber nicht dafür, Neues zu entdecken. Und in diesem Kontext hilft es nur, mit Leuten zu reden und die richtigen Fragen zu stellen, auf der richtigen Abstraktion und Muster zu erkennen.

Die beiden größten Probleme, die uns unterwegs begegnen sind:

Firmen sind froh über jeden Cent, den sie sparen können und riskieren lieber das falsche Produkt zu bauen, als ein bisschen mehr in frühen Research zu stecken. Das Risiko, das entsteht, weil man ein paar Fragen zu wenig gestellt hat, wird erst spät sichtbar. Wenn etwas passiert, ist man sowieso schon weg oder es ist eben die Schuld derer, die ein schlechtes Produkt schlecht gebaut haben. Zudem führten erst wenige Karrieren steil nach oben weil man unsinnige Projekte oder Produkte gestoppt hat.

Das zweite Problem, das wir oft sehen ist, dass Firmen gar kein Geld für Research ausgeben und in Meetingräumen munter vor sich hin raten, was denn klappen könnte und das dann auch direkt bauen. Im schlimmsten Falle ist jetzt auch noch Lean Startup die methodische Ausrede zum Iterieren und hie und da ein unmotivierter Pivot sieht auch immer mal ganz mutig aus. Der Name Strategiemeeting oder New Business kann dieses Defizit auch nicht wirklich aufwiegen.

Es ist wirklich wichtig, sich daran zu erinnern, dass es in frühen Phasen notwendig, allerdings auch möglich ist, sich auf möglichst unterschiedlichen Wegen, so billig wie möglich, Information zu kaufen. Das ist tatsächlich billiger als klassische Marktforschung und vor allem wesentlich aussagekräftiger.

Möglicherweise ist es gerade die geringe Aussagekraft quantitativer Daten in diesen Phasen,  die sie so reizvoll machen. Kaum eine Idee wird durch diese Daten wiederlegt. Nicht einmal die der schlechtesten Strategieberater. Confirmation Bias allerorten.

Eigentlich ist es einfach: Es geht darum, früh den Kontext zu verstehen und die Information billig mitzunehmen, die sowieso herum schwirrt ist und billig zu haben ist. Hauptsache, sie kommt von draußen. Dann wird man nicht so enden wie die ganzen Geschäfte in meiner Nähe.

Steckt man allerdings selbst in einem Unternehmen, hängt an ihm oder hat es gar gegründet, dann ist die Aussicht, dass die durchschnittliche Überlebenszeit von Unternehmen bald bei nur noch 15 Jahren liegt, schon nicht mehr so egal. Eigentlich müsste man nach der Erkenntnis ein paar schlaflose Nächte, in Angstschweiß gebadet, verbringen und sich fragen, ob man genug tut, um hier nicht im Durchschnitt zu landen.

Average company lifespan S&P 500

Folgerichtig wollen immer mehr Unternehmen dieser Entwicklung entgegenwirken. Das Zauberwort ist Innovation. Man will genug neue Probleme für Kunden lösen und so Wert durch Innovation schaffen. Hier gibt es eine gute und eine schlechte Nachricht:

• Die gute Nachricht zuerst: Innovation kann wirklich jeder bzw. jedes Unternehmen. Es ist keine Kunst. Es ist ein Handwerk, das man lernen kann.
• Die schlechte Nachricht gleich hinterher: Das passiert mal nicht so eben – man muss sich dazu bewusst entscheiden und bewusst Zeit nehmen, es zum Teil seines Lebens und seiner Unternehmenskultur machen.

Marathon zur Abwechslung

Mal etwas Anderes: Es gibt 3 Typen von Marathonläufern (bei den weniger spektakulären Distanzen Halbmarathon und 10 km ist es nicht anders, eigentlich ist es überall im Sport so):

• Typ 1 will mal eben aus Fun einen Marathon laufen, weil es cool ist, weil man es halt in gewissen Kreisen mal gemacht haben muss. Und dann macht man das einfach irgendwie. Eher schlecht als recht, vielleicht gar nicht, wird das Ziel erreicht. Eventuell verletzt man sich vorher, weil man vom Training keine Ahnung hat. Am Tag nach dem Marathon geht man (so man kann) zur Arbeit und kann sich dort immerhin als Helden feiern lassen. (Jeder der sich auskennt, geht nach dem ersten Satz des Berichts entnervt zu seinem Platz und schüttelt den Kopf.) Aber immerhin: Marathon – check, done! (Aber auch nie wieder, es hat ja weh getan!)
• Typ 2 ahnt immerhin, dass das ein größeres Unterfangen sein könnte und schaut sich mal einen Trainingsplan an. Mit viel Glück wird danach für ein paar Wochen konsequent trainiert. Diese Gruppe hat bessere Aussichten, den Marathon gesund zu überstehen. Aber Spaß macht es so nicht, der Erfolg bleibt ebenso aus wie bei der ersten Gruppe. Aber auch diese Gruppe kann mit dem Mythos Marathon angeben.
• Typ 3 beschäftigt sich ziemlich ernsthaft mit dem Thema. Relativ schnell bemerkt sie wie, wie ernsthaft – aber lohnend – eine richtige Marathonvorbereitung betrieben werden muss. Eventuell laufen diese Leute dann erst in einem oder zwei Jahren den Marathon, aber das Training vorher mit Unterdistanzen von 10km, Halbmarathon usw, ist an sich schon lohnend und vor allem: Das ist ja auch schon richtiges Laufen! Diese Gruppe wird kontinuierlich besser und kann sich immer bessere und realistischere Ziele setzen. Sie lernt tatsächlich wie man läuft. Hier wird auch wenig angegeben, denn man weiß ja wie viel Arbeit man hier investiert wurde und nur mit jedem zehnten Lauf ist man überhaupt zufrieden. Der Weg ist das Ziel, nicht mehr der eigentliche Marathon.

Und wieder Produkte und Innovation

Wir wollen keine Moralisten sein. Jeder kann machen was er will und es vollkommen ok, zu Typ 1 oder zwei zu gehören um sich einfach auszuprobieren. Aber Typ 1 und 2 sind keine Läufer. So ist es auch mit der Innovation (oder auch schon einfach mit bewusstem Produkt Management).

Es macht keinen Sinn, einfach mal einen Innovation Workshop zu machen, nach ein paar Monaten wieder auf die Ergebnisse zu schauen und festzustellen, dass das ja alles ein ganz cooler Anfang war. Wenn man wirklich Wert für seine Kunden stiften will, muss man sich tatsächlich ständig darum kümmern, sie zu verstehen. Es muss einem auch ständig wichtig sein und das alles muss ehrlich und ernst gemeintes Bemühen sein.

Es gibt keine Abkürzung. Es gibt keinen leichten Weg. Nur: Auch die anstrengenden Wege können Spaß machen – aber nur, wenn man sich vornimmt, da anzufangen wo man steht und ständig besser darin zu werden.

Und am besten fängt man heute an, nicht im nächsten Jahr, nicht im nächsten Monat, nicht morgen. Und natürlich können die ersten Interviews oder der erste Workshop eine Riesenerfahrung werden (das sollen sie auch und dabei helfen wir gerne!) – aber auch diese positive Erfahrung hilft nur, wenn man sich das anstrengende Ziel setzt, das auch durchzuziehen. Das sollte man tatsächlich andauernd machen.

Wie viel Mühe man sich mit der richtigen und notwendigen Unternehmenskultur nehmen sollte, wie viel Spaß das aber auch macht, zeigt dieser Artikel von Arne Roock über seine Arbeit bei Jimdo. Oder wie Tim Kastelle in seinem Blogpost “The secret is that there is no secret” sagt:

„You have to do the work. In the case of innovation, the work involves engaging the people you work with, experimenting, and figuring out how to scale what works, while learning from what doesn’t.

If you actually think about how to do this within your organisation, you’ll realise that it leads to profound changes. That is why people look for a shortcut. Or a secret. I’ll give you the secret: there are no secrets. You just have to do the work.“

“If you want to innovate, you have to try more stuff. This sounds simple (just like “eat less” sounds simple), but it’s not easy.”

Na dann, auf! Heute!

Titelphoto von Ed Costello bei flickr: Paula Radcliffe bei Ihrem Marathon Weltrekord, NY Marathon 2007, Meile 14

Und wir müssen sagen, das war wirklich die beste Konferenzerfahrung seit den frühen Tagen von Kanban. Genauso wie damals wurden wir von einer Vielzahl von Themen und Eindrücken aus den unterschiedlichsten Richtungen beeindruckt.

Will, 3 seiner Kollegen und lediglich eine Handvoll freiwilliger Helfer haben hier eine Konferenz perfekt organisiert, die 700 Gäste, 54 Speaker und 30 Workshops zusammengebracht hat. Aber der wirkliche Knüller war die Breite und Diversität der angebotenen Themen von tiefster UX Research über Lean bis hin zu Philosophie und Logik.

Und gerade deshalb konnten die Besucher sich in Mustererkennung üben und feststellen, mit welchen gemeinsamen Herausforderungen kultureller und methodischer Natur sich Wissensarbeit heute über die Disziplinen hinweg beschäftigt.

NYC High Line

Die eigentliche Erkenntnis war dann auch, dass es ein gemeinsames, zugrundeliegendes Lösungsmuster gibt. Auch wenn es naturgemäß nicht einfach ist, dies in ein paar Zeilen zu beschreiben, so handelt es sich darum, eine Kultur zu schaffen, die in einer sicheren Umgebung Zusammenarbeit ermöglicht, welche das Ziel ständiger Verbesserung unter dem Bild des Lernens motiviert.

Dazu gehört unter anderem das Eingestehen des eigenen Bias, der einem im Weg steht und den man mit diversen Methoden und Einblicken von außen behebt. Dies führt dazu, dass wir unsere eigenen Modelle ab und zu auf den Kopf stellen müssen, indem wir sie aus den unterschiedlichsten Blickwinkeln betrachten und auch gegenintuitive Wahrheiten – gerne von außen – zulassen. Aber zugegeben, so kurz klingt das schon recht schwammig, flach und abstrakt.

Um nur einige zu nennen, haben vor allem folgende Speaker uns beeindruckt:

Jabe Bloom, hat die Konferenz mit seiner Keynote über Russell Ackoff’s “Idealized Design” eröffnet. Hört Sie Euch bei einer anderen Gelegenheit an, um mehr darüber zu lernen, wie man den richtigen Produkten und Services näher kommt! Guter Stoff – so gut, dass wir tatsächlich noch einmal unseren Talk ein bisschen umgeschrieben haben.

Tomer Sharon, sprach über das Wrestling Universum WWE. Der Vortrag war eine unglaublich gute Demonstration, wie man aus seiner Research Geschichten extrahieren kann, welche die wesentlichen Punkte klar, lebendig und verständlich rüberbringen – so dass auch mal kein Auge trocken bleibt.

Hier wurde Theorie über schieres Entertainment demonstriert. “Show, don’t tell!” in Perfektion. Und dennoch wurde sehr subtil der Punkt rübergebracht: Research und deren Anwendung klappt nur, wenn man sich wirklich tief für seine Kunden interessiert (“Do you really care”).

Die dritte Person, die wir unbedingt erwähnen müssen ist John Shook, der Elder Statesman des Lean. Wer seine Bücher liest und seine Biofgrafie kennt, weiß dass er alles gesehen und erlebt hat. Und so strahlt er auch eine natürliche Kompetenz und ein Charisma aus, welches die Werte von Lean sofort greifbar und erlebbar machen. Ihn reden zu hören und mit ihm zu diskutieren, bringt mehr als 20 Bücher und zahllose Trainings.

Required support: CoffeeUp

Als roten Faden zog sich Komplexitätstheorie im Gewandt von Cynefin von Dave Snowden durch die Konferenz. Dieses Thema ist ja gerade auch bei allen Lean Kanban Konferenzen präsent.

Hier noch die wichtigsten Personen und Beiträge in Kurzform:

• Fridel und Arne of Jimdo zu “Management, Alignment, and Collaboration Done Differently”
• Jeff Gothelf zur Überwindung agiler Dogmen in seinem Talk “Purity vs. Pragmatism”
• Trevor Owens von Javelin (früher bekannt als Lean Startup Machine) über Probleme mit Innovation in großen Unternehmen und einem Lösungsmodell dazu. Mehr dazu auch in seinem neuen Buch “The Lean Enterprise” (gemeinsam mit Obie Fernandez geschrieben)
• viele andere können hier leider in der Kürze nicht erwähnt werden – wir könnten sicher Bücher damit füllen.

Wir selbst haben einen Talk zum Thema “Creation and Production combined” gegeben, in dem wir darstellen, dass Firmen den Unterschied zwischen Exploration und Produktion explizit machen sollten und in dem wir erklären, welche Art von Research sich in den Entwicklungsablauf integrieren lässt und welche lieber nicht.

Zusätzlich haben wir einen Workshop “Service Deisgn for Agencies gegeben, in dem wir erklärt haben, wie Agenturen ihr eigenes Wissen über Designprozesse auf ihre eigene Arbeit anwenden können um ihre Erkenntnisse bei Ihren Kunden noch besser vermitteln zu können.

Damit können Agenturen Kunden helfen, ihre aufgrund des Außenblickes ganz anderen Erkenntnisse in ihre Produkte einfließen zu lassen.

Side trippin‘

Es ist eine einzigartige Gelegenheit, Vorträge aus so vielen Disziplinen bei gleichzeitiger Tiefe präsentiert zu bekommen, so wie Will diese zusammenstellt. Hier wird das fortgeschrittenste Denken zu Wissensarbeit in unseren Zeiten präsentiert.

Merkt Euch den Termin für das nächste Jahr schon einmal vor! Die Registrierung ist bereits eröffnet. Wie wir schon zuvor gesagt haben – dieses ist eines der wenigen Events, das einen echten Unterschied macht!

Wer nicht bis zum nächsten Jahr warten kann oder wer den weiten Weg nach New York scheut, der kann Will in unserem gemeinsamen 2-tägigen “Bootcamp for Lean Product Management” am 01. und 02. Juli in Berlin im betahaus erleben.

Alles ist vorbereitet! Reserviert, solange es noch Plätze gibt! Hier alles zum Bootamp!

Fragen und Reservierungen gerne direkt per Email (info at ueberproduct dot de)!

Dabei ist die Art der Untersuchung zu Beginn der Firmen-, Produkt- oder Featurefindung offener und geht immer mehr in geschlossene Methoden über – je näher wir der Lösung oder gar ihrer Optimierung kommen. Die unterschiedlichen Phasen hatten wir entlang des Knowledge Funnel von Roger L. Martin angeordnet.

Wollen Firmen im Geschäft bestehen, muss es zu ihren Grundfähigkeiten gehören, so oft, schnell und tief wie möglich durch den Knowledge Funnel zu tauchen – denn so wird jedes Mal ein neues, relevantes Kundenproblem gelöst. Darum betrachten wir den Knowledge Funnel gleich noch einmal und abstrahieren von den Interviewtechniken und ändern den Betrachtungsinkel hin zu (User) Research-Methoden, die zu den einzelnen Phasen entlang des Knowledge Funnel passen – von der Problemsuche und –entdeckung bis zur Optimierung des Lösungsrezeptes.

Grundlagenforschung vs. angewandte Forschung

Dankenswerterweise hat das Erika Hall in ihrem brillanten Buch “Just enough research” schon für uns erledigt und wir können einfach auf Ihre Arbeit hinweisen und erklären, welche Typen von User Research sie unterscheidet.

Wie der Titel ihres Buches andeutet, ist ihr Ansatz recht pragmatisch und schlank gehalten. Forschung ist generell systematisches Nachfragen und als solches aufgeteilt in Grundlagenforschung (wie in der Wissenschaft) und angewandte Forschung. Angewandte Forschung hilft uns, unsere Probleme am Produkt besser zu verstehen und zu lösen.

Erika Hall macht es relativ deutlich, dass sie nichts davon hält, diese beiden Bereiche miteinander zu vermischen. Was wir uns merken können ist: Wir benötigen angewandte Forschung mit dem klaren Ziel unser Produkt zu verbessern. Das bedeutet – zur Erleichterung – auch, dass wir keine wissenschaftlichen Maßstäbe an unsere Arbeit anlegen müssen.

Das erspart uns einiges an Aufwand und reicht allemal für unseren Zweck: Tiefe Erkenntnisse und Einsichten in unsere Problemdomäne über Außenansichten erlangen.

Wir unterscheiden 4 Typen angewandter Forschung:

1 Generative oder erkundende Forschung

Diese Art von Forschung wird zu Beginn des Produktzyklus angewandt. Zu diesem Zeitpunkt sind wir noch auf der Suche nach dem nächsten Kundenproblem, das es zu lösen gilt. Ziel ist es, ein Problem formulieren zu können, von dessen Lösung wir relativ sicher sind, das es für den Kunden – und damit später auch für uns – relevant ist und dementsprechend Wert generiert.

Diese Art von Forschung betreiben wir u.a., indem wir uns an den richtigen Plätzen aufhalten und Leute beobachten, Kunden interviewen, manchmal beliebige Leute, aber auch Experten oder auch einfach durch Internetrecherche. In diesen Interviews stellen wir sehr offene, generische Fragen und wären noch gar nicht in der Lage, aufgabenorientiertere oder konkretere Fragen zu stellen.

Wir wollen das Leben und die Umgebung der Interviewees verstehen, analysieren Ihre Verhaltensweisen oder Hacks, mit denen sie sich die Welt ‚schöner’ machen und versuchen darüber Probleme zu entdecken, die wir für sie lösen können.

Selbstredend ist es nicht so, dass wir die Leute konkret nach ihren Problemen fragen oder sie uns diese nennen können. Es bleibt schon unsere Arbeit, Muster von Bedürfnissen und Lösungspotentialen zu entdecken, die wir dann angehen können. Noch haben wir keine Ahnung von der Lösung.

Ziel generativer und explorativer Forschung ist es ein Problem Statement formulieren zu können: Welches Problem lösen wir für wen in welchem Kontext und warum ist dies sinnvoll?

2 Beschreibende und erklärende Forschung

Ein Problem Statement formuliert zu haben, engt den Lösungstrichter schon mal ein. Zum Glück! Wir haben jetzt ein valides, relevantes Problem zur Lösung vor der Nase, aber es gibt dennoch unzählige mögliche Lösungswege. Um diese einzugrenzen und zu priorisieren benötigen wir jetzt ein genaueres Verständnis des Problemkontext und der Leute die wir bedienen um nicht zu scheitern. Wir müssen den Sweet Spot von „Was und Wie“ finden!

Jetzt können wir uns besser und genauer die Leute heraus suchen, die uns spezifischer bei der Untersuchung unseres Problems helfen können. Wir können gezielter Experten heraussuchen und unsere Fragen werden inzwischen auch treffsicherer. So versuchen wir unsere Wissenslücken bzgl. des Problemumfeldes aufzufüllen und vor allem auch neue Sichtweisen einzunehmen.

Das beinhaltet die Chance und Herausforderung von unseren eigenen Annahmen („Leute wollen hier normalerweise …“) Abstand zu nehmen und uns den Erkenntnissen und Einsichten der Interviewpartner zu öffnen. Unsere Aufgabe ist es nicht, unsere Annahmen zu bestätigen, sondern neue Perspektiven einzunehmen und so direkt an der Quelle besser zu verstehen was funktionieren könnte und warum und wann.

In dieser Phase ist es von besonderem Interesse, zu verstehen, welche Konventionen und Lösungsmuster wir verwenden können und welche nicht. Denn man sollte nicht vergessen: Konventionen  („Einkaufswagen“) im Internet helfen uns und sind von großem Wert. Wir sollten gar nicht erst (aus Eitelkeit?) gegen sie ankämpfen.

Allerdings können wir diese Lösungen nur im richtigen Kontext anwenden. Während Innovation in einem neuen Kontext von großem Wert ist, ist sie in bekannten Kontexten eher störend. (Wer traut sich schon zu, die „Einkaufswagen“-Metapher durch eine bessere, eigene zu ersetzen?).

Ziel dieser Phase ist es, ein gutes, tiefes Verständnis der Umgebung zu erlangen für die wir eine Lösung anbieten wollen. Daraus wollen wir Lösungsideen entwickeln und so informierten Lösungen für unser gewähltes Problem immer näher kommen.

3 Bewertende Forschung

Jetzt, endlich, können wir zum ersten mal Forschung treiben, die es tatsächlich zum Ziel hat, unsere Lösungen zu testen. In  den vorangegangen Phasen haben wir ein Problem identifiziert und dann mitsamt seinem Kontext und den Personen verstanden. Jetzt können wir auf Leute zugehen und ihnen unsere Lösungen präsentieren um herauszufinden, welche Lösungsansätze am besten funktionieren und wie wir sie drehen, wenden und anpassen müssen.

Das ist die Art von User Research, die uns am meisten begegnet. Hier handelt es sich im Wesentlichen um frühe UX Tests. Speziell hier sollte man sich bewusst sein, in welcher Art von Forschung man sich bewegt und welche Art von Erkenntnissen man gewinnen kann.

Ein Fehler wäre es, die Erkenntnisse aus dieser Forschung auf frühere Phasen zu beziehen und zu denken man bekommt in diesen konkreten Befragungen sehr Grundsätzliches heraus. Das könnte nebenbei aus Zufall einmal passieren, ist aber auf keinen Fall der Zweck dieser Tests und man sollte bei der Extrapolation sehr vorsichtig sein ob die Ergebnisse valide sind.

Wir treffen immer wieder auf Situationen, in denen Firmen diese Tests sehr liebevoll durchführen und daraus Antworten auf Fragen auf allen Ebenen ableiten und davon ausgehen, dass dieser Input dazu führt, dass man das richtige Produkt entwickelt. Dem ist nicht so.

Im Gegenteil. So zu denken ist geradezu gefährlich. Kunden, denen wir eine ‚fertige’ Lösung vorsetzen, können uns keine Auskünfte über das gelöste Problem geben, sondern nur über die Lösungsqualität. Unsere konkreten, letztlich aufgabenbasierten Fragen werden auch konkret beantwortet und die Aufgaben so gut wie möglich bearbeitet.

Und das meist sehr freundlich. Die Kunden werden uns hier nicht erzählen, dass sie keine Ahnung davon haben was unsere Lösung überhaupt anbietet und warum es unsere Forma überhaupt gibt. Auch nicht, dass sie keine Übereinstimmung zwischen unserem Versprechen, unserer Vision, unserem Produktangebot und unserer Markenbotschaft erkennen können.

Man sollte erst gar nicht versuchen, diese Ergebnisse in diese Art von Forschung hereinzuinterpretieren. Dennoch ist dies die große Mehrheit von Forschung, die wir beobachten.

Die gute Nachricht zu dieser Art Kundenforschung: Man kann und sollte sie oft ausüben und man kann sie tief und gut in den Entwicklungsflow integrieren. (Unsere Annahme ist, dass man sie deswegen so oft antrifft – außerdem ist es hip researchy zu sein.) Es ist aber wichtig zu verstehen, dass diese Forschung auf einem Detaillevel abläuft, der uns nicht garantiert, das richtige Produkt zu bauen. Hier erhalten wir nur Auskunft, wie unser Produkt funktionieren kann.

Hier ist es das Ziel, herauszufinden, welche unserer Lösungsansätze funktionieren können und so der Problemlösung im Konkreten immer näher zu kommen. Mit anderen Worten: Hier stellt es sich heraus ob wir genug erklärende Forschung betrieben haben um die richtigen Lösungen zu finden.

4 Beiläufige Forschung

Sobald das Produkt ausgeliefert ist, befinden wir uns in der bequemen Lage, Leute dabei beobachten zu können wie sie es benutzen und mit ihm umgehen. Welche Probleme treten dabei auf? Was fällt leicht und ist verständlich? Warum verlassen sie den Verkaufsflow ständig an derselben Stelle?

Warum ausgerechnet dort, wo wir alles für so klar halten? Warum wird das verdammte Formular nie ausgefüllt? Warum werden immer dieselben Produkte aufgerufen, andere aber gar nicht?

Das ist beiläufige Forschung und wie der Name sagt, sollten wir sie immer auf der Rechnung haben und ständig betreiben. Das ist unsere Chance, das gefundene Rezept immer weiter zu verfeinern, immer besser zu skalieren und so das Produkt immer einfacher zu gestalten.

In seiner Extremform, könnte man sagen, ist A/B-Testing einfach eine weitere, höher skalierte, rein quantitative Form dieser Forschung direkt im Produkt.

Hier noch unser Schaubild, auf dem die Forschungsarten entlang des Knowledge Funnel aufgeführt sind.

Arten von User Forschung entlang des Knowledge Funnel

Bevor man in die jeweilige Forschung einsteigt, sollte man sich also klar machen:

• Was ist die benötigte Ebene an Erkenntnissen?
• Welche Art von Forschung liefert dies?
• Welche Art von Fragen müssen wir stellen?
• Und jetzt nicht die Ebenen verwechseln!

Es ist auch wichtig zu bedenken, dass es zwar einfach ist bewertende und beiläufige Forschung in den Entwicklungsflow zu integrieren. Es kann aber ebenso kulturell herausfordernd, schwer oder gar konzeptionell unmöglich sein, tiefe erklärende oder generative Forschung in den Entwicklungsflow zu integrieren.

Ich persönlich würde sogar davor warnen und in diesen Fällen Forscher Forscher und Entwickler Entwickler sein lassen, die beiden Gruppen aber ermutigen sich über ihre Erkenntnisse auszutauschen.

Viel Spaß dabei!

Titelphoto: Mike & Amanda Knowles, licensed under the Creative Commons Attribution 2.0 Generic license.

Dabei verfolgen wir mit den Interviews in unterschiedlichen Phasen unterschiedliche Absichten. Da wir es kulturell eher gewohnt sind, mit quantitativen als mit qualitativen Erkenntnissen umzugehen, kommt uns gegenüber immer wieder die – berechtigte – Frage auf: “Wie viele Interviews müssen wir führen?” Und: “Wann sind meine Ergebnisse valide?”

Interview != Interview

Um die Fragen zu beantworten, lohnt es sich, erst einmal eines unserer Lieblingskonzepte anzuschauen, den Knowledge Funnel von Roger L Martin. Hier gibt es drei sich wesentlich unterscheidende Phasen im Lebenszyklus eines Produktes, die uns vor grundsätzlich andere Herausforderungen und damit Fragestellungen und Arbeitsweisen stellen.

Im oberen Teil des Trichters versuchen wir, erst neue Probleme von Kunden zu entdecken, die wir lösen können. So versuchen wir, das Problem und seinen Kontext zu verstehen. Das kann aber nur in einer kleinen Kundengruppe gut funktionieren – ansonsten ist unser Ausgangspunkt gleich wieder ein Kompromiss und eben nicht valide.

Im mittleren Teil versuchen wir, Heuristiken zu finden, mittels derer wir einer skalierenden Lösung näher kommen. Am unteren Ende des Trichters haben wir letztlich so viel Wissen gesammelt und so viel experimentiert, dass wir nun beginnen können, ein Rezept auszubeuten, das bereits gut skaliert.

Hier geht es nun um die weitere Optimierung des Lösungsrezeptes. Und das heißt meistens, das Rezept so zu verallgemeinern, dass das Produkt im Hintergrund bleibt. (Siehe „Gute Produkte sind nicht eitel“)

Um die Frage zu beantworten, wie viele Interviews wir brauchen, um ‘valide’ zu sein für die unterschiedlichen Kontexte, hangeln wir uns den Knowledge Funnel von oben (Hunch) nach unten (Algorithm) herunter.

The Knowledge Funnel

Valide Probleme und Wünschbarkeit entdecken

Wenn wir ein neues Produkt konzipieren, wollen wir erst einmal ein Problem entdecken, das es sich zu lösen lohnt; ein Problem, dessen Lösung erst einmal hart genug ist, um im Markt “Wünschbarkeit” (Desire) auszulösen. Hier ist die Aufgabe im Interview also erst einmal, den Kunden und seinen Kontext kennenzulernen, um herauszufinden, welche Probleme wir noch für ihn lösen können.

Wenn wir nun einen Interviewleitfaden aufstellen, fällt es auf, dass wir in dieser Phase keinerlei konkrete Fragen stellen können – wir wissen einfach zu wenig vom Kontext. Daher fallen uns konkrete Fragen gar nicht erst ein. In dieser Phase müssen wir sehr allgemeine, offene Fragen stellen, die den Kunden dazu bringen, konkrete Geschichten und Erfahrungen zu erzählen, etwa: “Wie war das, als sie das letzte mal ein Auto gekauft haben?”, “Können Sie uns erzählen, wie die Diskussion in Ihrer Familie weiterging?”.

Bei diesen Interviews lassen wir uns von der Empathie leiten und bringen den Kunden ins Erzählen. Drei bis fünf 3–5 Interviews sind ein guter Richtwert, um die Witterung aufzunehmen. Durch gegenseitiges Spiegeln des Interviews versuchen wir, Muster zu erkennen, hier nutzen wir aus, dass der Mensch eine ganz gute Mustererkennungsmaschine ist.

Die groben Muster sind nach ein paar Interviews gesättigt. Danach arbeiten wir das ganze formaler auf und leiten Beobachtungen und Bedürfnisse ab. Jetzt haben wir einen ganz guten Eindruck davon, wie wir den Kunden grob helfen können und was im Gegensatz dazu überhaupt nicht sein Problem ist.

Wir haben also die Ableitung eines validen Problems für ein relativ kleines Kundensegment und dabei die Wünschbarkeit für eine kleine Gruppe validiert. Damit haben wir vor allem Erkenntnisse auf qualitativer Ebene. Vor allem aber: Durch die Empathiearbeit können wir das Problem jetzt fast nur noch aus Kundenperspektive denken und nehmen einen vollkommen anderen Standpunkt ein, den wir vorher gar nicht haben konnten, und das ist der eigentliche Wert der Übung!

Manchmal führen wir die Interviews nicht selber, sondern lassen uns die Eindrücke von guten Interviewern schildern. Die Mustererkennung funktioniert auch dann und die Gefahr, den Kunden in eine Lösungsrichtung zu beeinflussen, fällt weg.

Will Evans (@semanticwill) hat dazu folgendes Slide gebaut, das das recht gut ausdrückt: Ohne Interview haben wir keine Erkenntnis, irgendwann nimmt die Steigerung an Erkenntnissen aber auch wieder ab.

Insights per Interview by Will Evans, semanticwill

Noch einmal als Wiederholung: Das Ganze funktioniert mit wenigen Interviews, weil es um Problemerkennung und Perspektivwechsel geht.

Der Lösung näher kommen

Nach dieser Phase können wir uns Lösungen für die erkannten Probleme und Bedürfnisse ausdenken und iterativ verfeinern. (Ein Unterschied zur ersten Phase: Jetzt sind schnelle Iterationen toll. In Phase 1 zählt Tiefe, jetzt zählt Feedbackgeschwindigkeit.) Dabei können wir für nächste Interviews Lösungsskizzen und Detailfragen stellen, Alternativen diskutieren usw. Die zweite Interviewrunde wird detaillierter.

Hier können wir hochgradig iterativ vorgehen und wiederum pro Interviewrunde sehr wenige Interviews führen. Die Interviews können jetzt auch recht kurz werden. Hier ist es wichtig, dass die Prototypen noch sehr Lo-Fi (also grob und rau) sind, damit die gute Gestaltung nicht ehrliches Feedback zur Wünschbarkeit verhindert.

Ganz unten im Knowledge Funnel machen wir etwas ganz anderes: Hier validieren wir Rezepte, d.h. bereits bestehende Lösungen und optimieren diese. Hier stellen wir auch ganz konkrete Fragen, bis hin zur Task Completion (“Versuchen Sie doch mal, in diesem Flow einen VW Golf zu kaufen!”).

In diesem Bereich haben wir auch eine hohe Vergleichbarkeit zwischen Interviewgruppen und können feststellen, ob unser Rezept nach einer Veränderung besser oder schlechter funktioniert. Interviewpartner können hier auch konkret im Zielmarkt rekrutiert werden. Die Prototypen sind jetzt Hi-Fi (also hochwertig und detailgetreu), um möglichst viel Kontext aus dem Produkt zu transportieren.

Man beachte aber auch, dass es Fragen gibt, die so nicht aufgelöst werden können, etwa, ob der Kunde den Kontext des getesteten Flows erkennt. Das schöne an diesen UX-Interviews ist, dass sie konkret und leicht zu formulieren sind und sich so gut in den eigentlichen Entwicklungsprozess einbauen lassen.

Und man kann natürlich noch wunderbar A/B-testen, indem man parallel Lösungen live stellt – so hat man letztlich die größte und konkreteste Validierung.

Jede dieser Testmethoden hat ein unterschiedliches Ziel und wird zu unterschiedlichen Zeiten mit unterschiedlichen Methoden durchgeführt. Es ist wichtig, sich darüber im Klaren zu sein und sie nicht mit einander zu vermischen. Erkenntnisse aus UX-Tests geben einem keine Hinweise auf neue Probleme und neue Produktmöglichkeiten. Es muss klar unterschieden werden, ob wir im Bereich der

Validierung eines Problems oder der Optimierung einer Lösung sind.
Dabei sind freundliches Feedback wegen zu guter Prototyen und unser eigener Solution Bias die größten Gefahren.

Der Verlauf der Interviewmethoden entlang des Knowledge Funnel sieht also wie folgt aus:

Interviewtechniken gemappt auf den Knowledge Funnel

Eine schlechte Nachricht am Ende: UX Tests bringen keine Conversion-Optimierung und neue Kunden, wenn das eigentliche Problem nicht bereits gelöst ist. UX Testing ist Optimierung einer bestehenden Lösung. Wir beobachten viele Firmen dabei, wie sie aus UX Testing die Silver Bullet zum Erfolg erwarten.

Das ist das falsche Mittel zur falschen Zeit: Ein weiteres Missverständnis, das potentiell zu UX Utopia führt.

Titelbild:  Some rights reserved by robinkristianparker – flickr

Gute Internetprodukte sind genauso. Sie sind da, wenn man sie braucht. Ansonsten drängen sie sich nicht auf. Sie haben einen sehr klar definierten Zweck, den sie für all jene, die kommen, gleich gut erfüllen. Sie versuchen nicht, einen zu ändern, sie versuchen nicht, einen zu erziehen. Sie sind einfach da und bedienen.

Denken wir an amazon, so denken wir erst einmal gar nicht an das Internetprodukt, sondern an die dahinter stehende Dienstleistung. Das Bild des User Interface bleibt blass. Wenn wir an amazon denken, wissen wir zwar wie das Web Interface aussieht, aber es hinterlässt keinen tiefen Eindruck. Die positivste Reaktion, die ich noch zu hören bekomme ist: Es sieht jetzt schon besser aus als früher.

Bei Kayak kann man einfach Flüge (inzwischen auch Hotels, Mietwagen usw.) finden. Mehr nicht. Selbst facebook (und ich mag es nicht) ist klar: Im undiskutierten Mittelpunkt stehen Nachrichten von Bekannten. Und dieser Mittelpunkt bleibt klar. (Na gut, erst einmal sehen, wie sie Paper da unterbringen)

Einfachheit = Klarheit

Wenn man sich erfolgreiche Internetprodukte anschaut wird ein Muster deutlich: Sie sind unauffällig und bleiben im Hintergrund. Sie transportieren keine starken Botschaften, keine Rechtfertigungen oder Erklärungen. amazon etwa könnte, berechtigterweise, die halbe Homepage mit ‚customer obsession‘- oder ‚werde Kindle-Autor!‘-Botschaften zukleistern. Das passiert aber nicht.

Gute Produkte haben meist einen spezifischen Zweck, den sie sehr gut ohne große Variation erfüllen. Und diesen einen Zweck errät man sofort und ohne nachzudenken.

Das überrascht erst einmal und wirkt widersprüchlich zu all der Arbeit, die wir uns machen: Denn wir geben uns ja alle unendlich Mühe, sehr viele Personas zu verstehen, ihre Bedürfnisse zu extrahieren, ihren Geschmack zu verstehen, die richtigen Farben zu finden, die richtigen Anwendungszwecke in den richtigen Situationen zu entdecken.

Früh im Entscheidungsprozess oder auch sehr spät. Situativ versuchen wir mal diesen und mal jenen Content anzubieten. Wir stellen uns die Frage, ob wir mit ein wenig mehr Content nicht Kohorten von Kundengruppe A in Kundengruppe B konvertieren können, denn von B wissen wir ja: Die kaufen!

Das ist alles nützlich. Die detaillierte Betrachtung, die endlosen User Journeys, Empathy Maps,und wie sie alle heißen. Das gegenintuitive Ziel von all dem ist aber, eine einfache Lösung für einen möglichst großen Markt zu finden. Am Ende ist all die Arbeit nur die Grundlage dafür, einen Kontext so gut zu verstehen, dass wir das ultimative, reduzierte Angebot definieren, das unsere Zielkunden sofort verstehen.

Und ich rede von einem Angebot. Wenn wir auf den Markt gehen und zwei unterschiedliche Dinge anbieten, verlangen wir zu viel. amazon bot am Anfang Bücher an. Bei mobile.de konnte man von Anfang bis heute nur gute Autos finden. amazon ging weiter und hat den Buchmarkt verwendet, um das Rezept immer weiter zu vereinfachen, so dass nun unendlich viele Warengruppen dazu kommen konnten.

Dafür hat amazon sein Interface nicht komplexer gestaltet, sondern ist bei dem unscheinbaren, einfachen Rezept geblieben, das nun überall funktioniert.

Unklar und viel bei Yahoo!, google gewinnt

Sobald wir am Interface diskutieren müssen, wie wir die unterschiedlichen Ansprüche unter einen Hut bekommen können, müssen wir zurück und unseren Kontext besser verstehen und wahrscheinlich unser Angebot reduzieren – bis es so einfach ist, dass es auf einen Blick verstanden wird.

Wenn wir zu viele „Reiter“ brauchen, um unsere Optionen darstellen zu können, müssen wir auch wieder zurück und das Problem studieren und mit einem einfacheren Angebot daherkommen, das weniger „Reiter“ benötigt, um dargestellt zu werden. Das Interface ist jetzt nicht das Problem – sondern unser Angebot.

Ein weiteres untrügliches Zeichen für ein zu komplexes Produkt ist, wenn wir uns beim Design zu viel Mühe geben müssen, um den Kontext zu erklären. Wenn unser Produkt „ohne Design“ nicht funktioniert, wird auch nicht „mit Design“ funktionieren. Wenn das Design gewinnen muss, sind wir im Modegeschäft – und bald wieder weg. Denn Mode ist flüchtig und verderblich. Das Produkt ist ein Gimmick.

Was gibt es hier noch mal?

Wenn wir also über Produkte stolpern, die uns erziehen wollen, die zu viel Content anbieten müssen, damit wir sie verstehen, die komplex sind, die uns zu viel anbieten oder ein sehr auffälliges Design haben, mit dem sie etwas retten wollen, liegt ein Verdacht nahe: Dieses Produkt wurde nicht tief genug konzipiert und existiert eher, um den Wunsch eines Investors, Gründers, Konzepters oder Designers zu erfüllen.

Es wurde noch nicht konzipiert, um die Wünsche der Kunden zu erfüllen. Hier wurde noch nicht genug Empathie aufgebracht und der Wunsch der Betreiber steht im Vordergrund. Der Betreiber ist hier noch zu stur und will seinen Willen durchsetzen – er erfüllt seine eigenen Bedürfnisse nach „Durchsetzung“.

Ein guter Kellner bleibt im Hintergrund – ein gutes Produkt auch. Der Kellner ist für den Gast da, wir müssen für den Kunden da sein. Unsere Eitelkeit muss zurück stehen. Und um das zu schaffen, müssen wir genug Arbeit investieren, um den Kunden und seine Probleme zu verstehen. Wenn dein Interface noch „sprechen“ muss, hast Du es noch nicht geschafft.

Titelbild von Florian Plag (Flickr: Serve chilled.) [CC-BY-2.0], via Wikimedia Commons

Beispiele: Square, die sich auch noch über die Gestaltung der Quittung Gedanken machen (und zwar aus gutem Grund) oder dropbox oder etwa Kayak.

Was liegt also näher, als auch UX zu machen? Und jetzt hinein ins echte Leben: Man holt talentierte UXler, die nun denken, hier soll wirklich UX gemacht werden. Diese machen sich also munter ans Werk, führen ihre Interviews und nähern sich dem User an. Oft machen sie nicht bei der Produkt-UX halt, sondern machen sich über die gesamte UX her – wir erinnern uns: Das heißt User Experience. Und diese ist nicht auf das User-Interface beschränkt. Herrjeh – wir haben ja auch gute UXler geholt!

Nach ein paar Monaten gibt es tiefe Einsichten in die Kundenerwartungen und Bedürfnisse, ein paar neue Konzepte, Vorschläge und Lösungen. Dafür hat man die Leute ja geholt.

Spätestens hier ist klar, dass man zwar in den Himmel will, den Preis des Sterbens dafür aber nicht zahlen will.

Jenseits der UXler ist die Firma aber noch im alten Fahrwasser, ohne Fokus. Das Wissen über den Kunden kommt über rein quantitative Marktforschung ohne qualitative Erkenntnisse und eigentlich hat man ja eigentlich nur ein paar nette Designs erwartet. Alles sollte doch schöner werden – nicht schwieriger.

Das alles zu verstehen, was hier an neuer Erkenntnis aus ungewohntem Winkel auf einen einströmt, ist eine echte Herausforderung! Zumal die Nachrichten aus dieser neuen UX-Ecke da drüben nicht gerade angenehm sind. Man hat doch einiges falsch gedacht. Dazu gehören auch viele Vorschläge, die für Außenstehende super einfach zu sehen sind und irgendwie auch in den Köpfen in der Firma bekannt sind.

Aber sie wurden nie umgesetzt. Denn obwohl die zu erzeugenden Werte vollkommen klar ersichtlich sind, scheitern sie seit ewiger Zeit an internen Interessenskonflikten und verstauben in irgendeinem Wiki. Und jetzt auch noch die alte Roadmap für diese Sachen opfern und über Abteilungsgrenzen hinweg umzusetzen? Wie soll das denn gehen? Das ist richtig schwer.

Wie es von hier weiter geht, ist so klar wie ernüchternd: In der UX-Ecke stapeln sich bald die Konzepte – denn umgesetzt werden sie ja nicht. Nach dem 10ten nicht beachteten und bald Schubladen füllenden Konzept kommt auch irgendwann der Elan des motiviertesten UXlers zum erliegen, hier ewig weiter zu kämpfen.

Sich direkt in den Produktionsablauf einzuklinken ist auch schwer – das hat man ja wiederum auch nicht gelernt. Und so kommt eins zum anderen: Aus den neuen UXlern werden irgendwann mittelmäßige Designer und dann schlechte Frontendler, die irgendwann Design-Templates erarbeiten und twitter-Bootstrap aufpimpen und darauf aufbauend einen Styleguide basteln.

Was UX sein sollte, ist jetzt eine schlechte Frontendabeilung ohne Durchgriff und damit eine Enttäuschung für alle. Ein bitteres Missverständnis, das niemand heil übersteht.

Spätestens hier will nun niemand mehr in den Himmel kommen, selbst wenn der Preis nicht mehr das sterben wäre.

Was hier passiert ist Folgendes: Man kopiert einen Mechanismus ohne seine Wirkungsweise zu verstehen. Man wollte ein Rezept anwenden, bekam aber eine komplexe Lösung mit tiefen Erkenntnissen, die der “Apparat” nicht verdauen kann. Was kopiert werden sollte, war eigentlich die Oberfläche, “cooles Aussehen“. Eigentlich sollte alles nur ein bisschen hübscher werden – andererseits aber dieses lästige NPS und Conversionproblem lösen.

Some people avoid thinking because they fear the conclusions to which it may lead.

— Philosophy Muse (@philosophy_muse) January 18, 2014

Mit anderen Worten: Wer UX haben will, weil er auf die Ergebnisse steht, der muss auch die Offenheit haben, den ganzen UX-Weg mitzugehen. Sonst macht er alles schlechter als es vorher war. Die andere Seite ist, dass UX sich Mühe geben muss, die Erkenntnisse besser zu vermitteln – knackige Prototypen, Ausschnitte aus den Videos vorführen, Storytelling statt Powerpoint-Analysen, Spaß statt Defensive – und sich durch LeanUX-Techniken direkter in den Produktionsablauf einzuklinken und den ganzen Deliverables-Overhead und –Unsinn hinter sich lassen muss, den Agenturen immer brauchten um ihre Methode zu verkaufen.

Keine Scheu vor Planungs- und Replenishment-Meetings in agilen Umgebungen. Die Software-Teams sind Dein Freund und Hebel, um Deine Erkenntnisse in Wirklichkeit umzusetzen. Und gleichzeitig kommst Du so in die Rolle, wirklich die User Experience ganzheitlich zu definieren und zu schützen.

Und: Das wolltest Du doch! (Siehe auch den Gast-Blog von Max Wambach.)

Also: Wenn man erst mal mit UX anfängt, wird es bald Erkenntnisse geben, die weh tun. Da muss man durch. Man sollte den ganzen Weg gehen oder gar nicht erst anfangen.

Der Trost: UX ist nicht die einzige Disziplin, die von diesem Problem betroffen ist. Die Suche nach schnellen Rezepten ist allgegenwärtig: Schnell mal einen Scrum-Kurs machen und das, was man gehört hat, einfach mal umsetzen: “Hey, Product Owner: Deine Story ist nicht Sprint-Ready!“, “Hey, Scrum-Master, das können wir nicht committen.

Wir sollten noch drei Schätzmeetings einbauen”. Oder im Kanban: “Nö, wir machen jetzt nur noch One Piece Flow, da gehen nicht zwei Stories parallel.” Auch hier führt blindes “Nachmachen” ohne Verständnis und Anleitung direkt ins Gegenteil von dem was man wollte. Der Wunsch nach Agilität endet in Regeln statt in besserer Zusammenarbeit.

Bevor ihr mit UX startet fragt euch ob ihr bereit seid, den Preis zu zahlen. Aber: seid ihr bereit den Preis zu zahlen, kein UX zu machen? Wie immer: Es fällt einem nicht zu, man muss es sich geduldig erarbeiten, offen für den Wandel sein und wissen was man tut, so wie  Max es hier beschreibt.

Titelbild von Wikipedia und lizenzrechtlich in der Public Domain.

Wir werden in diesem Jahr mehrere Trainings anbieten, bei denen wir jeweils unsere Kompetenz mit der Kompetenz eines Partners in einem anderen Gebiet zusammenwerfen. Damit können wir unsere Trainings jeweils schwierige und entscheidende Schnittstellen in Unternehmen bedienen und dort konkrete Lösungen liefern.

Bei der Auswahl unserer Partner haben wir uns auf diejenigen beschränkt, die jeweils zu den Besten in ihrem Gebiet gehören und mit denen uns eine vertrauensvolle gute Beziehung verbindet. Damit wir bei der Ausarbeitung der Trainings schon einmal all die Herausforderungen, die euch interessieren, vorurteilsfrei und ohne einen Konflikt zu scheuen durchgehen und vordenken können.

Aber alle Theorie ist grau und gerade Trainings stehen und fallen mit den Personen, deshalb hier die ersten Partner mit denen wir etwas unternehmen: 

Klaus Leopold (LEANability) ist Pionier in Kanban-Coaching und –Schulung und verfügt über jahrelange weltweite Erfahrung. Dabei hat er in unzähligen Firmen schon alle Teile der Wertschöpfungskette bedient und in auf schlanke Weise Kanban-Boards für teils über 200 Leute erstellt.

Sein ganzheitliches und doch pragmatisches Verständnis von Kanban wird in seinen Webinar „Flight Levels of Kanban“ deutlich. Er ist auch Co-Autor eines der besten Bücher über Kanban: „Kanban in der IT“.

Weiter ist Klaus Mitglied des Management Boards der Lean Kanban University und damit stets an den neuesten Entwicklungen des Kanban-Curriculums beteiligt. Mit Klaus werden wir ein Training „Kanban für Produktentwicklung“ anbieten, in dem wir die Expertise zu Lean Product Management einbringen, während Klaus zeigt, wie uns Kanban dabei ideal unterstützt.

Will Evans ist Director of Experience Design and Research bei The Library Corporation und TLC Labs, dem Enterprise Innovation Labor. Will ist dort über alle Abteilungen hinweg die treibende Kraft hinter der hervorragenden UX und den innovativen Produkten.

Vorher war er u.a. mit Jeff Gotthelf (Lean UX) bei The Ladders für UX verantwortlich.

Als Design Thinker in Residence lehrt er aktiv am NYU Stern’s Berkley Center for Innovation University. Er ist Gründer und Organisator der Lean UX NYC Konferenz. Er hat mehr als 15 Jahre Erfahrung in Interaction Design, Informationsarchitektur und UX Strategie und treibt aktiv Lean UX und Lean Startup in einer pragmatischen, aber tiefen Mischung aus theoretischem Verständnis und praktischer Anwendung voran.

Will’s Arbeit wurde in Magazinen wie Business Week, The Economist, Business Insider, Fast Company, Time Magazine, Fortune, MSNBC, Fox Business und dem Wall Street Journal dokumentiert. Wir selbst haben uns oft seine Lösungen bei Kayak.com angeschaut und vieles darüber verstanden.

Mit Will werden wir ein gemeinsames Produkt / Design Thinking / Lean UX / Lean Startup Bootcamp anbieten. Hier wird Will seine tiefen Erfahrungen zu UX und Design Techniken einbringen und wir werden wieder den Produktfokus beisteuern. 

Wir sind froh, mit Klaus und Will kooperieren zu können – beide sind einfach auch großartige Menschen und Charaktere!

Die ersten Trainings aus dieser Serie werden wir in den nächsten Tagen posten, wer jetzt schon Interesse hat, kann sich gerne auch sofort seinen Platz reservieren. 

Kontaktiert uns!

Danke für das Titelbild an Ed Yourdon –  Some rights reserved

„Kein Plan überlebt die erste Feindberührung“ – Helmuth Karl Bernhard von Moltke (aka „Moltke, der Ältere“, 1800 – 1891)

Damit hat von Moltke ausgedrückt, dass er nur den Beginn eines Feldzuges für planbar hielt, nicht aber den Verlauf. Den Verlauf hielt er wegen der Vielzahl unbekannter, aber zu berücksichtigender Einflüsse für unkalkulierbar. Die Aussage hat für mich zwei wesentliche Aspekte:

• Der erste ist die Aussage an sich: KEIN Plan überlebt die erste Feindberührung.
• Der zweite ist die Begründung: Wir wissen nicht was passieren wird, weil wir es mit einer komplexen Situation zu tun haben.

Beide Aspekte können wir auf den Produktbereich übertragen:

• Keine Produktplanung überlebt die Berührung mit dem Markt, weil wir
• nie genug über unsere Kunden und die Marktbedürfnisse wissen (die in etwa so komplex sind wie von Moltkes Umgebung).

Von Moltke in Berlin Tiergarten, Quelle: Wikipedia, CC Lizenz

Das bringt uns immer wieder dazu festzustellen: Wir können nie früh genug aus dem Büro gehen und den Markt beobachten und untersuchen, um das Risiko unseres Produktlaunches zu verringern. Denn je mehr wir vom Markt verstehen, umso mehr ahnen wir über das, was von uns verlangt wird, und umso eher passt unser Produkt in den Markt und löst die dort gestellten Probleme.

Ganz praktisch möchte ich das an drei Beispielen verdeutlichen:

• Wir kennen schon die Lösung eines Problems.
• Wir suchen die Lösung eines attraktiven Problems.
• Wir suchen ein relevantes Kundenproblem (oder Marktsegment), das wir lösen wollen – die Lösung ist dann unser Produkt.

Solution-minded oder technisch getriebenes Umfeld

Der erste und zweite Fall begegnet einem sehr häufig in bereits skalierten Firmen, deren Wachstumskurven bereits abflachen und die dem Innovators Dilemma entgegen laufen. Ein anderer Fall sind technisch getriebene Firmen: Das Muster ist: „Wir haben eine tolle Lösung gefunden!“.

Entweder hat jemand ein tolles Produkt gesehen, das man auch haben will oder es hat jemand ein tolles Tool entdeckt, das auf spannende Weise ein Problem löst. In beiden Fällen stellt sich die Frage, ob wir das Problem überhaupt haben, für das wir die Lösung schon kennen.

Oder besser: Ob unsere Kunden das Problem überhaupt haben. Da hilft es nicht viel, sich das ganze am Whiteboard schön zu rechnen. Wir schreiben dann oft einen Business Model Canvas (andere auch gerne ein A3). Daraus extrahieren wir dann möglichst generelle Problemstellungen, die wir mit unserer Lösung zu adressieren scheinen.

Und jetzt können wir „raus“ gehen und schauen wie sich das Problem im Markt darstellt. Manchmal finden wir es gar nicht wieder. Manchmal sieht das Problem ganz anders aus. Manchmal müssen wir es zigmal drehen und wenden („Framing“), um es wiederzuentdecken und – parbleux – plötzlich passt unsere Lösung gar nicht mehr.

Das ist oft enttäuschend. Aber meist wäre es enttäuschender, hätten wir den ganzen Kram einfach gebaut. Projekte, die keiner braucht.

Hier kaufen wir Information so billig wie möglich, bevor das große Geldausgeben beginnt. Nicht jeder mag so manche enttäuschende Erkenntnis – aber der Ansatz ist so Lean wie man es nur haben kann.

Startups oder ganz neue Produkte 

Der dritte Fall ist vor allem relevant, wenn man ein ganz neues Produkt in den Markt bringen will. Startups versuchen im Allgemeinen neue Probleme zu entdecken, die man hochskalierend lösen kann. Firmen, die schlau sind und immer wieder neue Produkte auf den Markt bringen, machen etwas ähnliches: Unaufhörliche Innovation.

Was hier konzeptionell passiert ist das, was Roger L. Martin mit dem Wissenstrichter (Knowledge Funnel) beschreibt: Man sieht (ahnt) ein relevantes Problem und versucht eine Lösung dafür zu finden. Zu Beginn ist dies mühselig und man nähert sich einer einfachen Lösung Stück für Stück über Heuristiken an.

Hier beginnt man, das Problem und den Markt besser zu verstehen. Wenn man Glück und Methode hat und lange genug dabei bleibt, findet man den Algorithmus, den Automatismus, der das Problem löst und kann ihn ausnutzen. Das Unternehmen kann das Produkt oder Angebot skalieren und ausbeuten (Exploitation). Um das zu schaffen, muss man immer wieder einen Schritt zurück gehen und sich umschauen.

The Knowledge Funnel

Die Fragen, die man sich stellen muss sind: Ist das Problem, das ich erkenne relevant? Trifft es die Bedürfnisse von genügend Menschen? Sind die Bedürfnisse tief und intensiv genug, also am besten Grundbedürfnisse, so dass die angebotene Lösung auch zum „Kauf“ führt?

Und nicht zuletzt: Wie genau sind die Bedürfnisse in diesem Feld gestrickt? Welche anderen kann ich noch mit bedienen? Diese Analyse hilft uns dann später bei der Ableitung eines befriedigenden, erfüllenden Produktes.

Wir schaffen Verständnis und Tiefe

In jedem Fall schaffen wir ein größeres Fundament für das Verständnis der Validität.

Manchmal gehen wir bis zum Anfang zurück. Und wenn wir am Anfang stehen, schicken wir gerne einen Interviewer los, der unsere gedachte Lösung nicht kennt, um nicht von unserem eigenen Bias überlistet zu werden! Je tiefer das Verständnis ist, das wir erlangen, je tiefgreifender wird unser abgeleitetes Produkt die Bedürfnisse unserer Kunden befriedigen.

Und diese Lösungstiefe erzeugt am Ende im guten Fall Begeisterung. Ohne Tiefe dagegen erzeugen wir kurzfristige Gimmicks. Und diese Tiefe können wir nicht in unseren Meetingräumen unter uns erzeugen, sondern nur, wenn wir uns draußen rumtreiben und das Umfeld, in dem unser Produkt funktionieren muss, untersuchen und die Menschen (und ihre Lebensumstände) kennenlernen, die unsere Produkte benutzen sollen.

Aber wollten wir nicht agil und schnell sein?

Dauert das nicht alles? Doch! Was hilft es uns, agil und schnell die falsche Lösung zu bauen? Continuous Deployment und schnelle Feedbackzyklen helfen uns zwar schnell ein halbwegs funktionierendes Produkt Stück für Stück besser zu machen. Es hilft uns aber nur wenig, wenn das Produkt von Anfang an durch zu flaches Verständnis verbaut wurde. Will Evans sagt:

http://twitter.com/semanticwill/status/422105507331989506

Wann seid Ihr das letzte mal einen Schritt zurück gegangen?

Natürlich sind wir alle ungeduldig und das Vorgehen stellt unsere Geduld (und die Eures Managements?) ganz schön auf die Probe! Aber bedenkt: Im Produktdesign liegen nur ca. 10% der Produktkosten begraben, es werden aber ca. 90% der Produktkosten festgelegt. Wir denke: Da lohnt sich das bisschen Sicherheit!

Und dran denken: Je näher dran Ihr an der Lösung angefangen habt, umso mehr lohnt sich der schritt zurück – aber um so mehr tut er weh, weil man ja entweder schon so viel investiert hat und seinen Biases ausgeliefert ist.

Falls Ihr mir noch nicht glaubt, holt euch einfach eine zweite Meinung und lest die gute Präsentation „Design Up Front is Back“ von Ari Tanninen.

Viel Spaß beim Abstand nehmen! 🙂

Zuerst wollen wir unser Gespräch mit Joe Dager aus dem Oktober noch einmal mit Euch teilen. Das Gespräch fand im Rahmen von Joe’s brillantem Podcast statt. (Wie gut Joe das macht haben wir hier beschrieben).

Auf dem folgenden Link könnt Ihr das Interview hören, aufgenommen ein paar Wochen vor der LKCE13 Konferenz.

In dem Podcast geht es vor allem um den Clash zwischen linearen Prozessen in der ‚Produktion’ und hochgradig nicht-linearen und unvorhersagbaren Prozessen in der Product Discovery und in der Problemfindung (welche Probleme soll mein Produkt lösen?). Prozesse, die vor allem zu Beginn der Wertschöpfungskette in Unternehmen stattfinden sind eher nicht-linear, Prozesse am Ende der Wertschöpfungskette haben sogar das Ziel eher linear zu sein (sonst skalieren sie nicht). Dieser Clash kostet so manche Nerven.

Bei der LKCE13 Konferenz haben wir das Thema mit dem Talk ‘The Boundaries of Kanban’ noch einmal vertieft. Hier verdeutlichen wir, dass es in Unternehmen beide Welten geben muss: Analytisches Denken um das Geschäft am Laufen zu halten und innovatives, abduktives Denken um neue Probleme und Herausforderungen zu entdecken und zu lösen.

Das Problem ist, dass beide Arten zu denken in den meisten Aspekten vollkommen unterschiedlich sind – bewahrend vs. verändernd, vorhersagbar aus bestehenden Daten vs. chaotisch und unvorhersagbar usw. Diese notwendigen, unterschiedlichen Kulturen in einer Firma miteinander zu vereinen ist eine riesige Aufgabe.

Der Weg ist zunächst einmal explizit zumachen, dass diese beiden Wege existieren, wir beide brauchen und welcher wo und warum zur Anwendung kommt. Product Discovery ist notwendig um neue Produkte zu entdecken und sehr unvorhersehbar, wenn das Produkt definiert ist, hilft z.Bsp.

Kanban es zu produzieren – hier sollten die Prozesse wesentlich linearer und skalierbarer sein. Entsprechend hilft uns Kanban die Dinge auf die richtige Weise zu tun, Product Discovery findet aber heraus was die richtigen Dinge sind. Das ist genau der Unterschied zwischen Effektivität (Doing the right things) und Effizienz (Doing things right).

Diese Aspekte sind orthogonal zueinander und müssen sich gegenseitig ergänzen. Das eine ist nichts ohne das andere. Kanban hilft uns Dinge richtig zu machen, Design Thinking, Design Studio und andere Innovationsprozesse helfen uns die richtigen Dinge zu finden.

Hier das Video von dem Vortrag:

Boundaries of Kanban – disruptive innovation (Markus Andrezak) from Lean Kanban Central Europe on Vimeo.

Schließlich hat noch Dave Gray – Autor von ‚Game Storming’ und ‚The Connected Company’ – ein interessantes Interview mit Markus geführt.

Es war unser erster google+ On Air Hangout, also ein live gestreamtes Interview. Dave benutzt diese Interviews um Material für sein neues Buchprojekt zu sammeln. Andere Interviewte der Serie sind Jeff Gotthelf (Lean UX, neo), Jim Benson (Personal Kanban) oder Dan Mezick (The Culture Game). (Hier kann man die anderen Videos der Serie ansehen und abonnieren.) Zu Beginn der Diskussion verfolgen wir erst einmal die bereits oben angesprochenen Themen.

Der für uns wertvollste Teil kommt dann gegen Ende, wo Dave eines der Learnings für uns aus diesem Jahr erwähnt und wir es gemeinsam tiefer diskutieren: Dave bringt aus dem Service Design das Bild des Restaurants auf und dort speziell den Unterschied zwischen der Arbeit in der Küche und im Gastraum.

In der Küche werden hochgradig wiederholbar ‚Standardarbeien’ erledigt, Rezepte abgearbeitet. Der Schwerpunkt im Gastraum ist es, die vielfältigen Wünsche der Gäste aufzunehmen, diese in Aufgaben herunterzubrechen, die von der Küche erledigt werden können und mit den Ergebnissen der Küche wiederum eine tolle Erfahrung für den Gast zu erzeugen.

Der Unterschied ist: Der Kellner weiß nicht, was von ihm gefordert wird und muss sich mit dieser komplexen Aufgabe wohl fühlen. Die Küche wiederum hat einige (hoffentlich nicht zu viele) Rezepte hochgradig wiederholbar auf hoher Qualität ‚automatisiert’. Mit anderen Worten geht es hier wie in unserem Job um die Kombination von Arbeiten in komplexen und komplizierten Arbeitsumgebungen.

Das wiederum ist eine der Kernaussagen von Cynefin. Das Bild verheiratet also wunderbar die Aussagen von Service Design, Innovationstheorie und Cynefin.

Viel Spaß damit! Falls Ihr uns einmal bei euch vor Ort oder auf einem von euch organisierten Event sehen oder hören möchtet, meldet Euch gerne!

• Innovation ist nicht gleich Innovation. Das Ten Types of Innovation Modell hilft, die eigenen Ideen kritisch zu hinterfragen und auf ein neues Niveau zu bringen.
• Das Pareto-Prinzip der Produktentwicklung beleuchtet, wie man blinden Aktionismus mit dem notwendigen kundenzentrierten Tiefgang kombiniert, um aus der Macherfalle herauszukommen.
• Ein besonderes Highlight ist der Gastbeitrag von Max Wambach, der mit seiner Neudefinition der User Experience Wertschöpfungskette den vielen Problemen im Alltag von UX und Produkt einen Denkrahmen gibt.
• Kundenfeedback ist oft der Schlüssel zum Erfolg. Wir haben versucht, die Grenzen auszuloten und erklären, warum manche Firmen dazu erfolgreich „Nein, danke!“ sagen (können).
• Das Kongress-Highlight für 2013 war mit Sicherheit die LKCE. Für alle, die nicht teilnehmen konnten, haben wir kurz zusammengefasst, was wir erlebt haben: über-Dienstreise zur Lean Kanban Central Europe 2013
• Die Weihnachtsgans ist verspeist. Es wird wieder Zeit für Hot-Dogs, aber Vorsicht vor der Currywurst: Schlange stehen, Hot Dogs – das Product Development Bottleneck
• Design Thinking und Produktmanagement wachsen immer mehr zusammen. Wir haben Tipps von Claudia Kotchka (Procter & Gamble) gesammelt, wie man das Thema im eigenen Unternehmen einführen kann.
• Der Ausweg aus dem Unternehmensdschungel: Folge den Spice Girls und Stephen Bungay und der Weg wird klar!
• Beispiele aus der Praxis sind die besten Lehrmeister. Wir zeigen, was Honda und Edeka erlebt haben.
• Eine bittere Wahrheit für alle, die von der einen revolutionären Idee träumen: Unaufhörlich, anders macht Innovation keinen Sinn.

Besten Dank an PreciousBytes für das Titelbild, Verwendung unter einer CC Lizenz.

TTOI wurde von der bekannten Innovationsberatung Doblin erarbeitet und konzipiert. TTOI teilt Innovationen in 3 Bereiche und 10 Typen ein:

• Anordnung (Configuration) mit den Innovationstypen
  • Geschäftsmodell – wie verdienen wir Geld?
  • Netzwerk – Wie verbinden wir uns mit welchen Partnern um Wert zu erzeugen?
  • Struktur – Wie sind wir organisiert, welche Talente binden und entwickeln wir?
  • Prozess – Wie können wir die Konkurrenz stehen lassen, indem wir operativ besser sind?
• Angebot (Offering) mit
  • Produktangebot – Welche Funktionen und Werte bietet unser Produkt?
  • Produktumgebung – Wie können wir das Produkt mit komplementären Produkten ergänzen und unterstützen?
• Erfahrung mit
  • Service – Wie können wir über Service im Zusammenhang mit unserem Produkt Wert erzeugen?
  • Kanal – Über welche Kanäle können wir unser Angebot zum Kunden bringen?
  • Marke – Wie positionieren wir die Marke und transportieren über sie unsere Werte?
  • Kundeneinbindung – Wie können wir den Kunden in unser Netzwerk einbinden und somit besser bedienen?

Die folgende Abbildung zeigt das Modell im Überblick:

Ten Types of Innovation Model

Vijay Kumar definiert Innovation als „lebensfähiges Angebot, das in einem spezifischen Kontext zu einer gegebenen Zeit neu ist und sowohl für Abnehmer als auch Anbieter Wert generiert“. Leider erreichen lediglich 4% aller Erfindungen diese Qualität. Das hat genau damit zu tun, dass eine Erfindung meist erst einmal eine der TTOI bedient. Erfolgreiche Innovationen bedienen meist einige, z.Bsp. mindestens vier der TTOI.

Mit diesem Modell im Hinterkopf kann man nun jede Idee daraufhin untersuchen, welche dieser Innovationstypen sie bedient. Der legendäre Spark of Insight ergibt bei nüchterner, distanzierter Betrachtung etwa das folgendes traurige Bild:

Der einsame Spark of Insight

TTOI hilft uns beim strukturierten Reframing

Wir haben bisher also eine echt tolle Produktidee, sonst aber nicht viel. Das ist schon mal ein Anfang! Jetzt fängt die Arbeit an. Wir betrachten unsere Idee von vielen Seiten und versuchen, ob wir ein Geschäftsmodell (wir erinnern uns: Wie verdienen wir damit Geld?) für unser Produkt finden, das sich signifikant von anderen unterscheidet oder zumindest kongenial passt.

Fallen uns komplementäre Produkte ein, die unser eigentliches Produkt ideal unterstützen und aus dem Ganzen eine Plattform machen? Wie können wir das Ganze mit einem passenden Service versehen, der allmählich eine Erfahrung aus unserem Angebot macht? Haben wir die Möglichkeit unseren Produktionsprozess so gut zu gestalten, dass wir hier einen besonderen Vorteil erlangen?

Finden wir die besten Talente auf dem Markt? Nach einiger Arbeit könnte das Ergebnis etwa so wie in der nächsten Abbildung aussehen. Schon besser. Wenn sich so etwas nicht ergibt, ist es vielleicht Zeit, die Idee zu vergessen oder Gras drüber wachsen zu lassen und sie später noch mal hervorzukramen. Vielleicht sind jetzt Zeit, Kontext und Optionen nicht gegeben, um hier zum Erfolg zu kommen.

Erweiterter Spark of Insight

Man sieht schon – die Arbeit besteht darin, aus einer einfachen Produktidee eine ganzheitlich gute Erfahrung zu bauen. Das Modell muss keinesfalls über alle Bereiche ausgeglichen gut sein. In allen Bereichen etwas zu bieten zu haben, ist gut und erstrebenswert, aber nicht notwendig.

Hier gibt es keine Regel. Wie so oft muss das Gesamtpaket stimmen und die Wahrscheinlichkeit des Erfolgs steigt mit der Anzahl abgedeckter Innovationstypen. TTOI hilft uns einfach bei der Arbeit, strukturiert nachzudenken, das Problem aus immer neuen Blickwinkeln zu betrachten, zu reframen. Reframing ist dann auch er Schlüssel zu erfolgreicher Innovation – ein Problem in vielen Dimensionen, aus vielen Blickwinkeln lösen und so eine brillante Gesamterfahrung zu erzeugen.

Man merkt es natürlich auch schon bei der Beschreibung: Bei allem Tool-Support ist die Kunst natürlich wieder, dabei so schlank zu bleiben, dass man sich auch mal traut und einfach auf den Markt geht, statt in Entscheidungsparalyse und Angst zu vergehen. Und gleichzeitig muss man die Balance haben, genug Tiefe in die Exploration zu bringen.

Am besten fängt man mit all dem früh in der Exploration an, ansonsten stehen einem die bereits investierte Energie und die daraus erzeugten Prägungen bei der nüchternen Betrachtung der Lösung im Weg und wir halten zu sehr an dem Erarbeiteten Ergebnis fest. Und: TTOI kann man natürlich nicht nur bei neuen Produkten anwenden, sondern auch bei wesentlichen, neuen Features. Dann eben noch schlanker.

Übrigens macht es Alexander Osterwalder mit seiner Idee der Business Model Innovation gar nicht viel anderes, auch wenn der Titel erst einmal ganz anders klingt.

„Business Model Innovation is about new ways of creating, delivering an capturing value“ – Alexander Osterwalder

Zum Abschluss noch einmal Beispiele von TTOI-Diagrammen für zwei erfolgreiche Produkte.

Erfolgreiche Innovationen bedienen sehr viele der TTOI

Tesla etwa

• bietet mit dem Model S ein revolutionäres Produkt (Produktangebot und Produktumgebung) mit seinen Autos an.
• Darüber hinaus ist aber dieses Produkt in eine exzellente Serviceerfahrung (Service)
• mit nahem Kundenkontakt (Customer Engagement) eingebettet,
• die über hervorragende, eigene Autohäuser und Onlinekanäle (Channels) unterstützt werden.
• Das Super Charger Netzwerk, also die kostenlosen Schnellladestationen, die aufgebaut werden, bieten ein neues Geschäftsmodell,
• Aber auch ein komplementäres Produkt (Produktumgebung), aber auch eine tolle Serviceerfahrung (Service).
• Die außergewöhnliche Qualität der Teile und der Fertigung unterstützt das Produkt weiterhin (Prozess).
• Dazu gehört aber auch die tiefe Integration mit den Lieferpartnern (Network).
• Als Nebeneffekt wird ein Parallelgeschäftsmodell aufgebaut, in dem die hervorragenden Teile, die Tesla im Bereich von Elektroautos entwickelt, auch von anderen Herstellern verwendet und bezogen werden. (Geschäftsmodell)

Man sieht also nach kurzer Analyse, dass Tesla nicht einfach ein tolles Elektroauto baut, sondern sich mehr Gedanken gemacht hat.

Tesla – Innovationsbreite und -tiefe

Noch ein anderes Beispiel:

• Der Erfolg des iPhone beruht natürlich nicht einfach darauf, dass es ein tolles Smartphone ist (Produktangebot),
• sondern auch in der kompletten Plattform aus iTunes und der Vernetzung in Mac OS (Produktumgebung).
• Zusätzlich sind die neuen Modelle wie iTunes, iBooks (Geschäftsmodell)
• sowie die Partnernetzwerke, die darüber erreicht werden (Netzwerk)und der damit integrierte Content ein weiterer Bestandteil des Erfolgs.
•  Die starke Markenbotschaft (Marke)
• sowie die ausgebauten Kanale Retail (Apple Store) und Online tun ihr übriges. (Kanal).

iPhone / iTunes – Innovationsbreite und -tiefe

So kann man jetzt unzählige erfolgreiche Beispiele durchdeklinieren.

Ach ja, das ist hier natürlich in aller Kürze. Darüber könnte man Bücher schreiben. Was heißt könnte? Doblin selbst hat eins darüber geschrieben und in Vijay Kumar’s Buch kommt TTOI auch als eine der 101 Design Methods vor. Man kann natürlich auch mit uns darüber sprechen J

Das gibt es auch in der Form und auf der Ebene von „Das muss blau sein, der Button muss rechts oben sein.“ Die Ebene, auf der es passiert, ist egal. Denn was passiert, ist das Falsche. Es ist Aktionismus. Es ist Dinge machen, um Dinge zu machen. Es ist sinnlos.

Und so sieht es in den Firmen aus: Alle machen Dinge, kaum einer weiß, warum und schon gar nicht, warum diese Dinge und nicht andere. Der Zufall regiert und zwar der Zufall, wen der Chef so trifft.

Aber: Machen klingt toll, und es dominiert die Firmenkulturen. Ist nicht „Ein Macher sein“ voller Lob? Macher sind tolle Kerle. Vielleicht sogar Helden? 

Wir dagegen glauben, einfach machen ist erst einmal unreflektiert. Und die Firmen sind voll von dieser Mentalität. Die extrovertierten Alphamännchen übernehmen das Sagen und dominieren die Kultur mit der Macherei. Die introvertierten Delta- bis Omegamännchen und -weibchen schauen zu und denken sich ihren Teil. Was sollen sie auch anderes tun!?

Und all die Macherei führt genau dazu: Mehr Macherei. Jeder ist beschäftigt und macht irgendetwas. Mit der Betonung auf irgendetwas. Denn was den Machern zum echten Erfolg fehlt ist: Tiefe und Zweck. Und alles hat seinen Ursprung darin, dass es den Machern um sich selbst geht und um ihre Energie, von der sie getrieben sind (und die wir eigentlich schätzen und gut gebrauchen können!), aber nicht um die Firma.

Das kann man daran erkennen, dass sie sich im Bezug auf einen Firmenzweck oder eine Vision jenseits von ‚Wir verdienen Geld‘ recht schwer tun und wenn, dann nur mit viel Mühe zu einer Vision und Strategie zu bewegen sind. Und sie werden die ersten sein, die sie verwerfen sobald sich die Gelegenheit ergibt etwas zu machen: Das nächste Feature, die nächste Initiative, die nächste Akquisition.

Und wieder rennen alle rum und machen irgendetwas – denn der Macher hat genug Ideen, um uns alle machen zu lassen. Nur das Ziel ist keinem mehr klar. Wofür sind wir noch mal da?

Aber was passiert denn da?

Betrachten wir Produktarbeit oder Innovation oder Produktdesign und nehmen ein Framework, welches die unterschiedlichen Aspekte beschreibt, dann kommt dabei etwas wie folgendes heraus. Wir durchlaufen hochgradig nicht-linear und iterativ Phasen wie:

1. Sense Intent
2. Know Context
3. Know People
4. Frame Insights
5. Explore Concepts
6. Frame Solutions
7. Realize Offerings 

Das Modell ist natürlich geklaut und stammt von Vijay Kumar und wird in seinem tollen Buch „101 Design Methods“ beschrieben.

Es spielt hier aber nur eine untergeordnete Rolle um etwas zu verdeutlichen. Vijay Kumar tut uns noch einen großen Gefallen und ordnet die Phasen wie folgt konzeptionell:

Wenn man sich nun fragt, mit welchen der ‚Modes‘ man am seltensten beschäftigt ist, dann gibt es typischerweise folgende Antworten: 

Typische Antworten: Welche Modes werden NICHT durchlaufen?

Leute beschäftigen sich also selten damit, den Kontext Ihrer Kunden kennenzulernen. Oder – genau so schlimm –  den Kontext der angestrebten Lösung im Markt, im gesellschaftlichen Kontext usw, zu studieren. Oder, auch schlimm, das Problem in einen neuen Zusammenhang zu stellen, neu zu ‚framen‘.

Tatsächlich ist dies der Kern von Service Design, Experience Design oder gar Innovation in sich: ein Problem von möglichst vielen unterschiedlichen Warten zu betrachten und aus diesen, neu gedachten Perspektiven, zu lösen.

Im obigen Bild kann man jetzt leicht erkennen, dass wir uns die wenigste Zeit für die Modes geben, die im Bereich von ‚Understand‘ liegen. Die meiste Zeit sind wir damit beschäftigt, uns im ‚Make‘-Bereich zu bewegen. Denn: Make wird verstanden. Make ist sichtbar.

Im Bereich von Make riecht man die Aktion. Der Kulturbruch kommt im Konzeptionellen: Die Insights aus dieser Phase sind schlechter sichtbar, müssen verkauft werden, müssen – bei größerem Unverständnis – besser kommuniziert werden. Sieger sind Macher. Loser sind ‚Denker‘.

Der Witz ist natürlich, dass auch wir unser ‚Understand‘ in konkreten ‚gemachten‘ Ergebnissen wie Prototypen fassbar und erfahrbar machen. So werden bei uns auch ‚Denker‘ zu Siegern und ‚Macher‘ zu Losern. Der Macher wird jetzt zum Loser, weil er nur Lösung denkt, aber den Problemraum nicht verstanden haben kann. Er denkt natürlich, dass er das intuitiv hinbekommt … aber das ist One in a Million, ein Zufall, wenn es mal klappt.

Kurz gesagt ist also das Pareto-Prinzip von Produktentwicklung: Es einfach machen. Aber was wir machen müssen, ist eben all das was links von der ‚Machengrenze liegt’, weil die dominierenden Macher schon von sich aus dafür sorgen, dass wir in den Modes auf der rechten Machtenseite arbeiten.

Dem müssen wir Tiefe und Validität und Seriosität der linken Seite entgegensetzen. Den Mut finden, sich in der Firmenkultur gegen das simple Machen, das Exekutieren von vorgeschlagenen Lösungen zu stemmen und das Understand dagegen zu setzen. Und mit den Erfolgen immer mehr dafür zu werben, dass das notwendig ist und vor allem, dass es machbar ist. Es ist machbar, weil es einfach ist:

• Man muss einfach mal einen halben Tag mit Kollegen darüber nachdenken, welches Problem man überhaupt mit welcher Absicht lösen will (Sense Intent). 
• Alle müssen sich einfach mal ein bisschen Zeit nehmen um Recherche zum Problemkontext im Internet zu machen, vor Ort (einfach so) und am Ende das alles mal zusammenzufahren und ein Modell davon zu machen. (Know Context)
• Man muss einfach mal rausgehen und Kunden oder auch Nichtkunden interviewen und ihren Alltag wieder kennenlernen. Das geht auch bei Starbucks oder im (letzten) Tante Emma Laden um die Ecke. Das geht wirklich! Und das nicht erst beim Testen, da ist es schon zu spät! (Know People)
• Und bevor man anfängt zu machen, muss man alles was man gelernt hat einfach mal von außen unter verschiedenen Blickwinkeln betrachten und schauen ob alles wir uns ausgedacht haben oder was der Macher vorgeschlagen hat immer noch so schlau aussieht. Das ist vielleicht das Schwerste, zugegeben. (Frame Insights)

Und für all das braucht man im Zweifelsfall nicht mal uns (obwohl das gerne für euch oder – noch viel besser – mit Euch machen!) oder andere tolle Agenturen. Gerade das kann man jetzt wirklich einfach mal machen. Kunden gibt es fast überall auf der Straße oder über den hauseigenen Service oder oder oder. Ansonsten braucht man Willen, Disziplin und ein bisschen gestohlene Arbeitszeit. Das geht schon.

Und am Ende geht alles ganz machermäßig schnell: Paula Scher hat das Logo für die Citi Group in „einer Sekunde die 34 Jahre gedauert hat“ gesketched („It’s a second done in 34 years“). Jeder kann die Geschichte dazu selber googeln.

Sketch of citi group logo by Paula Scher, 1998

Der Witz ist jetzt aber: Sobald die Balance zwischen Machen und Verstehen wieder da ist, verändert sich im Unternehmen der Gesamtblick auf alles und ‚einfach machen‘ sieht plötzlich dumm aus. Dafür wächst jetzt das richtige Verständnis dafür, dass Verstehen die Grundlage ist, die Umsetzungsenergie aber vom Machen kommt!

Wie so oft ist es also wichtig, dass man die beiden Kräfte explizit macht und jeweils am rechten Ort auf die richtige Weise nutzt und so echter Respekt für die beiden Seiten entsteht.

Da aber in den allermeisten Firmen erst einmal ein krasses Ungleichgewicht zu Gunsten von Machen besteht, heißt es erst einmal ganz viel Verstehen entstehen zu lassen. Und damit ist fast überall das Pareto Prinzip von guter Produktarbeit: Einfach mal mehr Platz fürs Verstehen machen.

Danke für das Titelbild an Noé Lecocq verwendet unter CC Lizenz

Ein Gastbeitrag von Max Wambach

Die Integration  von User Experience (UX) Design in die tägliche Arbeit von Product Management Abteilungen ist nun schon seit längerer Zeit ein wichtiges Thema. Meist drehen sich diese Diskussionen um UX und agile Entwicklung, Lean Approaches, benötigte Detailtiefe bei UX Design et al.

UX Designer verwechseln agile Produktentwicklung mit nur einem weiteren Prozess, der mehr Druck aufbaut und den kreativen Prozess zerstört. Häufig wird dabei kritisiert, dass wenig Zeit für einen holistischen Ansatz zur Lösung von Nutzerproblemen bleibt.

Aber warum ist das so? Wo Produktmanager und Entwickler scheinbar keine Probleme sehen, haben UX Designer vielen Vorbehalte.

Ein typischer Werdegang von UX Designern

Ich vermute, dass diese Vorbehalte durch den beruflichen Werdegang von vielen UX Designern hervorgerufen werden. Lasst uns einen kurzen Blick auf die Entwicklung von User Experience Design der letzten Jahre werfen: Viele UX Designer haben als Interaction Designer oder Visual Designer in kleinen bis größeren Interactive Agenturen gearbeitet.

Daneben gab es noch das Berufsfeld des Usability Engineers (erinnert sich noch jemand?), der häufig in größeren Firmen in der Produktentwicklung gearbeitet hat.

Durch die Natur des Wasserfallprozesses und der Kunde-Agentur-Beziehung war die Wertschöpfung dieser Berufsgruppen durch den Output am Ende der Prozessblackbox gekennzeichnet. Kunden mussten und wollten das Arbeitsergebnis nach jeder Prozessphase absegnen. Ganze Büchern von Dokumentation in Form von Wireframes, User Flow und Use Case Diagrammen wurden erstellt, kritisiert und unsere Kunden wussten wofür sie UX Designer bezahlten: schöne Deliverables.

Dass diese Ergebnisse jedoch häufig nur zum Bruchteil für die eigentliche Produktentwicklung benutzt wurden, war unwichtig – UX Designers Platz innerhalb der Wertschöpfungskette war offensichtlich, definiert durch Deliverables. Auch schaffte es die klar definierte Value Proposition von UX Design und Research, dass UX als kritischer Faktor für den Produkterfolg erkannt wurde.

Dank dieser Entwicklung haben Manager bald erkannt, dass es sich nicht lohnt, diese Ressource für allzu lange Zeit extern zu verorten. Externe Ressourcen skalieren in einem agilen Entwicklungsumfeld nicht sehr gut. Manager brauchten UX Designer, die tagtäglich, iterativ und kontinuierlich an der Verbesserung ihrer Produkte arbeiten.

Lass die Integration beginnen

Als Folge wurde Designer angestellte, die meist einen Agenturhintergrund mitbrachten. Ihre Aufgabe bestand daran eine UX-Abteilung aufzubauen und was sie mitbrachten war eine holistische Sicht auf das Produkt, einen Wunsch die UX des Produkts zu verbessern und eben auch eine klare Sicht auf Ihren Platz in der Wertschöpfungskette.

Aber plötzlich war die Arbeitsweise eine andere. Pragmatisches, Team-basiertes, kollaboratives UX Design ist plötzlich wichtiger. In seinem Essay „Getting out off the deliverables business“ beschreibt Jeff Gothelf, Autor des Buches „Lean UX“, wie UX Designer ihre alleinige Ownership von Konzept und Design aufgeben sollen und besser über die Experience, die sie dem Nutzer bieten wollen, iterieren sollen:

„The trick is to stay lean: keep the deliverables light and editable. Eliminate waste by not spending hours getting the pixels exactly right and the annotations perfect.“

Zwei Arten von UX-Wertschöpfung

Obwohl Gotthelfs Artikel fast 2,5 Jahre alt ist, habe ich das Gefühl, dass wir aktuell noch mit zwei verschiedenen Arten von UX-Wertschöpfung zu tun haben.

Die erste Variante ist gewohnter für traditionelle UX Designer, da sie sich näher am Arbeitsprozess einer Agentur befinden. Externe Produktstakeholder innerhalb der Firma benötigen Deliverables, um den Wert der teuren UX Designer anzuerkennen. Insbesondere das mittlere bis höhere Management, Marketing und Sales benötigen den Output von UX Design, um deren Wert anzuerkennen – auch wenn dieser Output nie dazu benutzt wird das eigentliche Produkt zu entwickeln. Der Wert von UX liegt in den Deliverables.

Die zweite Variante kommt näher daran wirklichen Customer Value zu generieren und ist zu bevorzugen, wenn Designer mit agilen Teams zusammenarbeiten. Deliverables werden als Kommunikationsmittel benutzt, um die angestrebte User Experience zu verdeutlichen. Dadurch weiß jedes Teammitglied welches Nutzerproblem gelöst werden soll.

Kurz: Wenn Entwickler eine Visual Design benötigen, um klar darüber zu werden, was entwickelt werden soll – designe. Falls nicht, dann nicht. Wenn das Team mehr Nutzerwissen benötigen – geh nach draußen und hol es dir. Was auch immer das Team unterstützt in seiner Produktvision klarer zu werden, sollte das Team gemeinsam angehen und durch den UX Designer finalisiert oder vereinfacht werden.

Der Unterschied zu Variante 1 ist, dass das Team den Wert von UX nicht durch Slides des letzten User Research anerkennt, sondern den Wert durch Teilnahme am Research selbst erfahren.

UX als Werkzeug Vs. Experience Design

So lange die Mehrheit der Firmen noch Probleme damit hat, den Wert, der von Experience-fokussierten Design kommt, anzuerkennen, sollten UX Designer sich darauf einstellen, Deliverables nur als Grundlage zur Kommunikation mit Stakeholdern zu nutzen. Deliverables sind das Toolkit für UX Designer, um ihren Wert für unerfahrene Stakeholder zu kommunizieren. Ich nenne das UX als Verkaufswerkzeug.

Experiencing vs. Tooling

Das Hauptaugenmerk von UX Designern sollte aber darauf basieren, Wert durch die Experiences, die designed werden, zu erschaffen (User Experience Design). Das Team zu beraten und komplexe Zusammenhänge durch die richtigen, pragmatischen und schlanke Deliverables (Research-Ergebnisse, Interaktions Designs, Visuals etc.) zu vereinfachen, muss die Hauptwertschöpfung von UX Designern sein. Darüber hinaus, stimme ich vollkommen mit Gothelf überein:

„UX designer are keepers of the product’s vision.“ 

Je kollaborativer UX Design wird, desto wichtiger ist es, dass der UX Designer eine UX Vision behält und das Team auf den nutzerzentrierten Weg führt. 

Hier müssen Traditionalisten ihre Wertschöpfungskette überdenken. Es reicht nicht mehr aus „nur“ ein guter Interaction Designer zu sein, um ein eine holistische Sicht auf die User Experience zu haben. Interaction Designs können keinen allumfassenden Wert liefern, wenn das Design nicht aus User Research abgeleitet werden kann und nicht zu einem zur Experience passenden visuellem Design führt.

Je interdisziplinärer agile Teams werden, desto mehr müssen sich UX Designer daran anpassen und neue Skills erlernen, um die richtigen Deliverables zur richten Zeit in der richtigen Detailtiefe zu erstellen.

Autor: Max Wambach

Max – at ease

Wir sind stolz und dankbar, dass Max Wambach diesen Beitrag für unser Blog geschrieben hat. Max ist ein phantastischer UX-Designer der neuen Generation und hilft uns und in unserer Umgebung UX Design so leichtgewichtig zu machen wie möglich, aber auch so tief wie nötig. Folgt Max auf twitter und schaut seine Homepage an. Vielen Dank für all die Mühe und den tollen Beitrag!

Max arbeitet mobile.de, ebay’s Marktplatz für Automobile

Viel Spaß!

Vor allem aber auch, weil wir uns dem lebenslangen Lernen verschrieben haben! Und tatsächlich wollen wir immer noch mehr zu Lean Kanban lernen, da Kanban uns immer wieder hilft, unsere Ideen dann auch umzusetzen.

Markus mit Fridel von Jimdo

Also gut – was haben wir gelernt? Vor allem, dass sich die Speerspitze im Kanban immer weniger mit der Mechanik der Boards beschäftigt. Im Kern geht es um Modernes Management und die Werte dahinter. Vor allem eine Gruppe, die David Joyce, Mike Burrows, Karl Scotland umfasst, beschäftigt sich mit den Werten, die hinter Kanban stehen.

Und tatsächlich ist die Beschäftigung mit den Werten genau das, was Lean schon immer ausgemacht hat. Wer Taiichi Ohno (und auch Deming!) liest, wird feststellen, dass Lean – und eben auch Lean Kanban – stets auf tiefen Respekt vor den Mitmenschen und Mitarbeitern basiert.

Genau das ist dann auch meist der echte Bruch in den Kanban-Implementierungen, dass es am Ende nicht um Rechthaben geht oder um die Position im Unternehmen, sondern dass Kanban auf gewisse Weise unabhängig davon Fakten ins Spiel bringt. Diese Fakten lassen dann die besseren Entscheidungen zu als die üblichen politischen oder positions-/machtbasierte Entscheidungen.

Mike Burrows explains the agendas of Kanban

Ein weiterer großer Trend beschäftigte sich mit Change, dem Wandel im Unternehmen. Und in diesem Zusammenhang mit Kanban als Katalysator für steten Wandel im Unternehmen. Dabei helfen die o.g. Werte, den Wandel in die richtige Richtung zu treiben und so eine lernende Organisation zu schaffen, die es auch gelernt hat, sich ständig selbst zu verbessern – meist in kleinen Schritten, Tag für Tag.

Wenn nötig kann dieser Wandel aber durchaus auch einmal radikal sein. Dieser Trend wird vor allem von Klaus Leopold und Sigi Kaltenegger stark geprägt.

Klaus Leopold – thinking

Ein anderer Teil der eher theoretischen Betrachtungen beschäftigt sich mit den Grundlagen von Entscheidungen – basierend auf Komplexitätstheorie, Logik aber auch Psychologie. Hier werden die Ergebnisse von Dave Snowden (Cynefin, Komplexität) und Daniel Kahnemann in die Grundlagen der Theorie mit eingearbeitet.

Von Snowden kommt die Erkenntnis, dass vieles der Wissensarbeit im komplexen Bereich spielt, d.h. ohne klare Ursache-Wirkungs-Wechselwirkungen. Zum einen bedeutet dies, dass Innovation (oder Neues generell) im komplexen Bereich erzeigt wird, aber im komplizierten Bereich ausgenutzt, gehebelt wird.

Zum anderen heißt es aber auch, dass man es hier mit gewissen Unsicherheiten zu tun hat, die ein anderes Arbeiten als im Bereich der Gewissheit bedingen. Kahnemann beschreibt das von der psychologischen Ebene, indem er klar macht, wie wenig wir teilweise Herr unserer eigenen Entscheidungen sind und wie wenig rational diese zum Teil von statten gehen.

Eine Parallele dazu in der Logik ist, dass bestehendes Wissen durch induktive und deduktive Logik ausgedrückt wird, neues wissen aber nur durch abduktive Logik erarbeitet werden kann. Dafür ist aber eine andere Arbeitsumgebung notwendig. Dazu hat Jabe Bloom einen sehr guten Vortrag gehalten.

Jabe Bloom – mad scientist on logics

Während es sicher einige stören wird, dass sich Kanban in dieser Form auf Konferenzen von der reinen Praxis entfernt, finde ich gerade diese Richtung vollkommen in Ordnung. Meine Erfahrung zeigt mir, dass die reine Übernahme von Praktiken und deren Wiederholung (etwa im Shu-Ha-Ri Modell) eben doch kein tiefes Verständnis für den eigentlichen Zweck und ein fortgeschrittenes ‚Wie’ in der Umsetzung bringt.

Wie viele Organisationen musste ich inzwischen ansehen, in denen Agilität doch nur ein weiteres Dogma war, das von den eigentlichen Werten unendlich weit entfernt war – oder eben doch nur den Wasserfall in kleinere Meilensteine heruntergebrochen hat … der Weg zum Ziel (Releaseplan, Roadmap usw.) stand aber doch vorher fest.

Ebenso oft zu beobachten ist der Slide-Back-Effekt, der besagt, dass ein paar Leute die Stange der Veränderung hochhalten –sobald sie aber weg sind, geht es mit der Änderungskultur gleich wieder den Bach runter. Für mich ist es spannend zu sehen, ob eine Einführung über die Prinzipien und Werte bessere Chancen hat.

Aber keine Sorge – bei der LKCE waren im Programm auch genug Erfahrungsberichte und praxisnahe Vorträge – ich habe mir die meisten davon nur einfach nicht angeschaut.

Der Flur der Weisheiten …

Wer an einem guten Überblick moderner Managementmethoden – weit weg vom Sammelsurium von Management 3.0 – interessiert ist: David Joyce hat mit „Theories of Work“ ein tolles kostenloses eBook ins Netz gestellt, das mit so einigem Quatsch in dieser Beziehung aufräumt.

Aus meiner Sicht sollte Kanban das Whiteboard noch mehr dort als gegeben annehmen wo es Sinn macht und sich noch mehr den Nicht-IT-Disziplinen öffnen. Dazu gehört es aber auch nicht immer nur über Prozessverbesserung zu sprechen. Dann wäre Kanban noch einnehmender.

Ebenso teile ich nicht das Dogma der ausschließlich evolutionären Änderung. Wenn die Umgebung radikalen Wandel verlangt, sollte man ihn einfach vollziehen. Da hilft kein Festhalten am gewünschten Optimum.

Alles in allem ist die LKCE für meine Begriffe die beste Konferenz im deutschsprachigen Raum, mit tollen Keynotes, einem tollen, diversen Programm, ziemlich weit vorne weg (für einige vielleicht zu weit) und für mich fester Bestandteil meines Terminkalenders.

Wir werden versuchen auf twitter auf weitere Konferenzberichte zur LKCE hinzuweisen. Folgt uns hier, um sie mitzubekommen oder weist uns gerne in den Kommentaren auf andere Berichte hin!

Alle Bildrechte bei LKCE13!

Ein Symptom, dem wir immer wieder begegnen ist, dass die Warteschlangen vor PD vollkommen unbeherrscht sind. Eventuell werden diese nicht einmal bewusst wahrgenommen, oder sie werden als gottgegeben hingenommen – wie in einem lausigen Supermarkt. (Nebenbei erwähnt ist es kein Zufall, dass das Kanbanprinzip auch als Supermarkt bekannt ist.)

Man bemerkt das an einem gewissen Chaos, an Umtriebigkeit und an einer gewissen Ziellosigkeit. Jeder im Produktmanagement ist unheimlich beschäftigt, eine Timeline (Deadline?) jagt die andere (oder: wartet auf die andere?), eine verstreicht nach der anderen, bedient eher ein Gantt Chart als einen Kunden, aber nichts passiert – weder im Positiven noch im Negativen. Was wir tun wirkt belanglos und irrelevant. Der Zynismus ist König in dieser Umgebung.

Schauen wir in die anderen Abteilungen, herrscht blankes Entsetzen, Resignation oder schon offene Abneigung und Abgrenzung uns gegenüber. Wir selbst sind unzufrieden, weil wir tausend Dinge anfangen (müssen?), aber kaum etwas fertig bekommen, das allerwenigste im Zeitrahmen und nichts davon in der Qualität, die wir uns selbst schuldig sind.

Unsere Product Development Abteilung gleicht einem Hot Dog Stand am Brandenburger Tor, der alle 10 Minuten 3 Hot Dogs ausliefern kann. Tatsächlich steht aber vor unserem Laden eine Schlange bis zum Reichstag. Unser Werbung behauptet ja auch „Beste Hot Dogs, immer frisch und schnell!“

Wer sollte da woanders bestellen? (Wer darf, wer kann?) Da stehen sie also, hunderte von Kunden, hungrig auf den fetten, saftigen Hot Dog, den wir ihnen versprochen haben, und alle denken, sie kommen bald dran. Der zwanzigste in der Schlange wartet aber schon eine Stunde.

Saftiger Hot Dog ()*

Natürlich sind wir nicht blöd und bemerken die ganze Sache recht fix. Damit mehr Leute bedient werden, verkaufen wir keine Hot Dogs mehr sondern stückeln die, so dass unsere Kapazität sich verdoppelt. Gute Idee – nur bekommt keiner unserer Kunden mehr einen Hot Dog und während vorher noch alle 10 Minuten 3 Leute zufrieden gestellt wurden und glücklich davon zogen, ist nun niemand mehr ein glücklicher Kunde.

Wir haben uns hoffnungslos verzettelt und schicken alle Kunden mit Stücken von Hot Dogs nach Hause. Wir denken sogar, der Preis sei noch ok. Kurz: In der Hektik haben wir die vollkommen falsche Analyse gezogen, um dem Ansturm gerecht zu werden.

Hot Dog zerfleddert (**)

Es wirkt absurd – aber das ist wirklich was in vielen Firmen passiert. Was man bei einem Problem zu großer Nachfrage machen müsste wäre natürlich erst einmal die Nachfrage zu analysieren. Quantitativ und qualitativ, also: Wie viel wollen die Leute von mir und genau was?

Fangen wir an mit der Menge! Im Hot Dog Beispiel wird klar, dass man viel zu viel von uns will. Eine Lösung scheint nicht in Sicht! Wir könnten mal eben mehr Hot Dog Köche einstellen, aber: Kein Budget, und das skaliert bei Produktentwicklung nicht. Wir könnten die Hot Dogs schneller zubereiten, aber: Die Qualität, und – wie zaubern?

Wir könnten Finetuning betreiben. So habe ich beispielsweise mal einen schlauen Imbissverkäufer mit einem T-Shirt „Ketchup links, Senf rechts“ gesehen, um lästige und laaaangsam machende Fragen zu vermeiden und dennoch das Problem zu lösen. Aber das wird uns nicht entscheidend schneller machen.

Wir könnten … Tee oder Glühwein verteilen. Alle wäre ein bisschen glücklicher, aber das Problem wäre immer noch nicht gelöst. Oder wir könnten einfach den Leuten reinen Wein einschenken und ganz blöde ein Schild hinstellen: 3 Hot Dogs alle 10 Minuten. Moment! Was heißt denn das?

Wir würden also einfach allen sagen, was und wie viel wir davon machen können. Das wiederum ist gar nicht schwer. Und die Wirkung dieser Transparenz ist umwerfend. Es ist ein bisschen wie „Reden hilft“. Denn, halt mal, wir sind ja gar kein Hot Dog Stand, der dem Ansturm wehrlos ausgeliefert ist.

Wir sind ja Teil eines Ganzen, einer Firma! Einer Firma, in der wir  – zumindest gefühlt – das Bottleneck sind. Und niemand in der Firma hat etwas davon, dass wir das Problem bleiben. Damit sich andere aber dafür interessieren uns zu helfen, müssen sie unsere Situation kennen.

Dafür bauen wir einfach ein Board auf, auf dem sich alle Projekte (Epics, Features, was auch immer) befinden, an denen wir arbeiten. Jetzt kann jeder sehen was los ist. Vor allem aber kann und muss jetzt jeder mitdenken, welche Aufgaben uns am sinnvollsten gegeben werden, um das Beste aus unserer Kapazität zu machen. So vermeiden wir lokale Optimierung ohne Sinn und Verstand und bevorzugen globale Optimierung über das ganze System.

Wir bieten alles mögliche (**)*

Aber noch mal Stop! Wenn wir genau hinsehen, verkaufen ja nicht nur Hot Dogs, sondern auch Pommes, Currywurst usw. D.h. wir müssen uns noch anschauen, welche Produkte und Services wir intern anbieten, wer unsere internen Kunden sind. Wie Peter Drucker fragen würde: „Was ist eigentlich unser Geschäft?“

Wenn wir das analysieren, können wir auch besser beantworten, auf welche ‚Bestellungen’ wir regelmäßig eingehen müssen, wie groß sie sind, welche eher mal ausnahmsweise kommen usw. Und jetzt können wir erst einmal eine wirklich gute Wand bauen, an der alles steht, was wir machen, fein säuberlich strukturiert nach der Art der Bestellungen und Stakeholder.

Wenn wir das lange genug gemacht und analysiert haben, verstehen wir besser ‚Was unser Geschäft ist“ und was unsere Aufgabe ist. Und genau hier liegt das Problem begraben, dass die meisten Firmen diese Situation gar nicht analysieren, sondern einfach irgendwie nach Gefühl und Wellenschlag ‚halt Projekte liefern’. Wer Kahnemann liest weiß, was das bedeutet: Blindflug ist ein höflicher Ausdruck dafür.

Viele Firmen (meist die, die eigentlich von Zahlen dominiert werden) sind einfach unheimlich schlecht darin, ein quantitatives Modell ihres Geschäfts zu haben. Kategorien wie Cost of Delay oder generell ökonomische Modelle von Produkten und Projekten sind Fehlanzeige oder rein subjektiv und damit mit massiven Schwankungen behaftet.

Sachliche Priorisierung ist solchen Kontexten unmöglich. Das alles muss entwickelt werden, damit sich die Mühe auszahlt, die wir uns geben um Transparent zu liefern.

Aber all das hat bis jetzt nur die liefernde Seite von Product Development als „Dienstleister“ angerissen. Was noch fehlt ist die gestaltende, eigenständige Seite – und die wiederum geht ganz anders. Über die reden wir demnächst.

(*)  Some rights reserved by rob_rob2001

(**)  Some rights reserved by hifix

(***)  Some rights reserved by Marshall Astor – Food Fetishist

Titelbild:  Some rights reserved by *sax

Praktiken die damals – zurecht – ersonnen wurden um die effizientere Produktion physischer Güter zu befördern, werden heute immer noch angewandt ohne zu bedenken, dass die Aufgaben und der Kontext sich seitdem dramatisch geändert haben. Command & Control dominiert noch immer die meisten Arbeitsumgebungen, die wir beobachten können – wenn es auch manchmal geschickt getarnt daherkommt.

Über dieses Wissen hinaus gibt es natürlich seit langem eine große Zahl von Menschen, die sich mit neuen Wegen beschäftigen und damit experimentieren, wie Komplexität und schnelle Veränderung in einer vernetzten Arbeitswelt zu beherrschen ist. Und noch einmal: die Realität, die wir in Unternehmen beobachten, unterscheidet sich dennoch drastisch von unserem Wissen.

Firmen werden über Metriken gesteuert, nicht über eine höhere Aufgabe, ihren Zweck in der Gesellschaft. Mitarbeiter werden gemessen an abstrakten KPIs, die irgendwann einmal von Zweck und Strategie und Kundenwert abgeleitet wurden. Inzwischen haben diese KPIs längst Zweck und Kundenwert ersetzt und ihre Verbindung zum eigentlichen Zweck und Wert ist verloren gegangen.

Das Resultat sind Firmen, die in Geschäftigkeit untergehen ohne Kundenwert, Begeisterung oder Loyalität zu erzeugen. Alle sind tagein, tagaus damit beschäftigt ‚Dinge zu tun’ und Metriken zu beobachten. Die Frage nach dem Kunden wirkt verstörend. Die Zahlen werden gepimpt, die Auslastung optimiert, beides zu Lasten von Qualität und Kundenwert.

Silos werden erzeugt, die ihren Zweck lokal optimieren, aber im Gesamtsystem nicht mehr funktionieren, weil jedes Silo dazu geschaffen wurde seine lokalen KPIs zu erfüllen. So fällt es Firmen schon wenige Jahre nach der Gründung schwer echten Kundenwert zu erzeugen, weil die geschaffenen Silos nicht mehr koordiniert werden können um übergreifende Aufgaben zu erfüllen – was nötig wäre um sinnvolle Kundenwerte zu erzeigen.

Die sich selbst bedienenden Abteilungen stehen sowohl dem „doing things right“ als auch noch mehr „doing the right thing“ im Wege.

David P Joyce ermöglicht uns mit seinem brillanten eBook „Theories of Work“, welches er frei unter  www.theoriesofwork.com anbietet, die vielleicht beste Vertiefung dieses Themas seit Jahren.

Wie schon erwähnt existiert das Wissen um „das Richtige“ und „bessere Wege“ seit langem. Und dementsprechend beschäftigen sich auch einige wenige seit langem damit. Als ich vor ca. 2 Jahrzehnten in meinem ersten Job auf der Kippe zum Management zum ersten mal das Gefühl hatte „das irgendwie ok“ zu machen, aber eigentlich doch keine Ahnung davon zu haben, ging ich in eine Buchhandlung und kaufte mir – schlicht nach Cover – ein Buch um erst einmal zu lesen „wie man das eigentlich macht“.

Ich hatte Glück – es war ein Buch von Peter Drucker. Und was war ich begeistert! Er hatte einfach alles schon herausgefunden! Ehrlicherweise habe ich ihn seit ca. 15 Jahren nicht mehr gelesen, aber er hat bis heute einen tiefen Einfluss auf mein Denken und Tun.

Ich hatte wohl einfach Glück. Rückblickend denke ich, er ist heute so aktuell wie damals und das generelle Bild, das er vom Management erzeugt ist bis heute richtig. Was mich zum ersten Event führt, das ich empfehlen will:

Das Drucker Forum 2013 in Wien am 14./15. November 2013

Der Blick auf die Liste an Vortragenden und Inhalten ist einschüchternd und gleichzeitig begeisternd. Gleichzeitig ist das Angebot vielfältiger als der Titel vermuten lässt. Leider habe ich die Konferenz erst vor wenigen Tagen entdeckt und werde nicht teilnehmen können.

Ich hoffe, Dir ergeht es besser. Ich bin mir sicher, die Konferenz wird viele begeistert und inspiriert, vielleicht aber auch enttäuscht vom eigenen Arbeitsplatz hinterlassen.

Eine der wichtigsten und interessantesten Bewegungen der letzten Jahre im Umfeld von Software- und Produkt-Entwicklung der letzten Jahre ist Kanban. Kanban ist im Wesentlichen eine Methode um kontinuierliche Verbesserung in Unternehmen einzubringen und integriert vielfältige Einflüsse von Ohno, Deming, Drucker und anderen.

Und jedes Jahr gibt es viele, intensive Events, die sich mit der Weiterentwicklung der Methode beschäftigen. Ein nicht zu kleiner Teil dieser Events findet im Herbst verstreut über Europa statt. Die Konferenz, die mir am meisten am Herzen liegt ist

Lean Kanban Central Europe 2013 in Hamburg am 4./5. November 2013

Die Konferenz wird von it-agile.de organisiert und mit besonderer Leidenschaft steckt  mein guter Freund Arne Roock hinter der exzellenten Auswahl des Programms und anderen wichtigen Details. Das vielfältige und interessante Programm am Montag und Dienstag wird erweitert durch Workshops und Seminare an den folgenden Tagen, angeboten von den jeweils Besten ihrer Disziplin.

Falls Du zufällig im Berliner Raum unterwegs bist, könntest Du Dich schon beim Red Bead Experiment auf die Konferenz einstimmen.

Arne und ich führen es für die Limited Wip Society Berlin (Kanban User Group) bei Immobilienscout24.de vor. Das Red Bead Experiment ist eine spielerische Einführung in die Management Prinzipien von Edwards Deming. Noch sind Plätze frei!

Lean UX ist auf einer konkreteren Ebene einen Annäherung an einen ‚besseren Weg’. Lean UX – eine nützliche, verdammte Lüge, wie Will Evans sagt – versucht die Sollbruchstelle zwischen tief kreativer und nicht-linearer Arbeit beim Entdecken und Erschließen von Problemen und Möglichkeiten einerseits und den lineareren Prozessen der Softwareentwicklung, also der konkreten Umsetzung der Lösung von Problemen andererseits zu kitten.

Dies ist der Punkt an dem in den meisten Unternehmen Kulturen, Werte, Denkweisen und sogar Logiken aufeinandertreffen und riesige Krater des Unglücks entstehen.

Die nächste Konferenz

Lean UX NYC 2014 from 11  to 13 April 2014

Beschäftigt sich genau mit diesem neuen Ansatz und organisiert die besten Sprecher zu diesem Thema und darüber hinaus. Will Evans sucht sorgfältig ein hochkarätiges Programm heraus und wird dabei kongenial von seiner Firma TLCLabs in der Organisation unterstützt.

Mit Neid habe ich letztes Jahr den tweet stream von Tampere goes Agile verfolgt. Das Programm schien mir zu dem vielfältigsten und herausforderndsten zu gehören, das ich jemals auf einer Konferenz gesehen habe. Das hat in mir den Wunsch ausgelöst, die diesjährige Ausgabe unbedingt vor Ort sehen zu wollen:

Tampere goes Agile ‘Change to Learn – Learn to Change’ on 5 December 2014

Der Call for Papers ist noch offen und es gibt noch freie, kostenlose Plätze!

Das wäre also der Überblick über die Konferenzen, die uns in der nächsten Zeit als relevant aufgefallen sind. Haltet uns bitte in den Kommentaren auf dem Laufenden falls euch noch ähnlich relevante Veranstaltungen auffallen! 

Dank für das Titelfoto an pop culture geek auf flickr, unter einer CC Lizenz

Ich denke, dass ihr Weg wichtige Hinweise darauf gibt, wie man eine blutleere Produktorganisation wieder zum Leben erwecken kann. Mein zugrundeliegender Gedanke dabei ist, dass man gute Produkte nur über das tiefe Verständnis eines Design Prozesses (wie etwa Design Thinking oder Design Studio) und irgendeiner Art agiler Umsetzung hinbekommt.

Also gut – wie hat sie es nun hinbekommen? (Und das kann man alles googeln und nachlesen!)

Folge dem Sog

Um einen Startpunkt für ihren neuen Ansatz zu finden, fing Claudia Kotchka ihre Initiativen dort an, wo die Probleme am größten waren. Das war jeweils bei den P&G Brands mit den größten Überlebensproblemen. Diese Patienten waren so krank, dass sie jede Medizin akzeptierten.

Hole Designer als trojanische Pferde in die Abteilungen

Sie wusste, dass Designer alle Tools und Methoden in ihrem Rucksack hätten, die für die Innovationsarbeit notwendig waren. Auch diese brachte sie dort in die Organisation ein wo die Toleranz für Experimente und Hilfe durch den Überlebensdruck am größten war. Diese wiederum konnten das nächste Prinzip bestens unterstützen:

Zeigen, nicht erklären (Show, don’t tell)

Um schnell Glaubwürdigkeit und Vertrauen zu gewinnen, ist es notwendig nicht lange zu erklären und zu theoretisieren, sondern schnell zu handeln. Mach’ Dir schnell die Hände mit konkreter Arbeit schmutzig, statt ewig  Meetings anzuhalten, in denen man erklärt wie es besser geht. Mach’ es einfach. De Designer waren Multiplikatoren für diesen Ansatz.

Zeige was Design wirklich ist

Die meisten Leute verstehen unter Design ‚Dinge hübsch machen’, also den rein dekorativen Effekt. Dass ‚hübsch sein’ ein Nebeneffekt von harter analytischer Arbeit und ständigen nicht-linear verlaufenden, konvergierenden und divergierenden Phasen ist, ist weniger bekannt.

Ebenso unbekannt, aber zum Verständnis wichtig, ist der iterative Prozess, den Designer durchlaufen, um erst die zu lösenden Probleme und dann den Lösungsproblem immer weiter einzugrenzen, um schließlich mit dem ‚richtigen’ Design herauszukommen. Um dieses Verständnis weiter zu vertiefen, unternahm man

Ausflüge in Design Studios

um die Kultur und Arbeitsweise im Design besser kennenzulernen. Da gab es einige Überraschungen, etwa „dass Designer blaue Haare haben“ oder „dass keiner der Designer an irgend etwas hübschen“, sondern alle an ‚hässlichen’ Lo Fi Prototypen arbeiteten. Das ließ das Eis brechen und schaffte

Verständnis für die Rolle von Prototypen

Viele Firmen „trauen“ sich nicht, „hässliche, unfertige“ Lo Fi Prototypen zu bauen, geschweige denn sie ihren Kunden zu zeigen. Obwohl es ihnen klar ist, dass frühes Erstellen und Testen von Prototypen ein toller Weg zum Lernen und Testen von Annahmen und Hypothesen ist, haben viele Firmen aus den unterschiedlichsten Gründen Angst ihren Kunden diese unfertigen Staden ihrer Arbeit zu zeigen.

Der Kunde könnte ja mit „Herrjeh, diese Leute brauchen Hilfe“ reagieren. Und hier sagte Claudia vollkommen selbstbewusst „und das ist genau was wir brauchten: Hilfe!“ P&G baute diese Prototypen, um Hilfe und Input zu bekommen. Und das bekommen sie genau mit diesen rauen Prototypen besser als mit fein säuberlich ausgearbeiteten. Am Ende ermöglichte das darüber erzeugte Kundenfeedback den Turnaround von P&G.

Fehler zulassen

Wenn man einen Prototyp-basierten Design-Prozess einführt muss man unbedingt eine Kultur und Umgebung gestalten, die Fehler zulässt und – mehr noch – umarmt. Die meisten Prototypen sind so gestaltet, dass sie nicht die komplette Idee des Produkts umsetzen, sondern einen einzigen Aspekt.

Damit testet man genau diesen Aspekt oder eine Hypothese zum Produktlösungsraum. Und hier ist jedes Resultat in Ordnung. Bei positivem Feedback scheint man in die richtige Richtung gedacht zu haben. Bei negativem Feedback scheint man einen falschen Lösungsweg gewählt zu haben und hat damit den Lösungsraum ebenso eingegrenzt.

So wie der Wissenschaftler Falsifiziereung bevorzugt, weil diese eben auch den Lösungsraum eingrenzt, müssen wir negatives Feedback begrüßen. Das schlechteste Ergebnis wäre kein Feedback zu erzeugen, weil es der einzige Zweck eines Prototypen ist, in Interaktion zu treten und Feedback zu triggern.

Deswegen ist es auch so wichtig, sich klar zu machen was genau man mit einem Prototypen testen will und welche Interaktion man erzeugen will.

Skunk Works Projekte ermöglichen

P&G hat das berühmte Clay Street Projekt (rate wo!) aufgesetzt, in welchem jeweils ein cross-funktionales Team 10 Mitarbeitern aus der gesamten Firma für 10 Wochen ein hartes Problem lösen sollte. Dabei ging es meist um innovative Ideen, um eine bestimmte P&G Marke wiederzubeleben.

Das Gerücht geht, dass P&G hier eine Erfolgsrate von 100% erzielte. Aber egal – wenn es nur 30-50% gewesen wären, wäre das immer noch phantastisch.

Analytische Denken hinter sich lassen

Eine der größten Schwierigkeiten im Unternehmen ist es, eine rein analytische Denkweise zu verlassen. Rein analytisches Denken steht dem Neuen und Unbekannten im Wege. Die Analyse rein quantitativer Daten gibt keinerlei Aufschluss auf wirkliche Bedürfnisse der Kunden.

(Siehe einen der nächsten Blogs für Details). Der Kunde sagt einem nicht, was er  bald brauchen wird. Auch Fokusgruppen helfen hier nicht weiter – die Form des Kundenkontaks, den sich selbst große Unternehmen noch ohne Gesichtsverlust zutrauen – wenn auch von teuren Agenturen durchgeführt.

(Wer weiß, was sonst alles in direktem Kontakt passieren könnte!). Es sind Methoden wie „Das Gebäude verlasen“ und „mit dem Kunden leben“, welche die echten Einblicke geben und Bedürfnisse vermitteln. Sämtliche Begleiterscheinungen einer Kultur, die lediglich datengetrieben die Vergangenheit in die Zukunft extrapolieren, behindern die Ergründung des Neuen und Unbekannten.

Schließlich beruhte der Erfolg der Einführung von Design Thinking bei P&G grob auf  folgenden Prinzipien:

• Motiviere Mitarbeiter über einen höheren Zweck (Purpose), nicht über Geld.
• Empathie
• Bringe die Disziplinen zu cross-funktionalen Teams zusammen
• Gestalte eine Kultur und Umgebung die Fehler gestattet
  • Es gibt keine Fehler mehr
  • Setze (frühe) Prototypen ein
• Geduld
• Vertrauensvorschuss 

Ich denke, diese Prinzipien passen für jede Organisation, die den Weg heraus aus einem sinnleeren und intern fokussierten Tunnel in ein von Kundendürfnissen und Kundenwert getriebenes Produktumfeld sucht

Was sind Eure Erfahrungen?

P.S.: Ein dickes Dankeschön und größte Bewunderung an Claudia Kotchka, die das alles in diesem Vortrag so natürlich und einfach aussehen ließ. Ihre Bescheidenheit war bewundernswert!

Letztens haben wir darüber geschrieben, dass Firmen stetig Innovation treiben müssen, um nicht rechts von anderen überholt zu werden. (Das darin verwendete Beispiel Nokia macht es ja tagesaktuell noch einmal deutlicher.)

Und wir haben auch erwähnt, dass es in der Realität oft anders aussieht: Firmen einer gewissen ‚Reife’ sind eher auf Wirtschaftlichkeit und das Auspressen des aktuellen Geschäftsmodells fokussiert. Der Name dafür ist oft ‚Operational Excellence’. Wie der Name schon sagt, geht es hier um ‚Operations’, den reinen Betrieb des Geschäftsmodells.

Das große Problem dabei ist, dass in dieser Phase das wofür die Firma eigentlich da ist vollkommen verwässert wird oder gar verloren geht und sich das Angebot radikal verschlechtert. Gleichzeitig greifen die Effizienzmaßnahmen selber auch nicht.

Innenfokus durch Operational Excellence

Denn während eine Firma im Aufbau des Geschäftsmodells gezwungenermaßen nach außen fokussiert ist und die Wünsche der Kunden erfüllt, ist eine Firma in der ‚Operational Excellence’-Phase zwangsläufig nach innen fokussiert:

• Wo kann Geld gespart werden?
• Wo kann effizienter gearbeitet werden?
• Wie können wir unser Konglomerat von Firmen integrieren?
• Wo können Synergien erreicht werden, und so noch mehr Geld gespart werden?

Das ist zum einen sehr verführerisch, denn man riecht förmlich, wie gut man diese Tätigkeiten administrieren kann. Man riecht auch, wie nun Silos und Hierarchien entstehen, an Bedeutung gewinnen, zum Selbstzweck werden und schließlich vollkommen undurchlässig werden.

Genau die Silos,  in denen die Effizienzmaßnahmen umgesetzt werden. Man riecht auch, wie diese Maßnahmen jeweils ‚einfacher’ innerhalb eines Silos umgesetzt werden können, das mit den anderen nicht kommuniziert. Aber auch wie schwer es ist, solche Maßnahmen über Silos hinweg umzusetzen.

Da das nächste Entscheidungskomitee in den nächsten drei Wochen ansteht, ist klar, was jeder Effizienzbeauftragte unternimmt: Er löst das nächst liegende einfache Problem in seiner Abteilung anstatt zu helfen das Gesamtsystem zu verbessern. Schlimmer noch: Diejenigen, die ans Gesamtsystem denken und die Einzelmaßnahme als nutzlos ansehen, sind aus Sicht des geplagten Umsetzers Querulanten.

Die Folgen dieses Vorgehens und dieser Phase ist in dreifacher Sicht tödlich für Unternehmen:

• Der Fokus liegt auf lokaler Optimierung statt auf globaler Optimierung.
• Der Fokus ändert sich von Kundenzentrierung (also nach außen gerichtet) komplett auf das Unternehmen selbst. Der Kunde wird ein unbekanntes Wesen.
• Und schließlich werden Abteilungen, die vorher einen Teil zum Ganzen lieferten, zu Silos und manifestieren sich als solche. Am Ende wird es der Zweck jeder Abteilung, sich selbst zu dienen – die anderen Abteilungen stören eher. 

Lokale Optimierung statt System

Während vorher die Firma als Ganzes, als System wirkte und das Ganze eben mehr war als die Summe seiner Teile, ist die Firma nun nicht einmal mehr die Summe seiner sich im Wege stehenden Teile.

Der Kunde macht das auch noch relativ lange mit. Wie der berühmte Frosch im Kochtopf merkt er lange nicht wirklich was vor sich geht. Ja, der Service war schon einmal freundlicher, die Mailings haben ihn schon einmal besser angesprochen. Aber irgendwann kommen Änderungen in den Systemen und im angebotenen Produkt, die er nicht mehr versteht und die für ihn alles schlechter machen anstatt besser.

Denn bei den Änderungen geht es ja nicht darum, dass ihm besser geht, sondern, dass Services und Produkte vereinheitlicht werden. Services und Produkte, die vor zwei Jahren noch auf ihn zugeschnitten waren. Und hier greift was John Seddon sagt: „Wenn du Kosten verringern willst, werden die Kosten hochgehen“.

Aber auch innerhalb der Firma hat diese Phase erschreckende Folgen. Es ist sehr leicht, sich an echten Erfolgen auf dem Markt zu erfreuen und diese Erfolge zu feiern und seine Motivation daraus zu ziehen. Schwerer ist es, sich am Erreichen (oder auch Nicht-Erreichen) abstrakter Zielvorgaben in ‚KPIs’ zu freuen, die eine Zeile in PowerPoint sind und auf umständlichen Wegen aus 20 Reports in 13 Systemen zusammengefahren werden müssen.

Typischerweise läuft eine Firma in dieser Phase auch nicht etwa 3-5 KPIs hinterher, sondern mehr als 200. Von irgendwelchen umsatzgetriebenen KPIs werden KPIs pro Abteilung, Unterabteilung und letztlich Mitarbeiter, Produktteil usw. abgeleitet. Ein Dschungel, den niemand verstehen kann und der letztlich mit dem K in KPI nichts mehr zu tun hat.

Welche der 200 KPIs sind denn nun Key, also wichtig? Und wer würde durchblicken, was sie bewirken und wo sie miteinander konkurrieren?

Aber was ist der Weg heraus aus dieser Phase? Der ist wiederum auf dem Papier erschreckend einfach, in der Praxis aber sehr schwer.

Kundenwert als Orientierung 

Zu allererst muss der Kunde wieder in den Fokus gestellt werden. Das ist sicher jedem klar. Allerdings ist niemandem mehr klar, was das bedeutet, denn auf den Powerpoints war der Kunde ja immer wichtig und irgendwie hat man Customer Centricity bei allem Geschiebe von KPIs niemals aus dem Auge verloren, oder?

Und die Zahlen gingen doch auch nach oben – da muss ja alles gut sein. Fragt man nun aber, wer denn im letzten Jahr einmal wirklich mit dem Kunden gesprochen hat (das absolute Minimum also), dann ist die Antwort erschreckend: Service und Sales – die können ja nicht anders.

Die Frage ist jetzt, wie man fast jeden Mitarbeiter wieder mit dem Kunden vertraut machen kann, denn jetzt ist das ja schwer. Die meisten Firmen kennen jetzt nicht einmal mehr eine Agentur, die ihnen die Kunden für Workshops, Interviews usw. beschaffen kann.

Zum anderen muss das Management den Weg aus dem Dschungel der KPIs und Ziele leiten. Und das ist ein Riesenwandel: Während bisher die Energie des Unternehmens, der Manager und der Mitarbeiter aus dem Jonglieren mit den ungezählten Unterzielen bezogen wurde muss, man sich nun auf maximal eine Handvoll Ziele für das Unternehmen beschränken.

Intellektuell bringt dass das Problem auf, dass man plötzlich sehr tiefe Diskussionen führen muss, um den Dschungel auf ein paar Bäume und Pfade zu reduzieren. Und das heißt ‚Nein’ sagen zu all den Initiativen, die einem in den letzten Jahren wichtig waren.

Alignment durch übergeordnete Ziele

Das K in KPI sagt ja nicht nur, dass es wenige KPIs gibt, sondern, dass sie auch von den wichtigen Inhalten getrieben werden. Dafür müssen jetzt aber die Inhalte jetzt überhaupt wieder neu verstanden werden. Das heißt, es muss tiefe Diskussionen über diese Inhalte und Ziele geben.

Auch diese können eigentlich wieder nur dann ausgerichtet werden, wenn man den Kunden kennt. Das ist ja der unglaubliche Wert an Kundenzentrierung – man hat immer einen echtes Ziel vor Augen, man muss es nur immer wieder neu entdecken: Die Kundenbedürfnisse. Nun muss es aber nicht nur Diskussionen geben sondern eben auch klare Ergebnisse und diese müssen klar vermittelt werden, so dass die Angestellten diese auch verstehen und von ihnen motiviert werden.

53 Seiten Powerpoint alle zwei Wochen sind dazu denkbar ungeeignet. Hier müssen authentische Manager ihre Visionen sehr persönlich vermitteln. Ein Problem dabei ist, dass die Manager mit dieser Vision inzwischen möglicherweise das Unternehmen verlassen haben. Den Manager mit echten Visionen verstehen sich selten gut mit Managern, die ein Unternehmen verwalten und effizient machen.

Auch hier ist wichtig, dass klar ist, dass es beide Kulturen in derselben Firma geben muss und der Wert der beiden Kulturen explizit gemacht wird. Und vor allem dass diese koexistieren und müssen.

Und nun muss endlich wieder einsetzen, was Stephen Bungay von uns fordert: Der ultimative Spice-Girl-Imperativ des Managements: ‚Tell me what you want, what you really really want’. Darüber kann die Firma wieder auf die echten Ziele Alignment bekommen. Noch besser, wenn die klar priorisiert sind und am besten noch Goal Nr. 1 klar identifiziert ist unter dem alle anderen Ziele im Zweifelsfall leiden müssen.

Und natürlich muss auch dies authentisch und lebendig an die Mitarbeiter vermittelt werden. Vor allem muss dies nun nachgehalten werden. Das bedeutet vor allem den Schutz der Mitarbeiter vor Ablenkung durch andere Ziele. Ein Überfluten der Mitarbeiter mit immer neuen wichtigen Aufgaben muss jetzt unterbleiben .

Und jetzt – erst jetzt – kann man von Empowerment reden und Autonomie von Mitarbeitern erwarten. Denn nun ist das Spielfeld abgesteckt, in dem der Mitarbeiter frei agieren kann. Denn nun gibt es Alignment auf der Ebene von ‚Warum’ und ‚Was’, welches die Autonomie auf dem ‚Wie’ ermöglicht.

Je weiter eine Firma sich in diesem Modell wieder entwickelt, um so eher kann auch die Autonomie auf dem ‚Was’ wieder entwickelt werden. Die Voraussetzung dafür ist natürlich ein Höchstmaß an Vertrauen, welches letztlich durch regelmäßiges ‚back reporting’ erzeugt wird – bei dem bitte nicht ‚reingeredet’ wird sondern nur das Verständnis des Ziels und der Aufgaben überprüft wird.

Ein langer und schwerer aber notwendiger und lohnender Weg. Noch besser ist es natürlich, wenn man nie dort endet. Wenn man also das Innovators Dilemma von Anfang an durchschaut und der Versuchung widersteht, die Innovation der Wirtschaftlichkeit zu opfern. Besser man räumt beiden Elementen von Anfang an den notwendigen Platz ein und schützt beide voreinander. Innovation und Wirtschaftlichkeit müssen in Unternehmen stet koexistieren.

Literatur: Stephen Bungay – The Art of the Action

Foto von Eric Mutrie lizensiert unter Creative Commons

Der Fall wird in MBA Studiengängen gelehrt, man streitet darüber und doch ist relativ klar, was passiert ist und dass es ein Riesenerfolg von Flexibilität war. Das Glück des Wendigen und Tüchtigen.

In den Nachkriegsjahren boomte in Japan der Markt mit kleinen Motorrädern, Mopeds und Rollern. Ein Riesenerfolg war der Honda Super Cub. Honda war ein dominanter Teilhaber an diesem japanischen Markt. Und so lernte Honda sehr gut, wie man diese Modelle mit kleinem Hubraum gut und qualitativ baut und welche Märkte man damit erschließt.

Gleichzeitig gab es in den USA einen Boom an Motorrädern. Harley Davidson dominierte den Markt, damals teils noch mit anderen Modellen und anderem Image als man sich heute vielleicht vorstellt:

Harley Davidson Werbung

Nach Harley Davidson waren es englische Hersteller, die 50% der Motorräder in den USA verkauften. Japaner existierten fast nicht. Die Ausfuhr japanischer Motorräder betrug damals lediglich 4% der Gesamtproduktion.

Allein 1962 verkaufte Honda dann bereits 40.000 Motorräder  in den USA. Der Plan war aber, diese Zahl in 1963 zu auf 200.000 zu verfünffachen. Und das wurde in etwa geschafft.

Kurz gesagt, und das sagt auch Kawashima, der damals verantwortliche Honda-Chef: Die Honda 50 war ein gigantischer Hit. Aber der Weg dorthin war von Umwegen geprägt. Und die gehen so:

Die anziehenden Nachkriegsverkaufzahlen in Japan waren inspirierend für Honda, und die Verkaufszahlen von Motorrädern in den USA ebenso. Weniger inspirierend war, dass man an diesem Markt keinen Anteil hatte. Also plante man dort einzusteigen. Folgerichtig sah man sich den Markt an und versuchte in ihm zu bestehen.

Man wollte im Markt mitschwimmen, analysierte ihn und versuchte den Markt mit Maschinen anzusprechen, die den dort üblichen Modellen entsprachen: Großhubige Motorräder.

Damit stellte sich allerdings kein Erfolg ein. Die Verkaufszahlen blieben unter den Erwartungen. Danach kam es zu einem weiteren Problem. Nicht geübt im Bau größerer Motoren und Maschinen gab es technische Probleme. Motoren überhitzten, Kolbenfresser häuften sich.

Honda beschloss, die fehlerhaften Modelle komplett nach Japan zurückzusenden. Während es furchtbar war, dass es zu den Problemen kam, wurde das kompromisslose Vorgehen in Sachen Qualität von den Händlern honoriert. Ein wichtiger Punkt, da Honda ja ein neuer Spieler auf dem Markt war und gerade erst Händler für sich gewann.

Nun kam ein weiterer Effekt hinzu: Die kleinen Maschinen, mit denen das Verkaufspersonal von Honda die Werkstätten aufsuchte, begannen Händler und Kunden zu begeistern: Die Honda 50 oder auch Super Cup 50 (Japan).

Und nun kam eins zum anderen. Anstatt den Markt so zu bedienen wie es gedacht war, machte man aus der Not eine Tugend und stellte sich vollständig um: Man verkaufte die hochqualitativen 50er, die man aufgrund der Erfahrung zu Hause in Japan seit Ewigkeiten hochqualitativ herstellen konnte.

Natürlich konnte man damit nicht die großen Maschinen verdrängen. Also warb man konsequent mit einem bürgerliche Image und damit dass, ‚you meet the nicest people on a Honda’ (siehe Titelbild). Ein sinnvoller Claim, denn die sechziger kamen auf und weniger bürgerliche Personen hatten inzwischen einen Drang zu größeren, wilderen Motorrädern.

Dazu engagierte man die renommierte Agentur Grey Advertising und drehte mit ihrer Kampagne und einem konsequent bürgerliche auftreten, Verkäufern in Anzügen usw. letztlich das Image einer kompletten Industrie.

„Mothers who once wouldn’t listen to an adolescent child’s plea for a motorcycle began to compromise, saying, „I’ll buy you one, if it’s a Honda.“

In Verbindung mit dem konsequenten Aufbau einer Salesforce, Qualitäts- und Servicedenken gelang der Durchbruch und die Disruption des Motorradmarktes: 1960 befanden sich 60% des amerikanischen Motorradmarktes in Hondas Hand. Noch einmal zur Erinnerung: 6 Jahre vorher exportierte gesamt Japan gerade einmal 4% seiner Produktion ins Ausland.

Das folgende Bild macht dies klar (man beachte auch die neuerliche Explosion in den letzten Jahren!):

Verkauszahlen Honda Super Cub USA

In Worten: Die jährliche Produktion der Honda 50 für die USA stieg in den fünf Jahren von 1958 bis 1963 von null auf 900.000.

Was dazu nötig war formuliert Kawashima wie folgt: „I really think business is a battle that must be fought with a comprehensive array of force. First, you need to have great products. Then, you need an organization that is appropriate for the product, and people who can make the organization work.

In that respect, I was blessed with great products and a wonderful staff. But also, I think the driving force was Honda’s decision to build its own sales network. Our direct involvement with the retailers led to the success of our American sales network and sales campaign.“

Was sich hinter den Aussagen ‚wonderful staff’, „people who can make the organization work“, „decision to build its own sales network“ verbirgt ist: Eine lernende Organisation, die flexible auf den Markt regiert und mutige Entscheidungen trifft, um den Plan zu verlassen um das Ziel auf anderen Wegen zu erreichen.

Dass dieses und die dazu gehörige Kultur in so großen Unternehmen wie Honda möglich ist, mag dem ein oder anderen Mut machen, der in kleineren Unternehmen ohne Mut und Kundennähe erstickt.

Disruption braucht den Freiraum zum Lernen durch Zufälle, muss das Glück des Tüchtigen dadurch erst ermöglichen und dann bei den Optionen erzwingen. Und dafür braucht es die Kultur des Lernens, der Konsequenz, mutiger, radikaler Entscheidungen bei gleichzeitiger Geduld und Mut zur Nachhaltigkeit statt kurzfristiges Denken.

„The motorcycle’s new image was „unlike anything that Americans had imagined before,“ Kawashima recalled. „It was that of a completely new vehicle; a motorcycle that simply didn’t seem like one.“ 

„Let’s put aside the thought of making money with parts for the time being,“ thought Kawashima. „Let’s just make sure we can provide complete afterservice for our customers. Let’s not get a reputation for not having parts in stock or not being able to deliver parts in a timely manner.“

Die Ironie der Geschichte ist, dass der Weg von Honda in die USA auch ein gewisser Rohrschach-Test für das eigene Denken ist. Die Planerfüller bei BCG etwa sahen den Weg in einer Studie ein wenig anders: BCG sah es als erwiesen an, dass Honda mit einem fantastischen Businessplan angetreten ist, die relevante Nische in den USA zu besetzen.

Tatsächlich ist es ein Weg von Irrungen und Wirrungen, Mut, Flexibilität und einer lernenden Organisation gewesen. Honda selbst weiß übrigens, was es da gemach hat und warum, nachzulesen ist das hier! Heute würde man das ganze sicher Knowledge Accounting nennen.

Die ganze Geschichte ist ein bisschen gegenintuitiv, weil Honda ja einen Plan hatte, ein auf die USA angepasstes Produkt anzubieten. Stattdessen musste Honda genau davon das Gegenteil machen, um den Durchbruch zu schaffe: ,Einfach das Standardprodukt vom Heimatmarkt Japan und das zugehörige Marketing ein wenig anpassen. Smart kann davon bis heute nur träumen und bliebt in seiner Nische stecken.

Ich bin zum ersten mal über die Geschichte gestolpert in dem tollen Buch ‚Group Genius’ von Keith Sawyer. Er erzählt die Geschichte um die Vorteile von improvisatorischem Verhalten gegenüber ‚Skriptverhalten’, also Festhalten am Plan deutlich zu machen. (Das Buch werden wir hier bald genauer vorstellen).

Kurz gesagt hat BCG gerade den Kern der Geschichte von Honda nicht verstanden: Hätte Honda an seinem Plan festgehalten, wäre es gescheitert. Gerade das Verlassen des Planes aufgrund neuer Erkenntnisse hat den Erfolg ausgemacht. Merken wir uns das.

Die Geschichte ist blendend dokumentiert, ich habe mich hier für Zahlen und Informationen bedient:

Group Genius, Keith Sawyer

http://en.wikipedia.org/wiki/Honda#Motorcycles

http://en.wikipedia.org/wiki/Honda_Super_Cub

http://world.honda.com/history/challenge/1959establishingamericanhonda/text01/index.html

Später dann war Edeka immer noch überall, aber vor allem war Edeka egal. Die Ware wurde austauschbar, die Läden hässlich und nichtssagend.

Das konnte nicht gut gehen. Und es kam noch schlimmer. Und was kam, war ein Beispiel an Markenzerstörung. Während man auf der einen Seite mit seiner Markt- und Lebensmittelkenntnis warb (Überraschunsei-Mädchen, Metzgerin), dachte irgendjemand, es mache Sinn, eine Billig’eigenmarke’ dagegenzusetzen: ‚Gut und Günstig’ – auch hierzu eindrucksvolle Videos.

Die ‚Gut & Günstig‘ Marke

Eine Marke, die sich diesen Namen gibt, ist ganz sicher nicht gut und günstig, sondern ‚Naja’ und billig. Aber nicht nur das ging daneben, nein, auch das Markenzeichen (s.o.) selbst strahlt alles andere als ‚gut’ aus, sondern eben auch wieder eher billig. Und die Videos: Da wurden jetzt sogar die Billigpackungen inszeniert und am Ende der Kunde noch genasweist.

Da war sicher jemand stolz drauf. Nach günstig kommt halt billigst. Wie gesagt, Edeka wurde egal und ich habe Edeka gar nicht mehr wahrgenommen.

Aber seit ein paar Jahren passieren merkwürdige, aber gute Dinge im Edeka Universum. Ich habe noch nicht geforscht, wer da jetzt am Drücker ist. Irgendjemand hat da vieles begriffen. Seit Jahren werden die Verkäufer wirklich unglaublich freundlich – aber nicht mal künstlich.

Nein, das wirkt vollkommen authentisch. Der Edeka zwei Straßen weiter ist wirklich mein Edeka geworden. Und obwohl der Laden riesig ist, kennen die auch meine Kinder. Und meine Kinder kennen die.

Aber es kommt noch besser. Edeka macht jetzt gute Eigenmarken. Das Logo ist Edeka, in wertig und elegant.

Die neue Edeka Eigenmarke

Die Produkte sind von bester Qualität und dabei – eben günstig. Nicht billig, aber günstig. Value for money. Nur zwei Beispiele: Es gibt seit kurzem phantastische Spaghetti für 99 Cent, die in Ihrer Qualität alle andere Massenware locker einholen oder in die Tasche stecken.

Obwohl Massenproduktion, sind sie hergestellt mit Liebe zum Detail. Der Pastateig wird durch Bronze geformt, wie sonst eigentlich nur bei meinen Lieblingsnudeln aus Lari von der der Manufaktur der Gebrüder Martelli, über die ich hier geschrieben habe.

Dadurch werden die Nudeln merklich rau, sie nehmen mehr Soße auf und werden zu einem natürlichen Geschmacksverstärker. Phantastisch.

Zum anderem gibt es dort jetzt sehr, sehr gute Kartoffelchips in zwei Geschmacksrichtungen (siehe Bild oben): Paprika und gesalzen. Beide Packungen kosten wieder 99 Cent, sind nicht zu groß und nicht zu klein, die Chips sind von guter Konsistenz und der Geschmack irre ausgewogen. Das machen die mal eben so! Probiert und staunt!

Daneben gibt es jetzt gute Direktsäfte unter der Eigenmarke und sogar eine ganze eigene Bio-Eigenmarke‚ teils mit rein vegetarischen Produkten. Es passiert viel.

Die alte und neue Eigenmarke sind ein gutes Beispiel, wie man dieselbe Strategie versemmeln oder veredeln kann. Mit beiden Versuchen wollte man letztlich die Marge erhöhen und Kunden an das eigene Haus binden. Mit ‚Gut und Günstig’ wollte man sich gegen Aldi positionieren.

Auf dem Weg hin zu billig hat man aber vergessen, die Qualität im Auge zu behalten. Die Qualität der Produkte, der Verpackung usw. Etwas, was einem im Kampf gegen Aldi nicht passieren darf. Denn Aldi macht vieles komisch, achtet aber immer auf Qualität. Nur die Umgebung ist billig.

Das weiß man. Man hat hier also nicht nur die Bedürfnisse der eigenen Kunden verprellt, sondern sogar die der Kunden, die man von Aldi gewinnen wollte. Mit der neuen Edeka Marke dagegen geht man wirklich auf den originalen Edeka-Kunden ein. Und wer weiß: Vielleicht merkt das auch bald der Aldi-Kunde.

Denn wir wissen auch: Das ist oft derselbe. Hier wird erfolgreich eine Marke mit den originalen Werten des Hauses wieder neu aufgeladen.

Ich bin mir sicher, dass die Artikel dieser Eigenmarken sowohl ein wirtschaftlicher als auch ein ganz subtiler Imageerfolg werden und Edeka sich damit noch klarer als qualitative, aber leistbare Familienmarke etabliert . Das klappt aber eben nur, weil das gesamte System Edeka drum herum stimmt. Da darf nichts brechen.

Es kommt aber noch mehr: Seit kurzer Zeit kann ich in meinem Edeka hier um die Ecke mit meinem iPhone bezahlen. Bei Edeka. Ist das nicht irre? iPhone Payment bei Pühler!

Habt ihr selbst ähnliche Markenerlebnisse beobachtet?

P.S.: Ach Edeka – beim Obst und Gemüse müsst Ihr noch aufholen!

Nokia Umsatz – Quelle: wolfram alpha

Wir sehen einen stetig fallenden Umsatz. Auch der Schwenk weg von den eigenen Plattformen hin zur Kooperation zu Microsoft als Plattform für neue Smartphones hat keine Trendumkehr gebracht.

Apple überholt im Umsatz Nokia rechts

Hier sehen wir einen der Gründe: Apple überholt rechts. Man beachte, dass die Darstellung der Umsätze logarithmisch ist. In Zahlen hat in den letzten Jahren Apple seinen Umsatz von ca. 25 Milliarden auf ca. 125 Milliarden verfünffacht, Nokia hat zwei Drittel von ca. 60 auf ca. 20 Milliarden verloren.

Nokia wird nicht unter den fünf größten Smartphone-Lieferanten geführt.

Hierzu kann man gar nicht viel sagen: Nokia ist immer noch einer der größten Hersteller von Featurephones (also normalen mobile Phones), findet aber keinen Platz unter den ersten fünf Smartphone Herstellern. Nokia existiert faktisch nur in der Welt billigen Handies mit geringer Marge, also in der Welt billiger Gebrauchsgegenstände.

Nokia stock chart

Der Aktienkurs spiegelt das recht eindrücklich wieder. Und es bleibt auch wirklich niemandem verborgen:

„Der einstige Weltmarktführer Nokia setzt immer stärker auf den Smartphone-Boom. Das kostet erheblich Marktanteile im gesamten Handygeschäft – auch deshalb, weil sogenannte Feature-Phones-Nutzer mit ihren Geräten zufrieden sind und sich deshalb keine Smartphones zulegen wollen.“

Quelle: http://www.n-tv.de/wirtschaft/Nokia-Marktanteil-bricht-ein-article10642006.html

Man muss schon lange suchen, bis man eine positive Nachricht zu Nokia findet. Aber spulen wir mal ein paar Jahre zurück, ziemlich genau in die Zeit vor dem … iPhone. Es kam im Jahr 2007 auf den Markt, also genau vor diesen Charts. Erste Smartphones waren bereits auf dem Markt, überzeugten den Kunden aber nicht. Sogar Nokia selbst hatte wunderbare Smartphones auf dem Markt. Zumindest einige Techies sprachen sie an.

Nokia Communicator – Die damalige Idee eines Smartphones.

Aber noch war der Markt fest in der Hand der heute sogenannten Feature Phones, also Mobile Phones, mit denen  man mehr oder minder eben telefonieren konnte. Dazu gab es seltsame Handyspiele, SMS, Versuche von Social Sharing und andere Gadgets. Der Markt der Feature Phones war damals von Nokia übernommen und revolutioniert worden: Von einer ehemaligen Papiermühle und Hersteller hochwertiger Gummistiefel.

Damals wurde Nokia zu Recht dafür bewundert, sich abermals radikal neu erfunden zu haben. Und mit jeder Neuerfindung hat Nokia nicht nur sich sondern jeweils auch einen Markt disruptiert und damit erobert. Und jetzt? Heute? Was ist passiert? Und: War das vorherzusehen?

Der Wissenstrichter

Dazu betrachten wir erst einmal was Nokia mit dem Einstieg in den Mobilfunksektor gemacht hat:

Zuerst einmal hat Nokia visionär ein Problem (Mystery) entdeckt: mobiles Telefonieren. Sie hatten eine Ahnung (Hunch), dass dieser Markt Zukunft hat. Nokia hat sich Stück für Stück der Erforschung dieses Problems und dessen Lösung angenommen. Erst hatten Sie grobe Mechanismen, Heuristiken, gefunden, um diesen Markt zu verstehen.

Und durch ständige, unaufhörliche, immer schnellere Wiederholung, waren sie irgendwann in der Lage, diesen Markt perfekt zu bedienen. Sie hatten jetzt einfache Regeln (Algorithm) gefunden, um diesen Markt zu dominieren. Damit hat Nokia einen vollkommen typischen Innovationszyklus durchlaufen.

Roger L. Martin nennt dies in seinem Buch „The Design of Business“ [Martin 1] den Wissenstrichter (Knowledge Funnel,). Er beschreibt den Weg durch diesen Trichter in folgenden Schritten:

Der Knowledge Funnel nach Roger L. Martin

1. Stufe: Mystery: Man entdeckt ein Problem (Mystery), man wundert sich.

2. Stufe: Heuristik: Man löst das Problem, Stück für Stück, heuristisch. D.h. man hat die Prinzipien der Lösung noch nicht verstanden. Man sucht noch nach den Mustern, Heuristiken. Um das schnell hinzubekommen, muss man schnell viel Erfahrung sammeln. Das macht man möglichst schnell in vielen Versuchen, die eventuell auch parallel ablaufen.

3. Stufe: Algorithmus: Hier hat man die Muster der Lösung, die Mechanik, verstanden und kann jetzt die Lösung skalieren. Beispiele dafür sind: Eine gute Online-Lösung, eine Franchising Kette (Starbucks hat das Muster des ‚third Place’ automatisiert, McDonalds den familienverträglichen Junkfood-Grill, usw.)

Genauso hat es Nokia gemacht. Es hat ein Problem entdeckt und wie verrückt nach Lösungen auf der Ebene der Heuristiken gesucht. Weil das Problem, dessen sie sich angenommen haben, wirklich ungelöst war und ein wirklich hartes Problem war, hatte das tiefgreifende Folgen: Ein neuer Markt ist entstanden, Nokia hat sich selbst dabei neu erfunden und letztlich komplett umgebaut, um diese neue Situation bedienen zu können. Das sind alles typische Merkmale für disruptive Innovation.

Das Innovators Dilemma

Leider ist das, was danach kam, auch ein Klassiker – wenn auch in der Geschichte von Nokia untypisch. Denn was dann oft passiert, ist dass Firmen in das  I_nnovators Dilemma_ hineinstolpern

„Christensen suggests that successful companies can put too much emphasis on customers‘ current needs, and fail to adopt new technology or business models that will meet customers‘ unstated or future needs; he argues that such companies will eventually fall behind.

Christensen calls this „disruptive innovation“ and gives examples as diverse as the personal computer industry, milkshakes, and steel minimills.“ Quelle: http://en.wikipedia.org/wiki/The_Innovator’s_Dilemma

Das heißt, Unternehmen, die einmal einen wirklich tiefen Wissenstrichter durchlaufen haben, beginnen, sich im unteren Ende des Trichters festzubeißen. Sie optimieren ihr aktuelles Geschäftsmodell auf mehreren Ebenen: Zum einen wird der Algorithmus (das Produkt) durch kleinteilige Feature-Optimierung immer besser.

Zum anderen wird die Operational Excellence in allen Bereichen optimiert. Das ist ehrenwert und eine anstrengende Aufgabe. Leider hat es aber meist auch den Effekt, dass sich das Personal oder zumindest die Kultur ändert. Nun werden exakte Vorhersagen wichtig.

Das erwarten die Investoren und die Öffentlichkeit zu Recht. Dadurch gewinnen ein Denken und eine Kultur Oberhand, bei der die Vorhersage aus der Vergangenheit – also Wiederholbarkeit – im Fokus stehen. Man könnte das ein analytisches Mindset nennen. Dadurch werden die Ziele der operativen Exzellenz vollkommen erfüllt.

Leider verlernt die Firma aber durch kleinteilige Optimierung den Wandel im Großen. Und damit wird die gesamte Firm vorhersehbar und das Geschäftsmodell leicht zu kopieren.

Wenn wir uns den Weg durch den Wissenstrichter aber genau ansehen, wird ein Problem offenbar: Wenn man ein Problem erkennt, kann man noch nichts über dessen Lösbarkeit und Rentabilität vorhersagen. Das hat in einer rein analytischen Kultur weitreichende Konsequenzen.

Diejenigen, die neuen Problemen auf der Spur sind, haben in Meetings den Nachteil, keine oder keine seriösen Aussagen zur Lösbarkeit oder Rentabilität Ihrer Arbeit machen zu können. Ganz anders als all die Verbesserungsinitiaven in Unternehmen: Diese sind (bis auf ein bisschen Politik und zu viel belohnten Optimismus) relativ berechenbar und erhöhen vorhersehbar die Marge des Unternehmens.

In solchen Meetings ist klar, welche Projekte ein Go bekommen und welche nicht. Damit sind aber Projekte benachteiligt, die weitere Male durch den Wissenstrichter hindurchkriechen wollen. Mit anderen Worten: In Unternehmen, die rein finanziell orientiert sind und Effizienz gewinnen wollen, hat Innovation keinen Raum mehr.

Die Firma wird blind für das Umfeld, die drohenden Disruptionen von außen, die schwarzen Schwäne und damit fragil – obwohl sie nach außen finanziell blendend dasteht.

Schwarzer Schwan: Ein von Nassim Taleb geprägter Begriff der verdeutlicht, dass das Eintreffen befürchteter angenehmer oder unangenehmer, Ereignisse mit großen Auswirkungen von Menschen unterschätzt wird. Man nimmt an, es gäbe nur weiße Schwäne. Tatsächlich sollte man den schwarzen Schwan einkalkulieren, da er im Falle des Eintretens von existentieller Bedeutung ist. [Taleb 1]

Fragil – robust – antifragil: Eine Klassifizierung der Eigenschaften von System nach N.N. Taleb. Dabei ist ein System fragil, wenn es durch geringere äußere Einflüsse Schaden nimmt. Dies sind im allgemeinen hochkomplexe Systeme, die durch ein enges Regelwerk gesteuert werden.

(Ein Beispiel für ein fragiles System, das Taleb durch Vorhersage der Bankenkrise bekannt gemacht hat: Das Bankensystem, welches durch zu hohe Konzentration und enge Abhängigkeiten leicht angreifbar wurde.) Ein System ist robust (resilient), wenn es sich nach einem schädlichen Einfluss von außen von alleine erholt und wieder in seine Ausgangsform oder seinen Ausgangszustand zurückkehrt.

Ein Beispiel für ein robustes System ist ein Ökosystem, welches z. Bsp. durch eine Ölkatastrophe geschädigt wird, sich aber selbständig erholt. Anti-Fragil sind Systeme, die sich bei einer Schädigung nicht nur erholen, sondern gestärkt aus der Schädigung hervorgehen.

Ein Beispiel für ein solches System ist z. Bsp. der Körper des Sportlers unter dem Einfluss von Training. Letztlich stellt das Training eine kurzfristige Überanstrengung dar, die vom Körper während einer Erholungsphase überkompensiert wird. Nach mehreren Wiederholungen ist das System Sportler stärker als vorher. [Taleb 2]

Unternehmen sammeln Wissen und Innovation, indem sie oft den Wissenstrichter durchlaufen

Wie kann man diese aussichtslose Situation vermeiden? Der Witz bei der Sache ist, dass man durch den Wissenstrichter eben nicht nur einmal durch muss und dann die Lösung ausmonetarisiert. Man muss durch diesen Trichter immer und immer wieder durch. Denn jedes Mal hat man die Chance, ein neues Problem zu lösen, also einen neuen Markt zu öffnen.

Dazu ist es notwendig, dass die Firma und insbesondere die Geschäftsführung genau diesen Mechanismus verstehen. Sie müssen verstehen, dass es eben zwei wichtige Aspekte in Unternehmen gibt, die dazu notwendig sind, anti-fragil also mehr als stabil  zu werden:

1. Man muss die Effizienz der Firma immer und immer wieder verbessern (z. Bsp.  Kaizen).
2. Dazu muss man scheinbar verschwenderische Innovation zulassen, indem man dieser die Ressourcen und den Raum lässt.

Dabei ist es wichtig, dass man die beiden Aspekte als geschützte Container innerhalb der Firma ansieht, die zwar miteinander kommunizieren und sich austauschen, sich aber gegenseitig keine Begrenzungen setzen. Denn die Innovation verkommt, wenn sie von Anfang an den Begrenzungen der Effizienz ausgesetzt ist.

Anders wird man mit der Effizienz nicht weit kommen, wenn man ihr den Freiraum und das (ja!) zeitweilige Chaos der Innovation aufzwingt. Das alles setzt aber erst einmal voraus, dass man sich diesen Mechanismus bewusst macht.

Innovation ist verschwenderisch, aber es ist billiger, sie zuzulassen

So ist es dann wahrscheinlich auch die wahre Leistung bei Apple gewesen, diesen Zyklus zu erkennen und zum einen die Effizienz der Lieferkette in ungemeine Höhen zu steigern, gleichzeitig aber den Designer ungemeine und verschwenderisch wirkende Freiräume zu gewähren.

Apple konnte es auf diese Weise in den letzten Jahren immer wieder gelingen, schneller als die Konkurrenz tiefe Fahrten durch den Wissenstrichter zu unternehmen und dabei diverse Produktkategorien zu definieren. Man muss dabei aber gar nicht auf ein so exponiertes Beispiel schauen: Steelcase, Procter & Gamble und andere Firmen haben ebenfalls die Kraft des Design neben der Kraft der Effizienz entdeckt oder die Kraft der validen Lösung (die eine echte Lösung) vs. der Wiederholbarkeit (repeatability) wie es Roger L. Martin nennt.

Wir halten fest:

• Die Innovationsfähigkeit eines Unternehmens ist lokal schwer zu beurteilen. So wie Nokia sich sicher wähnte, kann es jedem gehen, der nicht ständig im Großen innoviert. Schwarze Schwäne lauern um die Ecke.
• Um als Firma anti-fragil zu werden, muss man dafür sorgen, dass der Wissenstrichter in der Firma immer wieder durchlaufen wird. So entgeht man dem Innovators Dilemma, mit dem positiven Effekt immer wieder neue Probleme zu lösen und dabei neue Bedürfnisse und Märkte zu bedienen. Bricht ein alter Markt weg, so ist mit hoher Wahrscheinlichkeit ein neuer entstanden.  Macht man das fortlaufend, so sind die einzelnen Märkte selbst nicht so wichtig. Kommt ein schwarzer Schwan von außen und zerstört einen der Märkte, so sind noch genügend Märkte übrig.
• Management von Innovation ist wichtig, dabei muss man sich eingestehen, dass Innovation verschwenderisch ist: Nicht jedes Problem ist ein Problem, dass einen neuen Markt liefert und nicht jedes Problem kann zufriedenstellend gelöst werden und viele Probleme liegen auf der Straße – vielleicht sind andere schneller.

Bei Gelegenheit schreiben wir mehr über das ‚Was’ und ‚Wie’ der Innovation. Wenn Ihr Hinweise, Fragen oder Wünsche für weitere Themen und Aspekte habt, dann schreibt uns doch in den Kommentaren oder im Kontaktformular.

Literatur:

Gerade habe ich noch einen kürzeren Abriss zu dem Thema bei Tom Hulme gefunden: „Watch the Disruptors not the Incumbents„

[Taleb 1] Nassim Nicholas Taleb: Der Schwarze Schwan: Die Macht höchst unwahrscheinlicher Ereignisse. Hanser Wirtschaft, 2008, ISBN 978-3-446-41568-3. (Original: The Black Swan: The Impact of the Highly Improbable (Penguin, 978-0141034591, Februar 2008)

[Taleb 2] Nassim Nicholas Taleb: Antifragilität: Anleitung für eine Welt, die wir nicht verstehen. Knaus-Verlag, 2013, ISBN 978-3813504897.

[Martin 1] Roger L. Martin – The Design of Business: Why Design Thinking is the Next Competitive Advantage

überproduct ist da!

überproduct, das sind Christian und Markus, wobei … nicht ganz. Da wäre noch ein ganzes Netzwerk von Leuten um uns herum, mit denen wir schon in anderen Situationen gerne und gut zusammengearbeitet haben und mit denen wir das auch weiterhin tun werden, von Leuten, die uns lieb und wichtig sind.

Wir haben uns lange Jahre in den unterschiedlichsten Konstellationen und Positionen Produkte ausgedacht und dann auch geliefert. Dabei haben wir festgestellt, dass wir das zum einen nicht mal so schlecht machen und zum anderen über die Zeit gelernt haben wie das immer besser geht.

Vor allem aber macht uns das teuflischen Spaß! Und um noch mehr Spaß damit zu haben, wollen wir jetzt zum einen selbständig neue Produkte entwickeln, zum anderen aber möglichst vielen anderen dabei helfen, das auch und vielleicht besser als bisher zu machen, vor allem aber mehr Spaß dabei zu haben.

In all der Zeit, die wir das schon machen, haben wir gemerkt, dass uns vor allem zwei Dinge  geholfen haben: Gute Leute und Extreme Userzentrierung. Und genau das wollen wir für Euch anbieten.

Bevor wir sagen, wie das genau aussieht, vielleicht noch mehr zur Grundlage: Wer uns ‚kauft’, ‚kauft’ die extreme Userzentrierung gleich mit. In all den Jahren haben wir festgestellt, dass selbst die einfachste, klarste und naheliegendste Idee meist wenig wert ist, wenn sie von ein paar Produktmanagern am Whiteboard, gerne bei einem Offsite, entwickelt wurde.

Auch wenn es die klügsten Produktler der Welt sind. Viele dieser Ideen überstehen keine 10 Minuten in einem kritischen Interview mit Kunden. Wir haben Firmen erlebt, die jahrelang nicht gemerkt haben, dass ihr Geschäftsmodell am Kunden vorbei geht, eben weil sie sich nie – nie! – wirklich tief mit ihren Kunden auseinandergesetzt haben. Und all das waren schlaue Leute. Es ist so einfach, am eigenen Schreibtisch kleben zu bleiben und den Kunden nicht wahrzunehmen.

Wir wollen Euch gerne die einfachen, leichten und machbaren Wege zeigen, wie Ihr kundezentriert Produkte entwickeln könnt.. Das macht Spaß und es spart so viel Geld und Zeit, weil man so viele Dinge eben nicht mehr am Kunden vorbei baut.

Wenn wir neue Produkte konzipieren, wenden wir viele der Techniken von Design Thinking an, das heißt vor allem: Am Anfang gibt es eine tiefe Phase, in der wir das Problem genau verstehen und zwar mit Hilfe des Kunden. Dabei gibt der Kunde nicht das Problem vor, sondern wir beobachten sein Verhalten in der wirklichen Welt und die dahinter stehenden Bedürfnisse.

Auf diesem Verständnis aufbauend gestalten wir das Produkt in harten, öffnenden und schließenden Phasen. Dabei generieren wir ausgehend von dem was wir von den Kunden gelernt haben riesige Lösungsräume, dampfen sie aber gleich wieder ein. Dadurch bekommen wir valide, pragmatische Produkte hin, die aus einer Vielzahl von Optionen herausgesucht wurden.

Wenn die ersten Ideen validiert sind, können all die schönen Tools aus Lean Startup und Lean Entrepreneurship greifen, um das Produkt und ein tragfähiges Geschäftsmodell drumherum zu entwickeln. Auch hier lernen und passen wir noch mit Kundenbeteiligung auf verschiedenen Ebenen in kleinen Schritten an.

Je nach Situation durch A/B-Tests bis zu ausführlichen Interviews im Labor oder direkt beim Besuch vor Ort beim Kunden. Wir haben das Wissen und die Leute um das Euch zu zeigen und zusammen auszuprobieren – gerne auch als ersten Schritt mal ganz klein.

Uns ist sehr wichtig, Euch zu zeigen, dass dies alles einfach zu machen ist! Wenn man es einmal gesehen hat und den Bogen raus hat, dann ist es nicht einmal teuer. Im Gegenteil! Wir behaupten das man über eine Validierung über Prototypen eine Menge Geld spart.

Zum einen kommt man in einen ganz anderen, produzierenden Arbeitsmodus. Und damit kommt man aus sehr vielen Meetings raus, in denen man sich letztlich lange über Meinungen unterhält. Beim Produzieren und Testen von Prototypen trifft man beim Machen ganz automatisch all die kleinen Designentscheidungen über die man sonst redet, sie aber nicht vorantreibt.

Gleichzeitig führt man keine theoretischen Diskussionen, sondern ganz reelle Diskussionen über existierende Prototypen, die man fassen kann. Das alles führt zu einer ungeheuren Beschleunigung im kreativen Prozeß, der Discovery und Exploration – also in dem Teil in dem wir dem Wert für den User auf die Schliche kommen wollen.

Und die Kosten sind gering verglichen mit einer MaFo, die uns lediglich gemittelte, quantitative Aussagen liefert. Die Kosten für Recruting und Interviewing von Kunden sind sehr gering, wenn man es nur richtig anstellt, die Vorteile wie oben beschreiben riesig. Der Katalysator ist der Prototyp.

Diese Prinzipien sind uns sehr wichtig. Und wir wollen gerne mit Kunden arbeiten, denen das auch wichtig ist, die das gerne wollen, aber nicht genau wissen wie – oder die immer besser darin werden wollen. Gleichzeitig ist uns wichtig, dass Ideologie hier keinen Platz hat.

All das sieht in jedem Kontext anders aus und es gibt kein ‚richtig’ und ‚falsch’. Verschiedene Ansätze und Übertragungen aus anderen Bereichen können sich sogar befruchten und nicht etwa schaden. Ein anderes mal wieder muss man ‚hart’ sein.

Am liebsten arbeiten wir mit Euch ‚on the job’, aber wir werden auch bald Trainings anbieten. Wir arbeiten gerade an der Konzeption verschiedener produktorientierter Trainings, vor allem weil wir glauben, dass es davon zu wenige gibt. Wenn Ihr einen besonderen Wunsch oder Anregungen zu offenen Trainings oder solchen bei Euch in der Firma habt, kontaktiert uns bitte! Wir können sicher flexibel das Richtige zusammenstellen.

überproduct ist da, weil wir glauben zu wissen, wie man Innovation in Unternehmen über Produkte unterstützen und managen kann. Genau das wollen wir für Euch leisten. Überproduct soll unser bestes (über)Produkt sein und alles über Produkte liefern: Trainings (offen oder für Euch exklusiv), Innovationsberatung, direkte Produktunterstützung in Projekten, sind auch gerne einfach eure POs, CPOs, validieren Eure Produkte, helfen neue zu entwickeln, helfen beim Liefern oder … bauen mit euch ein Startup auf.

 Wir freuen uns auf Euch!

 Christian und Markus