Veröffentlicht —
Was wir von Bear Grylls über Produktentwicklung lernen können
Ich habe wahrscheinlich mehr Zeit als nötig damit verbracht, darüber nachzudenken, was Bear Grylls und Produktentwicklung gemeinsam haben.
Bleibt kurz bei mir.
Bear ist dafür bekannt, irgendwo an einem ziemlich unangenehmen Ort ausgesetzt zu werden, mit einem Messer, einem Stück Schnur und einer beunruhigenden Bereitschaft, Dinge zu essen, um die die meisten von uns lieber einen grossen Bogen machen würden.
Sein Ansatz lässt sich ungefähr so zusammenfassen:
Improvise. Adapt. Overcome.
Kleiner Disclaimer, bevor die Bear-Grylls-Fans hinter mir her sind: Erfunden hat er diesen Satz nicht. Er hat seine Wurzeln im militärischen Umfeld und wurde unter anderem durch Heartbreak Ridge bekannt. Aber er passt so gut zu Bears Art, mit schwierigen Situationen umzugehen, dass wir ihn trotzdem ausleihen.
Denn hinter all den aus Socken improvisierten Trinkgefässen und selbstgebauten Flössen steckt eine erstaunlich hilfreiche Art, mit Unsicherheit umzugehen.
Plan A überlebt den Kontakt mit der Realität selten
Bear kann sich vorbereiten, bevor er in der Wildnis landet. Er kann das Gelände studieren, den Wetterbericht prüfen und etwas Ausrüstung einpacken.
Dann ist er dort: Der Fluss führt mehr Wasser als erwartet. Der Weg ist blockiert. Es beginnt zu regnen. Etwas, das er geplant hat, funktioniert nicht.
An diesem Punkt hat er zwei Möglichkeiten:
Am ursprünglichen Plan festhalten, weil man sich vor drei Monaten darauf geeinigt hat.
Oder sich mit der Realität beschäftigen.
Wenig überraschend entscheidet er sich meist für die Realität.
Er hat darüber gesprochen, dass Improvisation für ihn zu den spannendsten Teilen des Überlebens gehört: Mit den wenigen Dingen zu arbeiten, die zur Verfügung stehen, und herauszufinden, wie man sie auf kreative Art und Weise einsetzen kann, wenn die Situation es verlangt. Genauso wichtig sind für ihn die Fähigkeit, sich schnell anzupassen, und der Umgang mit Misserfolgen.
Das ist eigentlich auch eine ziemlich gute Beschreibung von Produktentwicklung. In unserem Umfeld lassen wir es nur meistens komplizierter klingen, als es wirklich ist.
Auch Produkte entstehen ein Stück weit in der Wildnis
Natürlich ist die Entwicklung einer neuen Plattform nicht dasselbe wie irgendwo im Dschungel festzusitzen. In der Regel gibt es weniger Schlangen.
Aber eine wichtige Gemeinsamkeit gibt es: Am Anfang weiss man nicht alles.
Man weiss nicht genau, wie Menschen das Produkt tatsächlich nutzen werden. Man weiss nicht, ob die Funktion, die im Workshop alle grossartig fanden, noch Sinn ergibt, sobald jemand sie wirklich benutzen muss. Man weiss nicht, ob die Navigation verstanden wird, ob das Geschäftsmodell funktioniert, ob sich die Integration wie versprochen verhält oder ob das clevere KI-Feature wirklich nützlich ist.
Wir können fundierte Annahmen treffen. Aber es bleiben Annahmen.
Deshalb arbeite ich gerne in kurzen Schleifen:
Frage. Idee. Prototyp. Feedback. Entscheidung.
Zuerst klären wir, was wir eigentlich herausfinden wollen. Dann entwickeln wir eine Idee und setzen gerade genug davon um, damit sie greifbar wird. Wir zeigen den Prototyp echten Menschen, beobachten, was passiert, und entscheiden auf dieser Grundlage, was wir ändern, behalten oder als Nächstes testen wollen.
Und dann beginnt die nächste Runde, mit einer geschärften Annahme und besserem Verständnis des Problems.
Verliebt euch nicht in den Prototyp
Hier wäre Bear vermutlich ein überraschend guter Product Owner.
Wenn er ein Floss baut und es sofort zu sinken beginnt, beruft er wahrscheinlich nicht erst ein Retro-Meeting ein, um zu diskutieren, warum das Floss theoretisch schwimmen müsste.
Er steigt aus dem Wasser und baut ein besseres Floss!
In der Produktentwicklung fällt uns das manchmal schwerer, weil Ideen mit der Zeit emotionales Gewicht bekommen.
Wir haben wochenlang über das Konzept diskutiert. Jemand hat es dem Management präsentiert. Es steht auf der Roadmap. Es gibt einen wunderschönen Figma-Prototyp. Der CEO findet ihn gut.
Und dann verstehen die Nutzerinnen und Nutzer ihn nicht.
Das ist wertvolle Information.
Ein Prototyp ist nicht dazu da, zu beweisen, dass wir recht hatten. Er soll uns möglichst früh zeigen, wo wir falschliegen, solange eine Kursänderung noch vergleichsweise günstig ist.
Anpassen bedeutet nicht aufgeben
Es gibt noch einen anderen Teil von Bears Denkweise, den ich mag.
Den Plan zu ändern, ist kein Scheitern und diese Unterscheidung ist auch bei der Entwicklung von Produkten wichtig.
Man kann hartnäckig an dem Problem festhalten, das man lösen möchte, und gleichzeitig sehr flexibel bei der Lösung bleiben.
Eine Funktion kann verschwinden. Das Interface kann sich komplett verändern. Die Technologie kann wechseln.
Aus der ursprünglichen Idee kann etwas entstehen, das am Anfang niemand vorhergesehen hat. Das ist völlig in Ordnung.
Iteration bedeutet nicht, die erste Idee so lange zu polieren, bis alle zu müde sind, sie noch infrage zu stellen. Es geht darum, die Idee jedes Mal besser zu machen, wenn uns die Realität etwas Neues zeigt.
Improvise. Adapt. Overcome. Repeat.
Vielleicht sollte die Produktentwicklungs-Version so lauten:
Frage. Idee. Prototyp. Feedback. Entscheidung.
Zugegeben, etwas weniger dramatisch, aber die Denkweise dahinter ist dieselbe.
Stellt die richtige Frage. Entwickelt eine Idee. Baut etwas, das ihr testen könnt. Holt echtes Feedback ein. Trefft eine Entscheidung auf Basis dessen, was ihr gelernt habt und startet die nächste Runde.
Zum Glück erfordert Produktentwicklung nur selten, den eigenen Urin zu trinken.
Den eigenen Stolz muss man allerdings gelegentlich herunterschlucken.