Product Pioneers: UnBarcamp mit John Cutler im Juni 2021

Wir hatten diesmal wieder die Chance einen hochkarätigen Speaker für uns zu gewinnen: John Cutler ist vielen bekannt als Autor des Postings „12 Signs You´re Working in a Feature Factory". Als Head of Product Education bei Amplitude, einem führenden Anbieter von Lösungen rund um Product Analytics, setzt er sich intensiv mit dem Thema datengetriebene Produktentwicklung auseinander. John spricht auf Konferenzen wie Mind the Product, schreibt leidenschaftlich auf seinem Blog übers Produktmanagement und erreicht dabei fast 50.000 Menschen über Twitter.

Seinen Vortrag über „Exploding myth about Feature Factories“ haben rund 70 Teilnehmer*innen aus der gesamten OTTO Group gespannt zugehört, und im Anschluss intensiv die Möglichkeit genutzt, von John aus erster Hand in einem F&A-Teil noch weitere spannende Einsichten zu erfahren.

Mit dem ursprünglichen Posting prägte John den Begriff Feature Factory bereits im Jahr 2015: Nachdem er bei mehr und mehr Entwicklungsteams erkannte, dass es häufig nur ums Fertigstellen von Anforderungen bei möglichst hoher Auslieferungsgeschwindigkeit ging, publizierte er damals den Beitrag über Feature Factories – nicht ahnend, welche Reaktionen Dies hervorrufen würde. Denn Menschen wollen die Wirkung ihrer Arbeit sehen und verstehen – das kollidiert leider mit der von ihm skizzierten Fabrikarbeit, in der viele Entwicklungsteams und Produktmanager*innen festhängen.

John sagte selbst, dass er etwas naiv mit seinem ursprünglichen Posting gewesen sei, aber offensichtlich einen Nerv getroffen habe. Und er bedauerte, dass er damals nur das existierende Problem beschrieben habe. Seitdem versuche er, uns allen mögliche Lösungsansätze in die Hand zu geben.

Aus seiner Sicht gibt es drei grundlegende Wahrheit in diesem Kontext, denen man sich bewusst sein sollte:

1. Viele Unternehmen arbeiten in einer Feature Factory und sind damit sehr erfolgreich – ein Beispiel sind Teile von Microsoft. Dies hängt häufig mit der Domäne und/oder der Unternehmenskultur zusammen.

2. Viele Entwicklungsteams scheitern beim Spagat zwischen dem Druck zu Liefern und dem Aufwand, tatsächliche Wirkung der Produktentwicklung transparent zu machen. Häufig fehlen ihnen dabei einfache Möglichkeiten, um Insights darüber zu erzeugen, was Ihre Arbeit eigentlich für Anwender, Kunden und Stakeholder bewirkt.

3. Für ausnahmslos jedes Unternehmen ist es eine echte Herausforderung, aus einer Feature Factory zu entkommen. Selbst mit einer soliden Datenbasis, dem richtigen Mindset und passenden Prozessen sowie Werkzeugen, dauert es zu lernen, wie man richtig lernt.

John differenziert inzwischen seine Betrachtung der Feature Factory durch 12 Dimensionen, da er selten eine reine Schwarz/Weiß-Sicht gesehen hat. Mit diesen Dimensionen können dann die verschiedenen Zwischentöne einer Feature Factory betrachtet und mögliche Auswege identifiziert werden:

· Bedeutung einer Strategie: Ohne Strategie und dazu passendem Narrativ, ist es sehr schwierig, einer Feature Factory zu entkommen. Die Strategie ist das Bindeglied zwischen dem zu entwickelnden Produkt und den Kunden. Wenn deine Strategie „Verdiene Geld“ ist, wird deine Organisation ziemlich sicher eine Feature Factory sein. John wie darauf hin, dass auch das „Allheilmittel“ OKRs ohne eine Strategie, in die sie eingebettet sind, hierbei keine nachhaltige Lösung schafft.

· Bedeutung der Finanzierung: Die nachvollziehbare Frage des Managements “Und was bekommen wir für unserer Geld?” kann in vielen Organisationen nur mit konkreten Feature-Versprechen beantworten werden, weil andere Werkzeuge und das nötige Vertrauen fehlen. Bei einer Budgetplanung auf der Ebene Features oder Roadmaps/Meilensteine wird die Organisation eher zu einer Feature Factory tendieren; und weil die Planung aufwändig ist und ein hohes Sicherheitsbedürfnis besteht, führt dies dann zu den gefürchteten Mehr-Jahres-Plänen. Wird das Budget hingegen für Fähigkeiten, Produkte, Wertströme oder auch Entwicklungsteams geplant, hilft dies beim Weg raus aus einer Feature Factory.

· Einfluss der bestehenden Organisationsstruktur: Kleine Entscheidungen innerhalb der Organisationsstruktur können einen sehr großen Einfluss haben, da ein Alignment zwischen Strategie und Organisation unabdingbar ist. Johns‘ Beispiel war hierbei einzentrales Team von UX-Designerin, das für alle Produktentwicklungsteams einen Flaschenhals bildet, anstatt direkt in die cross-funktionalen Teams integriert zu sein. 

· Investment der begrenzten Zeit: Die Kalender der Produktverantwortlichen spiegeln die Prioritäten des Unternehmens wider. Oft fehlt die Zeit für Reflektion, für eine gemeinsame Retrospektiven oder gemeinsames Lernen. Sich genau diese Zeit zu nehmen, sollte aktiv eingefordert und incentiviert werden. Fördert das Unternehmen dies nicht, dann fördert es damit wiederum ein Kippen in Richtung Feature Factory.

· Bedeutung von Glauben, Sicherheit und Vertrauen: In erfolgreichem Unternehmen hat das Senior Management Vertrauen, dass Dinge tatsächlich funktionieren. Wir erwarten häufig, dass auch das Management in einer Feature Factory dieses Vertrauen aufbringt – ohne jemals ein funktionierendes, kompetentes Produktentwicklungsteam selbst erlebt zu haben. Bei der Frage „Hast du schon mal ein effektives Entwicklerteam erlebt? Was hat dieses Team ausgezeichnet“ hört man häufig Antworten wie „Ja, das Team hält jede Deadline ein! Ja, das Team reagiert extrem schnell auf Bugs!“. Solche Antworten spiegeln, dass die Vision eines „effektiven Entwicklerteams“ häufig leider einen völlig falschen Fokus auf Output setzt, und sich damit Feature Factories quasi selbst verstärken.  

· Portfolio an Wetten: Unternehmen haben meist sehr unterschiedliche Vorhaben, die sie angehen wollen. Um aus einer Feature Factory zu entkommen, sollte man diese sehr differenziert betrachten, und je nach Eigenart der Wette bzw. des Vorhabens passende Produktentwicklungs-Prozesse etablieren – es gibt nicht den Mono-Prozess, der auf alles passt. Wenn ihr etwas verbessern wollt, konzentriert euch dabei bewusst auf wenige Vorhaben/Wetten.

· Messen, um zu Lernen vs. Messen, um besser zu werden: Auch in einer Feature Factory kann häufig und viel gemessen werden, meistens geht es aber nur um Leistung. Wir müssen uns bewusst machen, wann wir eine Leistung messen wollen, und wann wir etwas messen, um ein Lernen zu ermöglichen. Wenn wir das klar unterscheiden und für das Management transparent machen, dann hilft dies, um Vertrauen aufzubauen. 

· Datenkompetenz: Um eine Datenkompetenz aufzubauen, die uns aus einer Feature Factory raushilft, müssen wir nicht nur Daten sammeln und auswerten, sondern uns vor allem über die Intention klar sein. Nur so können wir erkennen, wann wir das Falsche messen. Wichtig ist, Datenkompetenz nicht nur bei einer Rolle zu verankern, sondern über die gesamte Organisation zu skalieren. Dazu benötigen wir auch die richtigen Werkzeuge, um überhaupt neugierig darauf zu werden, was wir noch nicht wissen.

Am Ende gab uns John noch die wichtige Botschaft mit: "Produktmanagement ist hart! Immer! Ein kontinuierliches „Umlernen“ ist erforderlich“. 

Habt ihr auch Interesse daran, Euer Bild über Produktmanagement und Produktentwicklung zu vertiefen und noch andere engagierte Produkt-Menschen kennen zu lernen? Dann schaut Euch die kommenden Product Pioneer Events an – wir freuen uns auf Euch! 

Hier geht es zu den Anmeldungen Fuckup-Nachmittag und UnBarcamp

Euer Product-Pioneers Team

#productpioneers