Experimente in der Produktentwicklung – Nils Stotz zu Gast (Experimentation @ Zalando, ex Contentful)
Kultur, Reifegrade von Organisationen und der Einfluss von AI
In der neunten Episode des PRODUKTKRAFT Podcasts dreht sich alles um die Rolle von Experimenten in der digitalen Produktentwicklung – und dafür ist Nils Stotz der perfekte Gesprächspartner.
Nils vereint in seiner Laufbahn akademische Tiefe und operative Breite: Er hat zum Thema experimentelle Produktentwicklung nicht nur wissenschaftlich publiziert, sondern auch ein Buch dazu geschrieben. Gleichzeitig bringt er praktische Erfahrung aus Start-ups wie Getsafe und Likeminded, aus Scale-ups wie Contentful und aus seiner aktuellen Rolle bei Zalando mit, wo er das Thema Experimentation maßgeblich vorantreibt.
Wir sprechen darüber, warum Experimente so wichtig für moderne Produktentwicklung sind, welche Reife es dafür in Organisationen braucht – und wo sie nicht der richtige Weg sind. Nils teilt konkrete Einblicke, wie sich eine Kultur des Experimentierens aufbauen und langfristig erhalten lässt, welche Hürden dabei auftreten – und welche Rolle Führung dabei spielt.
Ein besonderes Highlight: Wie verändert AI die Art und Weise, wie wir Hypothesen testen, Entscheidungen treffen und Produkte lernen lassen? Wir beleuchten, was heute schon möglich ist – und was morgen Realität sein könnte.
Eine Folge für alle, die wissen wollen, wie sich fundierte Methoden, Mut zur Unsicherheit und organisatorische Realität sinnvoll verbinden lassen. Reinhören lohnt sich!
Product Support Needed?
Du brauchst freiberufliche Hilfe im Produktmanagement? Egal ob Coaching, operativer Support, interimistische Product Leadership oder Consulting: Melde Dich gerne unverbindlich unter jan@produktkraft.com bei mir und wir besprechen, wie eine Zusammenarbeit aussehen könnte.
Credits
Host & Producer: Jan Hoppe - https://www.linkedin.com/in/jan-hoppe-30b38ba3/ - http://www.produktkraft.com
Gast: Nils Stotz - https://www.linkedin.com/in/nilsstotz/
Audio Engineering: Tim Nippert - https://www.linkedin.com/in/tim-nprt-69a377286/ - https://www.timnippert.com
Links
Transkript (Auto Generated)
Jan: Hallo und herzlich Willkommen zum Produktkraft Podcast. Hier spreche ich, Jan Hoppe, einmal im Monat mit interessanten Stimmen aus der deutschsprachigen Welt des digitalen Produktmanagements. Wenn du das magst, folge mir gerne und gebe dem Projekt eine gute Bewertung. Mein heutiger Gast ist Nils Stotz. Nils vereint in seiner Laufbahn auf besondere Weise Aspekte von akademischer Sorgfalt, Startup-Grid, Scale-Up-Pragmatismus und Corporate-Weitsicht. Gemeinsam sprechen wir über das Experimentieren in der digitalen Produktentwicklung. Und er könnte als Gesprächspartner nicht besser passen. So hat er einerseits wissenschaftliche Publikationen und ein Buch mit dem Titel Experimentelle Produktentwicklungen veröffentlicht, hat aber parallel dazu operative Productwork in Startups wie Likeminded oder Getsafe ebenso unter seinem Gürtel, wie manifeste Leadership-Erfahrungen bei Scale-Ups bzw. Scaled-Ups wie Contentful und Zalando, wo er aktuell arbeitet. Viel Erfahrung also, die eine wunderbare Grundlage dafür bietet, darüber zu sprechen, welche Rolle das Experimentieren in unserer Arbeit spielt. Los geht's! Moin Nils, schön, dass du da bist.
Nils: Ja, vielen Dank für die Einladung. Freut mich sehr.
Jan: Klar, gerne. Bevor wir in unser Hauptthema des Experimentieren heute einsteigen, folgen wir natürlich der Tradition, die wir hier haben, dass wir uns immer erst mal anhören, wer unser Gast eigentlich ist und einmal nachzeichnen, wie deine Product Journey überhaupt verlaufen ist. Aber fangen wir doch mal am Anfang deiner eigentlichen Produktkarriere an. Du hast hier ursprünglich mal Finance studiert, bis jetzt aber einer der Hauptstimmen fürs Experimentieren im Produktmanagement. Also wie bist du aus der Finance-Schiene überhaupt mal im Produkt gelandet?
Nils: Ja, es ist eine interessante Journey auf jeden Fall. Ich habe da auch ganz am Anfang, als ich das noch studiert habe und als ich da die ersten Praktika und so weiter gemacht habe, war ich da auch ziemlich tief drin. Also ich habe viele mit Investmentbanking und Consulting und sowas gemacht und da schöne Slides gebaut und so. Das war schon auch alles sehr zahlenlastig natürlich. Aber das ist natürlich, ich will nie immer so, ich sage mal Leute im Investmentbanking und so weiter bashen, aber das ist natürlich am Anfang sehr so mühselig. Du siehst halt nicht so wirklich deine Contribution und so weiter zu dem eigentlichen Unternehmen. Und gleichzeitig habe ich mich natürlich gefragt oder habe ich gesehen, dass Tech-Unternehmen halt super interessant sind, dass die schnell wachsen, dass man da viel lernen kann. Aber da fragt man sich halt immer so ein bisschen, okay, was kann man da eigentlich machen, wenn man halt irgendwie nicht, weiß ich nicht, halt in irgendeinem Domain unterwegs war, die halt da genau reinspielt. Ja, also viele landen dann zum Beispiel in Sales oder so, sowas sehr generisches. Und damals gab es bei einer Company, die hieß Getsafe oder heißt immer noch Getsafe, sehr erfolgreiche Company, sehr viele Versicherungen verkauft in Deutschland, immer noch sehr aktiv, kommt aus Heidelberg. Die hatten eine Stelle, die hieß Entrepreneur in Residence. Das war natürlich sehr, sehr generisch. Und ich glaube, da ging es letztendlich auch darum, dass die halt letztendlich jemanden heiraten wollten, der halt auch Generalist ist und wo eigentlich noch gar nicht so klar ist, auf welche Themen der überhaupt draufgeht. Und da hat sich zum Beispiel dann ziemlich schnell rausgestellt, dass das halt eine Produktrolle ist. Oder so, wie ich das interpretiert habe, ist das eine Produktrolle. Weil damals hatten wir ein großes Problem, die sogenannte Activation Rate, also wie viele Leute letztendlich die Getsafe-Mobile-App benutzen, zu erhöhen. Und die Art und Weise, wie ich das halt angegangen bin, war, ich sag mal, sehr Product Growth orientiert. Und ich sag mal so, mehr oder weniger diesen Stil, den ich damals halt so aus der Note geboren angewendet hab, hab ich mir glaub ich so ein bisschen behalten. Und so hat sich das dann alles entwickelt.
Jan: Okay, das heißt, du bist, klassischerweise würde ich fast sagen, weil es geht bestimmt zwei von drei Leuten so ins Produktmanagement eingestiegen mit einem Job, der eigentlich gar nicht Produkt hieß.
Nils: Genau. Ich glaube, es ist ja auch was Interessantes, weil mich fragen das ja auch tatsächlich viele, wie schaffst du den Einstieg, weil die da halt interessiert dran sind. Das ist gar nicht so einfach zu beantworten, weil bei allen Companies steht halt irgendwie, naja, du brauchst halt fünf Jahre Erfahrung als Produktmanager für eine Produktmanagerrolle. Ist halt schwierig dann. Und da gibt es halt viele Adjacent-Jobs, gibt wenige Junior-Productmanager-Programme in Deutschland. Also es ist tatsächlich nicht so einfach.
Jan: Ja, und du hast dann den Einstieg bei Getsafe zum Glück gemacht. Bei der Rolle ist es aber nicht geblieben. Was ist dann passiert?
Nils: Ja genau, Getsafe war natürlich ein mega guter Einstieg. Da habe ich wahnsinnig viel gelernt. Also in allen Domains auch schon damals. Also das muss man sich ja vorstellen, wie früh das eigentlich war. Und das war jetzt 2018 oder so. Und da haben wir schon Experimente gefahren, hatten super guten Data Setup und so weiter. Und da, das war so das, aber da war natürlich schon ein bisschen was dabei Getsafe. Also als ich dazugekommen bin, da gab es schon Kunden, da gab es schon ein Team und so. Was ich dann eben interessant fand, war das Ganze so mal komplett vom Scratch zu sehen. Also wenn eigentlich noch gar nichts da ist, ne. Und da gab es halt damals das Angebot bei damals hieß es ja noch Likeminded. Heute sind sie gemercht mit Nilo Health, also Mental Health. Das hat damals für mich sehr viel Sinn gemacht, weil die sozusagen Gruppentherapie online angeboten haben. Die haben da halt jemanden gesucht, der sozusagen die Produktorganisation aufbaut. Und das fand ich damals super spannend. Da kannte ich auch Leute, die dort auch schon involviert waren und die Investoren und so. Deswegen bin ich dann dahin. Und das war auch eine super coole Zeit. Haben wir bis zu Series A. Bin ich dann dort geblieben. Und bin dann nochmal zu einer anderen Company gegangen, die sozusagen auch from scratch gestartet ist, die vom Y Combinator finanziert wurde, Lantern, so ein Data Startup. Genau, das waren so die, ich sag mal, ich sag immer so, Getsafe war so one to one, one to one hundred. Und die anderen waren eher so zero to one, beziehungsweise zero to zero. Weil Lantern hat nicht so ganz funktioniert mit dem Product Market Fit. Aber das ist auch eine wichtige Erfahrung. Weil das war letztendlich auch mein erstes B2B Produkt. Und ich glaube, das ist schon nochmal was anderes für einen Produktmanager, wenn man im B2B Space arbeitet. Und das hat letztendlich auch dazu geführt, dass ich diese Erfahrung dann hatte. Und das hat letztendlich dann auch dazu geführt, dass ich halt von Content-Folger her erhört wurde, als ich halt angefangen habe, ein Growth-Team aufzubauen.
Jan: Ja, und man muss auch mal sagen, also ich meine, ich kenne die Start-up-Welt ja auch zu Genüge, dass da mal ein Venture scheitert. Das ist halt Teil des Spiels. Das ist ja kein Problem, sondern eigentlich, wann immer du ein Risiko eingehst, wirklich was Neues zu erfinden, gehört es einfach zu der Natur der Sache, dass das auch mal passiert.
Nils: Absolut, ja absolut.
Jan: Cool, und von daraus ging es dann zu Contentful. Das war wieder eine deutlich größere Organisation.
Nils: Genau, dann wollte ich mal ein bisschen was Größeres sehen und vor allem auch so im B2B-Space. Und Contentful ist ja eines der größten. Ich meine, das ist ja so, es gab mal so ein Artikel, das heißt, der hieß das stille Einhorn, das Silent Unicorn. Ich finde, das trifft es ganz gut bei Contentful, weil es ist ein sehr, sehr gutes Unternehmen, meiner Ansicht nach. Damals auch sehr diesen Product-led-Ansatz gefahren, als wir damals gejoint sind. Und ja, halt einfach ein super Unternehmen. Kann ich nichts Negatives zu Contentful sagen. Und das hat auf jeden Fall auch sehr viel Spaß gemacht, weil da ging es halt einerseits darum, sozusagen das Team zu hiren. Gleichzeitig dadurch, dass wir sozusagen ein neues Team waren, also das Growth Team, das halt so ein bisschen über allen verschiedenen Feature-Produktorganisationen geschwebt ist, uns da so ein bisschen zu etablieren. Gleichzeitig so dieses Experimentation-based Product-Management eben reinzubringen. Also das war schon eine ultraspannende Zeit. Und da habe ich auch ultra viel gelernt, wie halt so große Organisationen funktionieren, wie man sich da behauptet und so. Und genau, ja.
Jan: Cool. Und jetzt zuletzt bist du seit Anfang des Jahres bei Zalando. Und auch da wieder am Experimentieren.
Nils: Genau.
Jan: Im Experimentation-Space unterwegs. Erzähl mal, was du jetzt machst.
Nils: Genau. Und da bin ich dann sozusagen auf die andere Seite gewechselt. Also bei Contentful und bei allen anderen Companies war ich eigentlich so im Customer-Facing-Product-Growth-Management, würde ich sagen. Und jetzt bin ich halt eher so auf der Experimentation-Plattform-Ebene. Das heißt, ich leite das Experimentation-Plattform-Team auf der Product-Seite. Und das heißt, wir stellen quasi sicher, dass Zalando, alle Teams bei Zalando die Möglichkeit haben, möglichst viele Experimente zu fahren. Dafür stellen wir die Infrastruktur zur Verfügung. Genau. Und das ist eben ein schöner Mix aus, ich sage immer so, teilweise Product-Management, aber teilweise auch so ein bisschen Program-Management. Du musst halt auch ein gutes Verständnis haben. Ich sage mal, wie die verschiedenen Teams funktionieren, wie die die Plattform nutzen und dir dadurch halt auch so ein bisschen verstehen, was so die Features sind, die du zum Beispiel selbst bauen musst, die du auslagerst und so weiter.
Jan: Damit hast du dann tatsächlich auch einen ziemlich einzigartigen, zumindest im deutschsprachigen Raum, 360-Grad-Blick darauf, wie Experimentieren im digitalen Produktmanagement funktioniert. Weil ich glaube, es gibt nicht viele Profile, die wir hier haben, die wirklich von ganz Early Stage, Pre-Seed, Start-ups bis hin zu Organisationen von der Größe von Zalando sich mit einem Thema so befasst haben und da so viel Erfahrung gesammelt haben. Und insofern freue ich mich total, dass wir heute mal richtig ans Eingemachte gehen werden. Was Experimentieren im digitalen Produktmanagement eigentlich bedeutet. Wollen wir reinspringen ins Thema?
Nils: Ja, auf jeden Fall sehr gerne.
Jan: Cool. Also, vielleicht fangen wir direkt mal mit einer Grundfrage an. Für dich ist Experimentieren ein Mindset und nicht einfach eine Frage, eine Phase in der Discovery oder ähnliches. Erzähl mal, was meinst du damit, dass Experimentieren ein Mindset sein muss?
Nils: Ja. Also, was ich damit eben meine oder was ich dadurch eben betonen will, ist, dass wir wissen halt, dass Experimentation oder näher, ich sag mal, AAB-Testing einfach die Methode ist, die du uns am sichersten, sag ich mal, an die, das hört sich so hoftramend an, aber an die Wahrheit bringt, ja. Also, das ist ja wissenschaftlich gesehen sozusagen auch der beste Test, um zu erfahren, okay, wie reagiert ein Nutzer auf eine bestimmte Veränderung in einem Produkt, ja. Und deswegen sollte man das halt auch besonders betonen, dass man sagt, naja, immer wenn das eigentlich möglich ist, dann sollte ich versuchen zu verstehen, nicht nur ist die Version A besser als die Version B, sondern wenn ich etwas verändere in meinem Produkt, was ist denn eigentlich der Impact? Wie wiegt sich das aus? Wie viel besser mache ich das Produkt dadurch? Wie viel besser mache ich meine bestimmte Metrik? Und wie viel besser mache ich vielleicht sogar die gesamte Organisation dadurch? Und ich glaube, das ist halt eine ganz andere Art und Weise zu arbeiten, weil die halt auch zu einem gewissen Grad frei von, ich sag mal, Hierarchien oder Meinungen und sowas ist. Und das ist halt einfach eine neue Art und Weise zu arbeiten. Man arbeitet wissenschaftlich, rational, metrikbasierend und ist halt so ein bisschen, ich sag mal, so egobefreiter. Und ja, das macht, glaube ich, also würde ich vermuten, macht das auch mehr Spaß.
Jan: Ja, das heißt also, es ist ein gutes Mittel, opinionfights zu vermeiden und auch, ja, würde ich sagen, dysfunktionale Muster aufzubrechen, in denen einfach die Person, die am weitesten oben in der Hierarchie sitzt, Quarposition am Ende gewinnt.
Nils: Ja, genau, also ich versuche immer so ein bisschen in unserer Community auch zu betonen, dass wir eigentlich nicht so sehr immer sagen sollen, ja, Leadership hat keine Ahnung oder hey, jetzt haben sie wieder irgendwas falsch entschieden. Das ist schon nicht so einfach, ne? Aber dass man sozusagen den Menschen oder den Leuten, die halt jung in eine Company gehen und Motivation haben, Dinge zu verändern, sozusagen eine Möglichkeit gibt, ihrem Punkt glasklar zu proven, ja? Das ist glaube ich schon was, was ich unbedingt fördern will, weil ich sehe es halt, ich habe es halt andersherum ganz oft gesehen, ne? Also viele Leute, vielen Leuten macht es extrem zu schaffen, ja? Also wenn du halt sagst, ja, der hat jetzt Recht, aber ja, so bot, also es gibt halt einfach eine andere Entschärbung, dann kann es auch nicht proven. Das will ich so ein bisschen verhindern und das meine ich mit Experimentation Mindset, ja.
Jan: Ja, das finde ich einen ganz spannenden Gedanken, weil das, was du gerade schilderst, so ein Mindset von ach, die Leadership-Leute, die wissen ja gar nicht genau, was wir hier alles den ganzen Tag ausbaden. Jetzt kommen die hier in das Meeting rein mit irgendeiner Meinung. Da meintest du gerade, es kann Mittel sein, die zu proven, dass man einen Punkt hat. Es kann aber auch ein Mittel sein, ein bisschen mehr Demo zu lernen und auch zu merken, vielleicht war mein Punkt doch gar nicht so wichtig. Das habe ich auch oft beobachtet.
Nils: Absolut, also ich habe ja auch mit vielen Leuten schon über, also man denkt ja manchmal dann so, dass man als CPO kann man sozusagen alles bestimmen. Also ich sage jetzt halt, dass eine Sache gemacht wird und dann wird die gemacht. Aber so einfach ist es halt immer noch nicht, weil du hast immer noch einen Board und du hast immer noch einen CEO und du hast immer noch alle möglichen Leute, die halt Meinungen zu bestimmten Themen haben. Und oft musst du als Produktmensch auch so ein bisschen begreifen, was deine Rolle oder was im CPO-Kontext so deine Rolle ist. Weil ganz oft ist es halt so, dass der CEO vielleicht auch ein viel holistischeres Bild sogar noch hast als du, weil der eben mit Investoren redet, weil der den Markt besser versteht, weil er schon 20 Jahre im Game ist oder so. Und dann ist deine Rolle eben nicht, dass du mit dem alles auskämpfst und den immer überzeugst, sondern dass du halt ihm die Tradeoffs nennst und sagst, klar, also, let's disagree and commit. Aber das bedeutet übrigens, dass wir das und das und das und das nicht machen können. Und das ist dann deine Rolle in dem Fall.
Jan: Ja, total richtig. Und wenn wir von Experimentieren sprechen, du hast vorhin gesagt, naja, da kann man so einen AB-Test machen. Ist Experimentieren immer gleichbedeutend mit, ich mach einen AB-Test, oder was bedeutet Experimentieren eigentlich, wenn du von Experimenten sprichst?
Nils: Ja, ich glaube, da kann man natürlich sehr, sehr lange drüber reden, aber ich fasste es eigentlich sehr, sehr weit. Ja, also Experimentieren ist für mich im Idealfall ein AB-Test. Das ist so, dass das Standard vorgeht. Aber wenn man jetzt beispielsweise so was nimmt wie, naja, ich habe jetzt halt wenig Traffic, aber ich möchte trotzdem halt auf irgendeine Weise versuchen, festzustellen, ob es hier ein Risiko gibt, oder ob man hier irgendwas validieren muss und mache jetzt eben, weiß ich nicht, ein Concierge-MVP, Visit-of-Oz-MVP oder all diese Geschichten, das wäre für mich schon auch Experimentieren. Es gibt zum Beispiel auch Auffassungen, die sehen sogar, ich sag mal, User-Interviews oder einfach nur so User-Testing schon als Experimentieren. Soweit kann man auch gehen, das fasst vielleicht so ein bisschen weit, aber der Grundgedanke ist halt eben, dass man Entscheidungen trifft auf der Basis von, ja, von sozusagen Daten, die du auf eine bestimmte Weise erfasst hast.
Jan: Und wie relevant ist so der Aspekt, vorher eine klare Hypothese formuliert zu haben? Also bist du da, na ja, man kann ja auch Daten erfassen und daraus formt sich im Nachhinein die Hypothese? Oder bist du jemand, der sagt, nee, lieber immer erst mal klar ziehen, was will ich hier prüfen?
Nils: Ja, es kommt natürlich immer auf den genauen Aspekt an. Im Idealfall hast du immer eine Hypothese, vor allem bei klassischen AB-Tests, weil ich habe halt noch keinen richtig guten AB-Test gesehen, wo du keine, also ich spreche jetzt mal einen Fachbegriff, heterogeneous treatment effects. Das bedeutet halt, dass Segmente oder bestimmte Nutzergruppen anders auf ein bestimmtes Treatment reagieren. Das heißt, ich ändere den Button-Color irgendwie von rot auf grün. Und jetzt schaue ich, wie meine User darauf reagieren. Und jetzt reagiert eben die ältere Bevölkerungsschicht besser als die jüngere Bevölkerungsschicht. Drückt sich in irgendeiner Conversion aus. Und wenn du dann eben keine Hypothese formuliert hast, dann könntest du ja beispielsweise auch sagen, naja, das wollte ich ja eh testen. Ich wollte ja eh nur testen, ob das die Älteren mögen. Und dann gehst du halt darauf und sagst, naja, das passt ja so, ne. Und da hast du dir, dann steckst du dir sozusagen später das Ziel, bevor du sozusagen schießt. Und das ist halt genau das, was du vermeiden solltest, ne. Das ist halt ein klassischer, ich sag mal, Denkfehler oder statistischer Fehler. Und genau das verhinderst du halt dadurch, dass du am Anfang schon eine Hypothese festlegst und das sozusagen preregistert, was du eigentlich machen willst, ne.
Jan: Okay. Und das Thema ist ja jetzt total nah dran an sämtlichen Product Discovery Prozessen. Ist Product Discovery in deinen Augen überhaupt denkbar ohne Experimente?
Nils: Also ich glaube, es spielt ja in allen gängigen Varianten, Lehrbüchern und Konzepten eigentlich eine Rolle, ne. Ich glaube, am Ende oder ich sag mal vor dem ultimativen Rollout solltest du in irgendeiner Weise das halt mal getestet haben, ne. Das Banalste, was es da eben gibt, ist sowas wie Canary Tests, wo du halt sagst, naja, ich roll was halt einfach nur so graduell aus und schau halt, ob es keinen Schaden macht. Das wäre für mich auch ein Experiment. Und letztendlich ist das ja der Zwischenschritt von, ich sag mal, purer Discovery Planning zu dem actual Rollout von einem Feature. Also wäre für mich Teil des Discovery Prozesses, ja, nicht rauszudenken.
Jan: Okay. Genau, es ist Teil davon, aber es ist ein ganzes Mindset. Dann lass uns nochmal auf das Mindset-Thema eingehen. Wie agiere ich denn als Produktperson, wenn ich ein Experimenting Mindset mitbringe?
Nils: Ja, also ich glaube, du stellst dir oft die Frage, warum etwas so ist, wie es ist. Ja, stellst es so ein bisschen in Frage. Und versuchst so ein bisschen auch zu verstehen, woher bestimmte Assumptions oder Hypothesen kommen. Ja, also ich glaube, du agierst ja als Produktmanager immer mit ganz vielen Leuten, die zu dir kommen und dir halt irgendwas vorschlagen oder sagen, lass uns das doch mal ändern oder lass uns das doch mal einbauen und so. Und ich glaube, was die Aufgabe von jemanden mit so einem Experimentation-Mindset ist, ist zu sagen, okay, hinter jeder dieser, ich sag mal, Aussagen steckt letztendlich eine gewisse Assumption. Ja, also die nehmen was an, dass der User auf eine bestimmte Art und Weise reagiert, dass er in einer bestimmten Situation ist, dass wir irgendwas in einer bestimmten Geschwindigkeit machen können. Das sind alles Assumptions. Und Hypothesen nehmen sozusagen diese Assumptions und drehen die nach außen. Ja, also eine Assumption ist sozusagen, also nicht nach außen gekehrte Hypothese, so will ich das formulieren. Und wenn du dann halt diese verschiedenen Hypothesen mal hast, also wenn das ganz klar ist, dann kannst du halt ganz viele Produkte auch viel besser validieren und viel besser vortesten. Also wenn ich jetzt sage, wir bauen irgendwie das ganz große Feature, das irgendwie mich sechs Monate beschäftigen würde und anstatt das sozusagen zuvor zu bauen oder mir einen ganz komplizierten Test zu überlegen, sage ich einfach, naja, was steckt denn da genau dahinter? Also warum sollten wir das denn genau bauen? Und wenn du dann halt irgendwie so zehn Hypothesen hast und die dann eben testen kannst, dann kannst du eben verhindern, dass du dich in eine Richtung bewegst, die du halt eigentlich hättest, ja, im Vorhinein testen können, ob die überhaupt sinnvoll ist für deine User und für dein Produkt, ja.
Jan: Ah, okay. Um es zusammenzufassen heißt das, wenn ich als Produktmanager ein Experimentation-Mindset habe, dann nehme ich die Aussagen, die Annahmen meiner Peers und meiner Kollegen und Kolleginnen, die auf mich zukommen, und ich arbeite heraus, welche impliziten Hypothesen da drin sind, indem ich sie explizit mache, testbar mache und damit auch operationalisiere auf eine gewisse Art und Weise.
Nils: Genau, das hast du sehr schön zusammengefasst. Impliziert und explizit waren die Wörter, nach denen ich gesucht habe.
Jan: Ja, wir reden ja auch nicht so oft auf Deutsch über diese Themen.
Nils: Ja, genau.
Jan: Und das heißt, das ist vielleicht eine ganz gute Brücke zu dem nächsten Themenstrang, den ich gerne aufgreifen würde, weil ich glaube, wir haben uns ganz gut verstanden und herausgearbeitet. Was ist überhaupt dein Experiment? Und dann finde ich die Frage aber sehr spannend, gerade im Alltag als Produktperson. Wir haben das gerade so als Beispiel reingeworfen. Da kommt jemand vielleicht aus der Marketing-Abteilung, hat irgendeine Idee, wie könnten wir das Produkt jetzt verändern? Vielleicht ist es auch jemand aus dem Engineering-Team oder, oder eine Kundin kommt mit einer Idee auf mich zu. Wenn ich jetzt jeden Vorschlag, der an mich herangetragen wird, jedes Mal verteste, dann habe ich ja innerhalb von Tagen ein Experimentier-Backlog, das ich in Jahren nicht abarbeiten kann. Also woran mache ich denn fest, wann sich ein Experiment letztendlich wirklich lohnt?
Nils: Genau, also das kommt letztendlich auf das Gleiche wieder zurück. Ich meine, du musst die Assumption oder die Annahmen, die du halt implizit in diesen verschiedenen Wünschen oder Beobachtungen siehst, musst du halt explizit machen in Form von Hypothesen. Und dann hast du ja den nächsten Effekt, dann kannst du die auf einmal so ein bisschen auch quantifizieren. Also ich glaube, es gibt Hypothesen, die stecken in vielen verschiedenen Wünschen oder Beobachtungen und so weiter drin. Und das heißt, wenn du dann zum Beispiel siehst, naja, das ist eine ganz schön kritische Annahme, also die muss eigentlich für das meiste stimmen, dann wird es auch Zeit, die ich sag mal auf verschiedene Art und Weisen auch zu testen und zu validieren, weil wenn die dann falsch ist und sag ich mal 80% aller Feature-Quests und so weiter darauf basierend, dann ist es natürlich schon ziemlich klar eine Aufgabe des Produktmanagements zu überprüfen, ob das überhaupt wahr ist. Und genau, und so kannst du das dann halt auch sehr schön priorisieren.
Jan: Okay, das heißt, häufige, immer wiederkehrende Hypothesen sind besonders kritisch und müssen besonders in den Blick genommen werden.
Nils: Ja, also die halt in vielen verschiedenen Aussagen und Insights stecken, genau.
Jan: Ich habe da in der Vergangenheit natürlich nicht ganz so strukturiert, wie du darüber nachgedacht. Deswegen interessiert mich, wie ist so dein Take? Ich habe manchmal das Gefühl, es gibt auch so Hypothesen, auf die wieder andere Hypothesen aufbauen. Ist das ein richtiges, mentales Modell, oder würdest du aus so einer, ja, fast akademischen Sicht darauf sagen, nee, das ist eigentlich deine wiederkehrende Hypothese?
Nils: Nö, man kann das auf jeden Fall krass akademisieren und man kann das krass verkopft machen. Das sehe ich schon auch. Aber ich glaube halt, was aus meiner Sicht eher so das, oder was ich so in der Praxis eher so feststelle, ist, dass nicht so dieses, welche Hypothese beruht auf welcher Hypothese, sondern eher so, welche Hypothese kann ich zum Beispiel, oder welche mehrere Hypothesen kann ich beispielsweise hängen mit bestimmten Experimenten zusammen. Also wie du das miteinander verbindest, ne? Wie die aufeinander aufbauen, ich meine, das siehst du. Also meiner Ansicht nach erkennt man das halt schon immer irgendwie, dass manche Hypothesen grundständiger sind als andere. Also wenn ich jetzt irgendwie sage, okay, Menschen mögen es, wenn es draußen warm ist, oder irgendwie junge Menschen mögen es, wenn es draußen warm ist oder so, ist das natürlich eine andere Hypothese, als wenn ich das viel expliziter mache und sage, das ist jetzt eine ganz bestimmte Usergruppe, die das schätzt. Und ich sehe eher so dieses Mapping zu den Experimenten selbst als die Schwierigkeit.
Jan: Um es mal greifbar zu machen, und ich persönlich verliere mich ja auch gerne mal im Abstrakten, deswegen mal greifbar gemacht. Hast du eine Erinnerung oder ein Beispiel für ein Thema, wo du dachtest, das war ein Stark vielen, mehrere Ideen zusammen, denen alle die gleiche Hypothese zugrunde lag?
Nils: Es gibt ein Modell, das hilft vielleicht ganz gut in diesem Kontext. Das heißt 3D-Growth-Model. Das haben wir auch sehr oft benutzt. Und das hilft dir so ein bisschen, diese einzelnen Aspekte zu strukturieren. Weil es ist ja letztendlich auch so vom Nutzerverhalten her, musst du das ja eigentlich denken. Und da passieren ja verschiedene Schritte. Und der erste Schritt ist ja meistens so diese Discoverability. Also sieht der Nutzer das überhaupt? Dann im zweiten Schritt Desirability. Also will der das aus irgendeinem Grund? Möchte er das haben? Und im dritten Schritt so die Duability. Also kann er das halt möglichst einfach umsetzen. Und ich glaube, wenn du jetzt halt beispielsweise sowas, so ein Produkt oder ein neues Feature eben einbaust, dann musst du halt glaube ich eher so ein Framework ansetzen. Also du fragst dich als erstes, okay, wie mache ich das für den Nutzer sichtbar? Nun, dann kannst du halt schön einmal ausmappen, okay, wie oft zeige ich das? Was passiert, wenn ich das öfters zeige? Und dann kommt der zweite Schritt, der ist so ein bisschen schwieriger. Da geht es eher um Desirability. Also, wie mache ich, dass er das auch haben will und dass er das gut findet? Und im dritten Schritt kümmere ich mich eher um die Doability. Und das ist eben oft so counterintuitive, weil man sagt halt, naja, man will ja eigentlich erstmal so an die Conversion ganz hinten. Die sollte ja möglichst einfach sein, und dann setzt man da an. Aber oft ist es halt irgendwie auch eher so ein Aspekt, dass man sagen muss, okay, ihr nutzt ja überhaupt eine Awareness von irgendwas. Und so, würde ich sagen, geht man so von den Hypothesen eher vor. Also man sagt halt, okay, erste Hypothese ist, der User sieht das überhaupt nicht. Der hat überhaupt nicht gesehen, dass es dieses Feature gibt. Dann, zweiter schwierigerer Step ist, er will das gar nicht, er hat kein Interesse daran aus irgendeinem Grund. Und dritte Hypothese dann, er kann es nicht umsetzen, weil es zu schwierig ist.
Jan: Okay, spannend. Wir kamen ja von dem Thema oder von der Frage ausgehend, dass man gar nicht jedes Experiment durchführen kann. Das heißt, wir haben so einige, die lassen sich leichter testen, andere, die lassen sich nicht so leicht testen. Was sind denn mal Feature-Wünsche, wo man sagt, mein Gott, hier kann man das Experiment auch lassen und das einfach bauen. Aber das gibt es ja bestimmt auch Momente, wo man einfach pragmatisch sagt, hier lohnt sich der ganze Aufwand gar nicht.
Nils: Auf jeden Fall. Ich glaube, was wichtig ist, in so einem Kontext erst mal zu betonen, ist, dass man das halt bewusst macht. Ja, sodass man eben bewusst sagt, wir verzichten jetzt auf einen Test. Wir könnten das theoretisch machen, aber wir sparen uns das jetzt aus ganz vielen verschiedenen Gründen. Ich meine, du musst so ein bisschen, glaube ich, auch die Use-Cases unterscheiden. Also es geht einmal eben darum, um zu sagen, okay, A ist besser als B. Ich glaube, wenn du es nach diesem Use-Case nimmst, könntest du eigentlich oft sagen, okay, wir brauchen eigentlich keinen AB-Test, weil es einfach so viele Gründe gibt oder wir zum Beispiel auch einfach kein Risiko sehen, diese andere Version sozusagen zu verwenden. Und da könntest du zum Beispiel oft so einen Test oder ein Experiment skippen und sagen, wir vertrauen jetzt einfach best practices, das passt für uns jetzt gerade. Aber es gibt natürlich auch die Problematik, dass du oft gerne verstehen willst, was hat denn dieser Change genau für einen Effekt. Und da ist es halt, da kommst du halt selten oder schwer so um Experimentation oder um AB-Testing rum, weil nur so siehst du halt, was ist überhaupt der Gesamteffekt von diesem Change, den du halt einführst. Und da gibt es halt nicht so wirklich einen Weg drum rum, aber auch da kannst du natürlich sagen, naja, das ist uns in dem Punkt, ist uns das nicht so wichtig. Und da spielen so viele Faktoren eine Rolle, also da können strategische Faktoren eine Rolle spielen. Du hast das irgendjemandem versprochen. Oder irgendjemand legt da ganz besonderen Wert drauf. Wie gesagt, wichtig ist meiner Ansicht nur, dass man das sehr transparent nach außen aussagt. Wir verzichten darauf ausgrund XYZ. Und dass man das auch nicht verklausuliert, sondern dass man das ganz klar macht. Weil sonst ist das natürlich auch für die Leute, die damit involviert sind, ein bisschen frustrierend. Das ist vermeidbar meiner Ansicht nach.
Jan: Dass man im Prinzip so einen Lerneffekt an der Stelle übersieht oder bewusst übergeht.
Nils: Genau.
Jan: Okay, verstehe. Und wir haben gelernt, was ein Experiment ist. Wir haben auch gelernt, an manchen Stellen kann man sie auch übergeben. Wir haben auch gelernt, man kann prinzipiell gar nicht alles testen. Ganz grundsätzlich sind wir uns aber, wie wahrscheinlich die meisten Zuhörer und Zuhörerinnen auch einig, dass sich das Experimentieren im digitalen Produktmanagement nicht nur lohnt, sondern eigentlich praktisch unerlässlich ist. Und dennoch haben viele von uns in Organisationen gearbeitet oder arbeiten gerade in Organisationen, in denen das Experimentieren, das Vertesten von Hypothesen eben nicht gängige Praxis ist. Und jetzt habe ich mit dir hier mal jemanden zu Gast, der die Organisation jeder Größe kennt, also der ganz early-stage Start-up, die mittelgroßen Scale-ups, die großen Digitalkompanies wie gerade Zalando zum Beispiel kennt. Und da würde mich mal interessieren, wie baue ich denn in diesen jeweiligen, doch sehr unterschiedlichen Umfeldern eine Kultur des Experimentierens auf? Und vielleicht fangen wir mal, weil ich vermute, die Komplexität des Aufbaus einer Kultur des Experimentierens bei den kleinsten am einfachsten ist. Wie gehe ich denn in einer ganz Early-Stage-Company vor? Also sagen wir, da sind fünf, sechs, sieben Leute, wir haben noch keinen richtigen Product-Market-Fit. Das Unternehmen gibt es seit einem halben Jahr. Bisher hat aber noch nie jemand etwas vertestet. Wie gehe ich da als Produktperson vor, wenn ich dem Team beibringen will, dass wir das zu unserer DNA machen?
Nils: Ja, also ich glaube, es ist ja bei ganz vielen erstmal so die Herausforderung, eine gewisse Awareness überhaupt dafür zu schaffen, dass es das als Methode gibt. Und dann eben auch klar zu machen, dass das halt zu zu viel besseren Ergebnissen führt. Also gerade wenn du jetzt irgendwie sehr, sehr Earlystage bist. Ich glaube, heutzutage kannst du ja, hab ich auch neulich mal gelesen, also dieses Feasibility-Problem, das wir sozusagen vor, weiß ich nicht, 20 Jahren oder so hatten, kann man etwas überhaupt bauen. Das gibt es ja heutzutage gar nicht mehr so richtig. Also du kannst fast alles möglich machen. Was aber nicht so einfach zu bestimmen ist, ist, ob die User das halt wirklich wollen. Und das ist halt ne Erkenntnis oder etwas, was du halt so ein bisschen, was du halt verstehen musst. Also dass das halt nicht so straightforward bist. Es reicht heutzutage nicht mal mehr, ein Produkt zu bauen, das alle Leute wollen, meiner Ansicht nach. Sondern du musst sogar gleichzeitig noch zusätzlich verstehen, wie kann ich das überhaupt vermarkten? Und wie habe ich die richtigen Distributionskanäle für so ein Produkt? Und all diese Dinge, die kannst du halt austesten. Indem du halt nicht sagst, naja, ich warte jetzt, bis ich eine Funding-Runde habe und dann setze ich 10.000 Euro auf Google Ads. Sondern dann mache ich das halt mal im kleineren Rahmen und versuche das so ein bisschen zu verstehen. Wie viel würde mich das kosten? Wie kann ich das hochskalieren? Und das ist für mich alles eine experimentelle Vorgehensweise, mit der du meiner Ansicht nach auch Investoren beeindrucken kannst. Investoren wollen Traction sehen, die wollen aber auch verstehen. Die wollen aber auch sehen, dass du dein Produkt verstanden hast und dass du auch ganz klar darlegen kannst, wie skaliere ich dieses Produkt? Wie kriege ich da mehr Traction? Und auch da hilft dir genauso Experimentation weiter. Und genau das sollte man als Produktmensch in dieser Organisation dann eben auch ganz früh schon darstellen.
Jan: Also im Prinzip der Ansatz hier Education. Ich habe vier, fünf, sechs, sieben Kollegen und Kolleginnen in der nächsten Fundingrunde wollen Investoren wissen, wofür braucht ihr denn überhaupt Geld? Und dann wird man begründete Antworten geben können, die mehr sind als einfach, ich weiß ja ein Slide Deck mit so ein paar Ideen, sondern schon einige bewiesene Fakten drauf haben. Und da geht es einfach um One-on-one Education. Ich bringe den Leuten bei, was man da überhaupt machen kann und warum das wichtig ist.
Nils: Ja, also genau wie du sagst, genauso ist ja letztendlich die Situation. Also da sitzen Investoren, die wollen dir halt irgendwie 10 Millionen Euro oder so irgendwas geben. Und die wollen natürlich wissen, wofür du das ausgibst. Dann kannst du natürlich einfach hingehen und sagen, naja, für Performance Marketing und so und so sieht es dann ungefähr aus. Du kannst aber auch sagen, naja, wir haben uns verschiedene Kanäle angeschaut und hier glauben wir daran, auf Basis von folgenden Daten. Und dann ist das meiner Ansicht nach schon ein ganz anderer Pitch. Also ich als Investor würde das super gut finden, wenn mir das jemand, bzw. ich würde sogar fragen, warum habt ihr das nicht schon gemacht? Und ja, dann halt einfach bessere Ergebnisse oder bessere Prognosen einfach machen zu können.
Jan: Ja, cool. Und wenn die Organisation ein Ticken größer ist, also sagen wir, ich fange als neuer Product Leader in einem Scale-Up an, das vielleicht einfach relativ, passiert ja auch oft genug, relativ zufällig in den Product Market Fit mal reingestolpert ist, immer mehr Leute angestellt hat, inzwischen sitzen da 100, 150 Personen, die bearbeiten das Produkt. Jeder hat verschiedene Ideen, wo es jetzt hingehen kann, aber so ein richtiges, wir testen unsere Ideen, ist halt einfach noch nicht Teil der DNA des Unternehmens. Wie gehe ich da am besten ran, wenn ich da frisch in so ein Team reinkomme?
Nils: Ich glaube, an so einer Stelle ist es eben wichtiger, dass man das, da hast du ja schon eine gewisse Art von Rituals. Ja, also da hast du schon sowas wie irgendwie, du hast Weekly-Meetings, wo du halt alles mal besprichst, weil du das halt brauchst, weil du noch nicht so, weil du nicht mehr so eng bist, dass du dir halt alles einfach zurufen kannst. Sondern dann brauchst du schon so ein paar Rituals einfach. Und ich glaube, da würde ich das halt integrieren, ja. Also banale Sachen wie beispielsweise, dass man sagt, okay, wie viele Experimente gab's, wie viele haben wir diese Woche gemacht, was haben wir daraus gelernt? Dass man das einfach Teil seiner Rituals macht, was natürlich auch immer ein wichtiger Punkt ist, ist so ein bisschen dieses, dass man diese Psychological Safety herstellt, ja. Also ich meine, das weiß ja auch jeder, dass es halt ultra wichtig ist. Und dass man halt letztendlich das gefailte Tests oder nicht erfolgreiche Tests genauso gefeiert, wie eben Tests, die etwas Positives hervorgebracht haben. Weil beides eben letztendlich ein Learning ist. Und ich glaube, so was ist zum Beispiel in so einer Phase dann auch ultra wichtig.
Jan: Also meiner Erfahrung nach weiß das gar nicht unbedingt jeder, dass so psychologische Sicherheit so relevant dafür ist, dass man überhaupt so eine Experimentierkultur aufbauen kann. Vielleicht kannst du da zwei, drei Worte zusätzlich zu sagen.
Nils: Ja, also ich meine, das ist ja dieser Begriff von Amy Edmondson. Ich glaube, die hat ja das auch ziemlich gut begründet damals. Aber klar, also natürlich arbeitest du am besten, wenn du eine gewisse Sicherheit fühlst. Und wenn du dich eben so fühlst, dass du halt auch die Sachen mehr oder weniger aussprechen kannst, die du denkst. Und das äußert sich halt vor allem im Bezug auf Fehlern, ne? Das ist eines der besten Bücher, das ich in den letzten paar Jahren gelesen habe. Das heißt The Right Kind of Wrong, eben von Amy Edmondson. Und das erweitert sozusagen diesen Psychological Safety Begriff noch ein bisschen. Und übersetzt den so in verschiedene Fehlerarten. Und Fehlerarten, wie beispielsweise Basic Failure. Das ist sozusagen ein Fehler, den wir halten, Oversight oder ein Slip. Ja, also wir vergessen irgendwas, schreiben irgendwas falsch oder so. Klar, muss man vermeiden und man muss sich irgendwie Methoden und Prozesse suchen, um das halt so gut es geht auszumerzen. Ist aber jetzt kein Ding, das wir eigentlich wollen, ne? Es gibt Komplex-Failure. Die sind schwer vorherzusagen. Die stehen meistens, wenn halt so verschiedene Teams zusammenarbeiten und die haben beispielsweise so eine Metrik, die halt nicht jeder so gleich beeinflussen kann. Aber das ist sehr schwer, das zu verstehen. Aber sowas wollen wir auch nicht. Was wir aber wollen, sind sozusagen diese intelligent Failures. Also dass wir sehen, wir haben eine bestimmte Hypothese. Wir sagen, dass wir jetzt diese Hypothese eben testen. Und dann ist sie falsch, stellt sich das falsch raus. Also wir haben eine falsche Hypothese aufgestellt. Mehr ist es nicht. Das war ein intelligent Failure. Und ich glaube, dass also in einem Team oder in einem Unternehmen sozusagen so rauszukarben und zu sagen, darum ging es jetzt hier und dass es gut, dass das passiert ist, das erfordert schon sehr, sehr viel Verständnis, sehr, sehr viel Insight und sehr, sehr viel Leadership. Aber ich glaube, dass das zu einer Unternehmenskultur führt, die letztendlich perfekt ist, um eben möglichst viele Experimenter zu fahren.
Jan: Ja, macht total viel Sinn, weil wenn wir so ein Umfeld nicht bieten, geht man ja schnell in eine Situation rein, in der Leute Hypothesen aufstellen, die common sense sind, damit das Experiment ein positives Ergebnis hat. Aber haben wir wirklich viel daraus gelernt, wenn wir etwas vertestet haben, von dem eh alle davon ausgingen, dass es richtig ist. Wahrscheinlich eher weniger.
Nils: Genau, das siehst du ja auch ganz häufig so in Bezug auf Discovery, dass man halt sagt, naja, man macht jetzt eben Product Discovery und dann gibt es ganz viele Produktmanager, die ganz viele Leute interviewen und dann stellt sich heraus, ja wir hatten recht. Und genau, ich glaube, diese Self-fulfilling Prophecy, das ist natürlich auch etwas, was man natürlich vermeiden sollte, was aber auch schwierig ist, das so ein bisschen dann die Organisation davon abzubringen, jedenfalls aus meiner Erfahrung.
Jan: Hast du einen Tipp, wie das gelingen kann, gerade aus der Perspektive eines Product Leaders, einer Product Leaderin, wenn ich dann ein Team habe, das nicht gewohnt ist, so zu arbeiten, da reinzukommen und sich auch wirklich dem auszusetzen? Also nur das eine ist ja, man sagt, man hat da gerne eine psychologische Sicherheit zu und freut sich, wenn die Leute das machen. Aber wie kann man wirklich dafür sorgen, dass das auch bei den Leuten ankommt?
Nils: Ich glaube, das ist halt eine Frage, wie du, wie du, wie Leadership Letzten das in den Meetings agiert, ja? Also wie die über bestimmte Dinge nachfragen. Beispielsweise, ich denke mir immer so, weiß ich nicht, wenn jemand sagt, er hat ein Feature geschippt oder es gibt ein neues Feature, dann denke ich mir immer so, ja, das ist, na, das ist schon so, also eigentlich Brot und Butter unseres Geschäfts, ne, so klar, machen wir tagtäglich so. Wir können uns natürlich überfreuen. Wir können aber auch fragen so, okay, war das jetzt gut für den Nutzer oder nicht? Und das ist ja eigentlich so die Frage, die uns am meisten interessieren sollte. Und ich glaube, darauf sollte man sich halt so als Leader oder auch als Team so fokussieren, ne. Da kannst du natürlich sagen, oh, das ist natürlich schwierig, weil du dann irgendwie so eine Außenseiterrolle hast und alle anderen Teams machen das doch auch. Aber letzten Endes wird dich das halt schon, zu einem gewissen Alleinstellungsmerkmal bringen, weil du halt die Sachen so begründest, wie sie dann halt auch letztendlich für das Leadership auch Sinn ergeben, ne. Weil wenn ich sage, ich habe ein Feature geschippt, ist das was anderes wie, hey, ich habe jetzt ein Feature geschippt und das bringt uns 15 Millionen annual revenue plus jedes Jahr. Das ist eigentlich eine viel spannendere Aussage, ne.
Jan: Okay. Also wirklich die Attention auf die Outcomes legen.
Nils: Cool.
Jan: Und angenommen, ich bin jetzt in einer deutlich größeren Organisation. Noch mal eine Magnitude größer. In meinem Unternehmen arbeiten vielleicht 750 Leute. Es läuft soweit ganz gut. Aber ich bin da und ich merke, hey, eigentlich muss ich die Organisation jetzt dazu bringen, mehr zu experimentieren, damit wir den nächsten Schritt machen können und tatsächlich auch als Organisation besser werden und nicht einfach nur das bestehende Produkt weiter optimieren, sondern wirklich wieder ins Interieren kommen. Was kann ich da machen?
Nils: Ich glaube, an so einem Punkt muss man sich dann schon so die Frage stellen, wie man das überhaupt in das Unternehmen reingibt. Also ob man beispielsweise ein komplett neues Team erschafft, das ich dann idealerweise Growth Team oder so nennt, das zum Beispiel auch gar keine Ownership von bestimmten Dingen hat, sondern eher so holistisch über die Produkterfahrung nachdenkt und eben sagt, naja, jetzt stellen wir mal so ein paar Sachen in Frage. Und wenn ich jetzt eben Teams habe, keine Ahnung, die arbeiten halt an einem bestimmten Aspekt von einem Feature, die fragen sich halt auch nicht, braucht es das Feature überhaupt oder ergibt das überhaupt Sinn so in unserem Feature-Portfolio? Und wenn man dann halt so ein neues Team erstellt, dass das so ein bisschen so übernimmt, natürlich in einem respektvollen Rahmen und so, ich glaube, dann bringt das schon mal einen neuen Denkanstoß oder eine neue Initiative in das Unternehmen rein und challenge vielleicht auch so ein bisschen die etablierten Teams und verhindert vielleicht dann auch teilweise so ein bisschen, dass so die Produktorganisation in das Produkt so zu sehr einfließt. Es ist ja auch eine typische Situation für viele Produkte.
Jan: Na total, da ist man schnell bei Convice Law, dass die Teams, die es gibt, dann die Struktur wieder abbilden und das Produkt der Teamstruktur am Ende entspricht.
Nils: Ja, exakt.
Jan: Okay, das heißt, da würdest du so rangehen, dass du sagst, schaff ein Team, dessen Aufgabe es tatsächlich ist, genau diese Fragen zu stellen, damit die sich nicht zu sehr mit der einen Sache, an der sie gerade bearbeiten, zu eins machen, sondern wirklich eine dedizierte Mission haben, genau das nicht zu tun.
Nils: Also das kann eine Lösung sein. Ich glaube, das ist nicht bei allen jetzt die ultimative Lösung, aber ich letztendlich bei Contentful haben wir das genauso gemacht und das hat eigentlich ziemlich gut funktioniert. Man kann aber zum Beispiel auch so die Art und Weise, wie man das Produkt so geschnitten hat, beziehungsweise wie man das Produktteam geschnitten hat, dass man das so ein bisschen in Frage stellen. Also dass man eben sagt, naja, wir fokussieren uns jetzt nicht mehr auf Features, sondern wir fokussieren uns auf User Types oder User Journeys. Dass man beispielsweise sagt, okay, wir legen jetzt vier Personas fest. Es gibt vier verschiedene Produktteams und die arbeiten mit dieser Person zusammen. Es geht so ein bisschen darum, dass du halt diese Legacy und diese Ownership für bestimmte Sachen so weit wie möglich von den Teams rausnimmst. Ich glaube, dann ist einfach mehr Kreativität gegeben, mehr Innovationskraft gegeben. Und dann stellst du halt einfach mehr Dinge in Frage und kommst halt auch auf viele neue Hypothesen, die du dann vertesten kannst.
Jan: Wie ist denn das mit Wissensmanagement? Also wenn ich jetzt auf dem Scale viele neue Experimente fahre, vielleicht haben wir einen Growth-Team, das genau auch gerade guckt, wo können wir uns eigentlich so ein bisschen selbst disrupten. Dabei laufen oft dann ja auch nicht irgendwie ein Experiment, sondern auch mal 20, 30, 40 parallel ganz viele Learnings fallen raus. Hast du einen Tipp, wie man das Wissensmanagement bei einer Organisation von der Größe gut managen kann?
Nils: Ja, das ist auf jeden Fall eine sehr wichtige Challenge. Du weißt, letztendlich ist das Ziel auch von Experimentation, ein Institutional Memory aufzubauen. Das heißt, ich glaube, ein wichtiger Aspekt ist natürlich, dass du an einem gewissen Punkt im Experimentation Lifecycle so eine, ich sage mal, Zentralisierung hast. Das funktioniert in Form von Tools dann meistens so als Experimentation Plattform, wo du eben sagst, na ja, hierüber laufen an irgendeinem Punkt, beim Assignment oder zumindest bei der Analyse laufen dort halt alle Experimente rein und dort halte ich die zumindest alle mal fest. Und idealerweise habe ich natürlich einen Haufen richtig gute Metadaten, die mir dann auch noch so ein bisschen sagen, okay, ging es da um dieselbe Primary Metric, war das in derselben Area, hat es dieselben User betroffen und so. Und so kannst du das zumindest mal ansatzweise systematisieren oder sozusagen in den selben Topf bringen. Was du dann genau machst mit all diesen Daten an irgendeiner Stelle, ich glaube, da sind viele, viele Unternehmen und wir auch gerade dran, weil wir natürlich verstehen wollen, wie nutzt man dieses Wissen dann wiederum am besten, um sozusagen besser die User holistisch zu verstehen. Weil wenn ich bestimmte Person ausgebildet habe und ich glaube daran und ich glaube an diese, dann will ich natürlich auch mehr oder weniger Beweise dafür sammeln, die mir sozusagen bestätigen, dass das wirklich so ist, dass diese User existieren und dass die eben die Art und Weisen haben, die wir eben zuvor angenommen haben.
Jan: Okay, cool. Also das heißt, gehen einmal noch mal durch. Wenn ich in einer Organisation arbeite, die keine Experimentierkultur hat, wenn das ganz Early Stage ist, dann gehe einfach ran, Educator, die Kollegen und Kolleginnen, die wenigen, die man da hat, warum das wichtig ist. Wenn wir 150 Leute haben, wenn wir haben schon eine gewisse Routine da und wir haben schon gewisse Normen in der Organisation, dann etabliere das in den Routinen, die es gibt. Setze das zum Beispiel als Standardpunkt auf die Agenda und achte als Leader oder Leaderin darauf, dass du das auch unterstützt und besonders positiv hervorhebst, wenn jemand das macht. Wenn es größere Organisationen gibt, dann kann ein guter Weg sein, ein dediziertes Team dafür aufzustellen, dass sich genau die Fragen stellt. Wo müssten wir eigentlich mal genau reingucken? Welche grundlegenden Hypothesen müssen wir jetzt mal in Frage stellen, auch wenn da vielleicht ganze Abteilungen in der Organisation dranhängen?
Nils: Sehr schöne Zusammenfassung.
Jan: Cool. Und auch wenn ich das mache, wir kennen das alle, man stößt in verschiedenen Organisationen ja dennoch auf gewisse Hürden, auf gewisse Widerstände, wenn man anfängt mehr zu experimentieren. Was sind denn so die typischen Pitfalls, denen man gegenüber steht, wenn man damit beginnt?
Nils: Ich glaube, es ist letztendlich gar nicht mal so unterschiedlich vom Standard Produktmanagement. Also man sieht zum Beispiel bei Zalando, aber eigentlich bei allen Companies sieht man eigentlich dasselbe Phänomen. Du hast in all deinen digitalen Produkten hast du eine gewisse Art von Real Estate, also einfach Fläche, Arten von Impressions, wo automatisch einfach jeden Tag Traffic drüber kommt. Letztendlich geht es ja jetzt um ein gewisses organisationelles Alignment. Was ist uns gerade am wichtigsten? Soll da jetzt im Fall von Zalando, wenn du jetzt irgendwie eine Webseite hast und da ist so ein großer Banner ganz oben, was sollen wir da drauf, also was sollen wir da advertisen? Sollen wir da sagen, hey, wir glauben, dass es für dich Sinn macht, jetzt auch noch Schuhe zu kaufen und Parfüm? Oder hey, willst du nicht vielleicht Plusmember werden? Oder hey, wie sieht es denn aus mit den pre-owned Geschichten, die wir auf unserer Webseite anbieten? Also das sind ja alles verschiedene Stakeholder und alles verschiedene Teams, denen diese Art des Produkts oder dieser Teil des Produkts wichtig ist. Und das ist halt so ein bisschen die ganz große Kunst meiner Ansicht nach, dann zu erkennen, okay, wie kriege ich das hin, das Richtige jetzt an der richtigen Zeit für die richtige Person zur Verfügung zu stellen. Und ich glaube, dass Experimentation ist ein guter Ansatz, das zu lösen. Aber letztendlich ist das gleichzeitig der Root Cause von vielen Diskussionen und vielen Problemen, die man diese eben gibt.
Jan: Ja, also das heißt, wieder die Frage, wo setze ich eigentlich warum meine Priorität, genau wie im allgemeinen Produktmanagement, das muss ich klären.
Nils: Ja, genau.
Jan: Wie sieht die Antwort dafür deiner Meinung nach aus?
Nils: Ja, also ich glaube, da kann man eben wieder ins ganz hohe Leadership gehen und sich eben fragen, okay, was ist denn unsere Grundhypothese? Und das sind ja alles, also Strategien sind ja auch mehr oder weniger einfach nur Hypothesen. Also wenn ich sage, hey, ich glaube daran, dass wir, weiß ich nicht, viel zu wenig Schuhe oder viel zu wenig Sportartikel verkaufen und ich will mich jetzt darauf fokussieren, dann ist das eben das Element, was ich jetzt am meisten benutze in solchen Fällen, dann hat das eben Priorität. Und das Wichtige, was man vielleicht noch sagen muss, ist, das muss keine richtige oder keine wahre Hypothese sein, ja? Also dieses gute Sprichwort sometimes wrong, never in doubt, das ist ultra wichtig, weil was tödlich ist für das Experimentieren oder für Produktmanagement allgemein, ist der Verlust von Geschwindigkeit oder der Verlust oder der Mangel an Entscheidungen, ja? Also wenn ich mit 20 Teams erstmal diskutieren muss, was ich letztendlich anders auf diese Seite packe und das ist nicht von Anfang an klar, das lehnt die ganze Organisation, das frustriert alle und das ist etwas, was man vermeiden sollte. Das heißt, wenn man die Strategie von Anfang an sehr glatt zieht und sagt, das ist unsere Hypothese, daran glauben wir, das ist klares klar und das sind vielleicht auch noch die Tradeoffs, die wir da sehen, dann ist es sozusagen für die ganze Organisation klar und dann stellt sich so eine Frage überhaupt nicht, wer sozusagen da das Vorrecht hat, sondern es ist einfach klar, wir setzen darauf, das machen wir für ein Jahr, dann stellen wir das alles nochmal in Frage. Aber sowas ist halt meiner Ansicht nach wichtig. Die Geschwindigkeit, mit der man Entscheidungen trifft.
Jan: Ja, dem kann ich sehr zustimmen und ich verstehe total, was du meinst mit der Parallele zur Standardprodukteentwicklung, wo das Experimentieren als Einzelfall gar nicht anders ist. Ist die Strategie klar, ist auch klar, was zu tun ist und sie ist überraschend oft, ohne da jetzt mit dem Finger auf eine einzelne Organisation zeigen zu wollen, sie ist überraschend oft einfach nicht so ganz klar.
Nils: Ja und ich kann dir auch sagen, also wir machen ja auch ganz oft so, ich sag mal Workshops mit einzelnen Teams und User Journeys und so weiter. Was sind die einzelnen Schritte beim Experimentieren? Das ist die erste Frage. Und die zweite Frage, wie viel Effort ist dahinter? Und der Effort ist meistens nicht bei Dingen, wo man sagen würde, wow, okay, wie kriege ich jetzt diesen einen Datenpunkt zum anderen oder wie setze ich das statistisch in meinem Tool um? Der größte Effort ist immer im Alignment, immer in der Collaboration mit anderen Teams. Und das muss man halt als Organisation, glaube ich, verstehen und halt auch versuchen, auf verschiedene Art und Weise herauszunehmen. Weil es gibt ja auch zum Beispiel ein ganz berechtigtes Interesse, ja? Also wenn ich jetzt beispielsweise sage, hey, wenn ich auf unserer Website irgendwie Winterschuhe im Sommer zeige, weil ich glaube, das bringt es halt voll, dann sagen vielleicht andere Leute oder andere Teams, die eben gerade T-Shirts advertisen, hey, das hat einen negativen Effekt auf uns. Und klar, dann muss ich das eben auch in das Experiment aufnehmen und sagen, okay, was ist denn die Guardrail-Metrix? Was kann da einen negativen Effekt erzeugen? Und dann muss ich das für die natürlich auch klar darstellen. Und ja, ich glaube, das ist eben so das, was das Wichtige ist, dass man auf irgendeine Art und Weise diesen, ich sag mal, sehr manuellen Alignment-Aspekt so gut wie möglich rausnehmen muss, sodass die Teams einfach schneller arbeiten können.
Jan: Macht total Sinn und ist dann wahrscheinlich auch eine ganz gute Überleitung zu einer anderen Frage, die ich in dem Kontext von so Hindernissen und Problemen habe. Und zwar, wenn man das zu stark durch operationalisiert, läuft man ja auch in die Gefahr, oder korrigiere mich, wenn du es anders siehst, aber dass man so eine Situation schafft, in der irgendwie so lokale Maxima von einmal definierten KPIs optimiert werden, was wiederum oft dann nicht im Sinne der Gesamtorganisation ist. Sagen wir, die Strategie ist klar, wir wollen jetzt in Q3 voll auf recurring customers setzen, wir haben eine große Kundenbasis, die möchten wir wieder aktivieren. Dann definiert man vier, fünf KPIs, die sich bitte nicht verschlechtern sollten, und drei, vier, an denen wir das messbar machen. Dann kommt man trotzdem oft in eine Situation, wo, okay, dann werden ganz viele CRM-Marketing, E-Mail-Marketing-Kampagnen rausgehämmert. Die Leute kommen häufiger auf die Plattform, aber am Ende waren es doch nur wieder Engagements, weil man vergessen hat, irgendetwas anderes zu definieren. Also du weißt, worauf ich hinaus will. Wie kann ich vermeiden, dass ich dann in so einem Number-Gaming optimieren von so einem ganz lokalen, kleinen Thema werde, was das große Ganze aus den Augen verliert?
Nils: Ja. Also das ist natürlich eine Frage des Experiment-Designs letztlich, ne? Also klar kannst du natürlich zu Beginn sozusagen die komplett falsche und, sag mal, zu nahe Matrix setzen. Natürlich mit einem guten Hintergedanken, dass du sagst, naja, das ist auf jeden Fall messbar und da kriege ich auf jeden Fall statistische Signifikanz hin. Aber natürlich darfst du auch nicht irgendwie die Metriken, die dich eigentlich interessieren, ganz hinten raus vergessen, ne? Das heißt, oftmals ist es eben so, man muss diese alle berücksichtigen, ja? Aber man wählt häufig dann eben eine Primary Matrix so ziemlich in der Mitte, ne? Aber darf natürlich dann auch, auch wenn es länger dauert, das Ganze zu messen, die Metriken, die sozusagen ganz hinten im Pfeil sind, die ultimative Conversion-Metrik, brauchst du natürlich trotzdem als Guardrail-Metrik, ja? Und ich sag mal, bei den meisten Experimentation-Plattformen ist es ja auch letztendlich möglich, dass du das natürlich logischerweise nicht sofort siehst, aber dass sich das dann irgendwann ergibt, dass du, dass sich herausstellt, naja, wir haben jetzt gerade was sozusagen lokal optimiert. Das hat sich letztendlich negativ ausgewirkt. Und das ist dann ja auch wiederum Learning. Es ist halt nur, ich sag mal, eine Frage der Disziplin, das dann tatsächlich auch sozusagen einzubeziehen in die zukünftige Produktentwicklung.
Jan: Also wir sind wieder bei dem Gedanken-Experiment, auch wenn es am Ende initial mal nicht ein positives Ergebnis hat, ist auch ein Learning und damit gelungen.
Nils: Auf jeden Fall, ja.
Jan: Und was empfiehlst du Organisationen, die sagen, wir würden gerne experimentieren, aber wir haben ja hier unsere eigentliche Roadmap und wenn wir jetzt Ressourcen hier abziehen zum Experimentieren, kommen wir ja mit unserer Roadmap nicht zutage. Wie balanciere ich diesen Drahtseilakt?
Nils: Ja, ich glaube, die Roadmap sollte sich ja idealerweise aus den vielen Experimenten ergeben. Und ich glaube, Elena Werner hat es ja irgendwie auch schon einmal gesagt, dass, wie ihr wollt von mir, dass ich eine Roadmap bestelle, ich weiß so überhaupt nicht, was ich in ein paar Monaten mache. Und ich glaube, so ähnlich ist es bei Experimenten eben auch. Man muss letztendlich so ein bisschen als Produktmanager, glaube ich, aus diesem Mindset oder aus diesem Gedanken rauskommen, dass all diese Features eben nützlich sind. Ganz oft ist es so, also es gibt, glaube ich, auch Statistiken dazu, es ist einfach ganz oft so, dass ein Feature, das du releasest, dass das sogar zusätzliche Maintenance dich kostet, weil du das halt in Stand halten musst, aber die halt gar nicht so viel bringt. Und wenn du halt diese Rechnung mal so richtig aufmachst, dann wirst du halt sehen, es ist halt ganz oft, macht es halt ultra Sinn, etwas lieber zu testen und gar nicht zu shippen, als das halt zu shippen und dann zu sagen, ja toll, aber letztendlich hat es uns gar nichts gebracht. Und deswegen muss man vielleicht auch so ein bisschen, also ich verstehe Roadmap als wichtiges Stakeholder tun, aber man muss halt auch letztendlich festhalten, was das ist. Also wir geben da sozusagen eine Aussage, was wir glauben, was als nächstes passiert. Aber das kann sich alles ändern. Und das sollte sich auch oder das sollten wir auch alles in Frage stellen, indem wir eben versuchen, bevor wir irgendwas in einem großen Stil anfangen zu bauen, dass wir das validieren. Besonders wenn das halt Risiken beinhaltet.
Jan: Okay, also einerseits muss ich mir im Hinterkopf behalten, dass ich in dem Moment meine Roadmap ist eigentlich erstmal auch nur eine Annahme. Wenn ich nie ein Experiment gemacht habe, kann die total falsch sein. Gleichzeitig, um da mal Devils Advocate zu spielen, habe ich ja schon auch einen Punkt, dass wenn ich jetzt sage, wir haben bisher keine Experimente gefahren, wir haben nicht genug valide Daten und jetzt wollen wir das machen. Es kann jetzt aber auch nicht sein, dass wir da komplett aufhören zu entwickeln. Für zumindest auch für den Moment. Aber nur kann man vielleicht auch sagen, aber da bin ich mal gespannt, wie antwortest du jetzt einer Geschäftsführerin, die sagt, der Laden muss laufen, wir müssen weiter bauen. Wir haben jetzt keine Zeit, drei Monate lang nur zu testen.
Nils: Ja gut, das muss ja nicht. Also ich glaube, diese radikalen Änderungen, die klappen sowieso selten. Sondern man muss das ganz oft sozusagen in der Organisation ein bisschen einmassieren. Also beispielsweise, dass man eben in dem ersten Schritt vielleicht gar nicht sagt, naja, Moment mal, macht das Feature überhaupt Sinn? Sondern dass man eben so ein bisschen eher in das Gespräch kommt, was wir am Anfang gesagt haben. Welche Hypothesen stecken dann hinter diesem Feature? Und wenn man dann vielleicht halt irgendwann mal so eine Analyse macht und es tatsächlich shippt, dass man eben sagt, okay, waren dann vielleicht irgendwelche Hypothesen, waren die nicht richtig? Wollen wir die vielleicht nächstes Mal besser testen? War das jetzt nicht vielleicht eigentlich ein Misserfolg, obwohl wir es in der vorausgesagten Zeit geschippt haben? Und ich glaube, wenn man so Gespräche halt erst mal anfängt und dann so ein bisschen die Stakeholder auf seine Seite bringt, ich glaube, dann kann man so ein bisschen anfangen, okay, jetzt haben wir mal ein neues Feature, oh, das ist wieder dasselbe, okay, wie kriegen wir das so ein bisschen raus? Hier haben wir hohes Risiko, das muss sitzen. Und ich glaube, dann kommst du halt in richtig gute Gespräche, so radikal würde ich da eigentlich nie rangehen.
Jan: Okay, also graduell ist die Antwort auf radikal.
Nils: Genau.
Jan: Sehr gut. Und nun ist es Mitte 2025. Ich denke, wir müssen über AI reden. Wie glaubst du, verändern LLMs verändert das, was wir heute mit AI im Prinzip out of the box an jeder Ecke machen können, die Art und Weise, wie wir Experimente gestalten können?
Nils: Also, ich hab da ja schon sehr viel drüber gesagt. Ich hab ja meine AI World Tour und so schon bei LinkedIn angekündigt. Aber letztendlich unterscheide ich eben zwei Ebenen. Die erste Ebene, die gilt eben für jeden, letztendlich jeden Prozess und jedes Team, das du in einer Organisation hast. Wenn man sich den Experimentation Lifecycle anschaut und sagt, ich muss eine Idee haben, muss das in eine Hypothese umformen, muss das priorisieren, muss das Experiment designen. Das sind ja alle Steps, da kann ich in verschiedenen Formen immer AI benutzen. Das ist so die prozessuale Ebene. Und da habe ich beispielsweise so eine Studie auch geschrieben, da haben wir so acht verschiedene Use Cases, acht verschiedene Process Steps unterschieden und insgesamt 23 verschiedene Use Cases etabliert. Das fängt an bei, naja, was ist denn, wenn ich jetzt auf einmal ein LLM benutze, um zu verstehen, wie gut die Hypothese ist, die ich aufgestellt habe. Also in Bezug auf verschiedene Kategorien gefüttert mit all den Hypothesen, die wir bereits in einem Unternehmen sozusagen getestet haben, wie gut die tatsächlich war und so weiter. Das Gleiche für, ich sag mal, alles, was unstrukturierte Daten bilden haltet. Also beispielsweise auch das, von dem, was wir am Anfang gesprochen haben, diese Meta-Learnings aus einem Experiment. Es ist selten, dass du aus einem Experiment nur lernst, okay, das ist besser als das andere. Sondern da steckt natürlich ganz, ganz viel mehr dahinter. Und wenn du das sozusagen alles sozusagen capturesst und dann auch wieder abrufen kannst, durch ein L&M, dem du eben genau diesen Kontext gibst, ich glaube, das ist halt unfassbar viel wert, da jetzt schon rein zu investieren in sozusagen eine saubere Datenstruktur. Nicht mal im Sinne von, dass die Daten selbst sauber strukturierend sein müssen, sondern dass sie einigermaßen noch retrievable sind und man versteht, was mit was zusammenhängt. Das reicht dann schon, um mega große Erkenntnisse und ein megagutes Institutional Memory zu kreieren. Und das wäre eben so diese Prozess-Ebene, ne?
Jan: Wie kann das dann ganz konkret aussehen? Also reicht das dann, wenn ich da einfach irgendwie sage, alle Experimente werden jetzt mal bitte hier in Notion dokumentiert oder so? Oder wie sieht das ganz konkret aus, damit ich mich dafür bereit mache, dass ich irgendeinem Tag, sagen wir, in drei Monaten mal sagen kann, jetzt gebe ich das Ganze mal gezielt einem LLM zur Interpretation, um mal zu gucken, was liest du hier noch raus?
Nils: Das klingt so banal, aber es ist tatsächlich gar nicht so einfach. Man braucht, wie du sagst, ein zentrales Tool, in dem du alle Informationen, die du über ein bestimmtes Experiment hast, eben abspeichert. Und das ist im Idealfall natürlich eine Experimentation-Plattform, die genau dafür geeignet ist, wo du diese Daten auch in einem richtig schönen Data Warehouse und so weiter abspeichern kannst. Vielleicht sogar noch so ein bisschen strukturiert, also dass du unterscheidest zwischen das eine Feld beinhaltet die Hypothese, dann kommt eine Metrik und dann kommt irgendwie so ein paar Sätze zum Learning und so weiter. Und ich glaube, dass das in einem ersten Schritt schon mal zu machen, das ist schon mal ganz wichtig. Sobald das eben an einem zentralen Ort gespeichert ist und ich vielleicht diese Daten auch noch mal von einem weiteren Tool einfach per API abrufen kann. Ich glaube, dann hat man schon ganz, ganz viel gewonnen, weil dann hat man die Daten sehr, sehr flexibel und dann kann man sich letztendlich immer noch überlegen, wie man das genau mit LLMs letztendlich aufgreift.
Jan: Okay, also Hauptsache, man speichert die Daten korrekt ab, im Idealfall in Experimentation-Plattformen, mit guten Erklärungen dafür, was bedeutet jetzt, welches Datenfeld, damit man später auch wirklich auslesen kann, was soll das hier bedeuten, was ich hier in der Datenbank vorfinde.
Nils: Genau und vielleicht sogar, was hat man mit dem Experiment danach gemacht, als das beendet wurde.
Jan: Ja, okay. Okay, auf die Prozess-Ebene hin habe ich es verstanden. Was ändert sich noch durch AI?
Nils: Genau, also ich glaube, der spannende Punkt, oder was jeden so ein bisschen aufhorchen lässt, ist eben nicht die Prozess-Ebene, sondern was ist denn bei den meisten Companies so das eigentliche Problem von Experimentation. Und das ist eben ganz oft der Traffic. Ja, also wir haben nicht genug Kunden, oder wir haben nicht genug User, um letztendlich bestimmte Experimente und Arbiters zu fahren. Und das ist natürlich ein hartes Problem. Ja, also das ist etwas, das haben wir bei Zalando natürlich nicht, aber das hat man bei ganz vielen anderen Unternehmen. Und wie spielt denn da zum Beispiel AI eine Rolle? Kann denn AI vielleicht sogar reale User ersetzen? Und da spricht man dann häufig von Silicon Participants oder Digital Twins. Und ich glaube halt, wir sind nicht so weit davon entfernt. Also man sieht schon die ersten Companies, die das in einem qualitativen Kontext machen. Also die sagen, du kannst hier 20 Interviews in der Zeit von 20 Minuten machen. Und wir können sozusagen diese Digital Twins genauso erstellen, wie du dir letzten Endes deine Person überlegst. Und ich glaube, da sind wir nicht sehr weit entfernt davon, dass das eben auch quantitativ geht. Und dann spricht ja auch eigentlich nichts dagegen, dass man sagt, naja, ich habe jetzt hier Variante 1 und hier Variante 2. Und jetzt will ich mal wissen, wie glauben wir denn, dass sich unsere Userbase verhalten wird, wenn wir das sozusagen an die ausrollen. Und das kann eben auch über AI schon möglich sein. Die Frage ist, zu was das führt.
Jan: Bevor wir da hingehen, wo das hinführt, will ich doch noch mal Devil's Atrocad an der Stelle spielen. Wenn ich eine AI-System, welcher Art auch immer, bitte Antworten auf neue Dinge zu finden, sei es jetzt, indem es ein User, eine Userin für ein Interview simuliert, sei es, indem es Zahlen generiert für ein Experiment, das eigentlich nicht genug tatsächlich empirische Daten hat, dann ist es ja schon so, dass diese Modelle Insights reproduzieren. In einem qualitativen Test würde es dann sagen, ja, ok, basierend auf irgendwelchen Informationen, die ich von wo auch immer habe, könnte jemand so antworten. Und inwiefern unterscheidet sich das dann wirklich von beispielsweise so einer Monte-Carlo-Simulation, wo ich einfach sage, meine Mittelwerte sind so und ich schmeiße jetzt einfach mal tausend Datensätze an die Wand, die ähnliche Daten haben wie die anderen, aber die eigentlich nur nach hinten gucken und eben nicht wirklich Neues erforschen, sondern es nur in ein anderes Gewand tun. Wo ist da der Unterschied?
Nils: Genau, also das Risiko, das du ansprichst, das ist natürlich sehr real, das ist auf jeden Fall da. Also da kann man auch nichts groß gegen sagen. Was ich aber trotzdem anführen würde, ist, erstens, was ist die Alternative? Also wie machen wir es momentan? Ja, also man kann natürlich sagen, okay, das geht nicht, dann machen wir halt gar nichts und shipen es einfach. Weiß nicht, ob das besser ist. Also vielleicht diesen kleinen Schritt von AI-Testing noch zu gehen, wäre vielleicht bei sowas dann eben sinnvoll. Und zweitens müssen wir natürlich noch so die Rolle oder die, ich sag mal, die Hierarchieebene von dieser Art von Tests noch so ein bisschen besser verstehen, ja. Also es muss ja nicht sein, dass das komplett für jeden einzelnen Test und jedem Experiment alle Participants ersetzt. Sondern man kann ja beispielsweise ganz langsam anfangen und sagen, hey, lass uns doch mal alle Tests, die wir sowieso machen würden, AI testen und lass uns mal schauen, wie ist denn jetzt der Unterschied zwischen diesen beiden. Und dann hast du ja schon mal ein gutes Verständnis, wie sinnvoll das tatsächlich ist. Und ich glaube, das wird halt in vielen Dingen auch, ich sag mal, Jobfamilies auch enablen, die gar nicht die Möglichkeit haben, so end to end so ein Experiment zu machen. Ich glaube, ich kenne viele Designer, die sagen würden, hey, da würde ich ganz anders arbeiten. Da würde ich nicht nur eine Variante erstellen, sondern würde ich zehn Varianten erstellen. Und würde halt erstmal versuchen, okay, was sagt mir sozusagen die AI oder was sagt mir sozusagen schon mal ein gewisses Panel, was könnte ich hier noch verbessern? Das heißt, ich sage nicht hier wieder, also dass das komplett alles ersetzen soll sofort, sondern ich sage, dass das halt ganz viele neue Möglichkeiten erschafft. Wie das dann genau im Endgame aussieht, weiß ich auch nicht.
Jan: Ja, verstehe und also ich glaube, da ist schon ein Punkt bei besonders, wenn ich noch gar keine Daten habe. Also ich stehe, ich weiß noch überhaupt nichts über Nutzergruppe X. Sagen wir Schwimmlehrerinnen, weil ich eine App in dem Umfeld irgendwie entwickeln will, um dann so überhaupt mal einen Start zu machen, um überhaupt mal eine Idee davon zu gewinnen, was da los ist. Also 100%iger Buy-in. Ich bin persönlich ein bisschen skeptisch, was so die Tiefe dann am Ende angeht und sehe auch ein bisschen das Risiko der Monte Carlo Simulation. Aber ich glaube, am Ende ist es eh gerade alles noch ein bisschen Coinflip und wir werden am Ende sehen, wo kommen wir da an und welche Use Cases werden sich etablieren und welche nicht.
Nils: Genau, sehe ich ganz genauso.
Jan: Ich bin auch dabei, ich kenne es ja auch aus der Start-up-Realität. Es ist halt einfach auch schwierig, wenn man ganz am Anfang steht, überhaupt signifikante Zahlen rauszuholen.
Nils: Du musst dir ja auch vorstellen, ich glaube, es ist manchmal auch so ein bisschen eine psychologische Komponente. Ich glaube, das geht auch vielen bei uns im Alltag so. Also der Standard-Use-Case, man schreibt irgendeine E-Mail und ist sich irgendwie nicht sicher, weil die aus irgendeinem Grund wichtig ist und pastet sie halt in JETCBT und das JETCBT sagt dann, oh Wahnsinn, super cool, hier ist noch eine kleine Verbesserung und dann denkt man schon so, wow, nicht mal ein L&M sagt, dass es da irgendwas zu verbessern gibt. Das gibt dir halt auch eine gewisse Confidence und ich glaube so ähnlich, dass es dann halt auch irgendwie so bei ganz early Produkten.
Jan: Okay, cool, und auf was sollten wir in dem Kontext von AI und L&M's noch zu sprechen kommen, bevor wir auf das nächste Thema eingehen?
Nils: Ich glaube, was man eben halt nicht unterschätzen sollte, ist so diese human AI Collaboration. Das ist halt so das Wichtigste. Also, als ich mit allen möglichen Leuten darüber gesprochen habe, was sie davon halten, wie man das eben im Prozess benutzt und so weiter, ganz viele Leute haben eben gesagt, naja, es gibt eben so bestimmte Sachen, vor allem so was wie Prioritization. Das wäre für mich die Hölle, wenn das AI übernimmt. Weil dann kommen wir ziemlich schnell halt auf so eine Ebene, wo man sagt, naja, jetzt stehe ich morgens auf, setze mich an den Computer und dann sagt mir der Computer, okay, jetzt machst du zuerst eins, dann zwei, dann drei. Es gibt auch ein gewisses Streben nach, ich sag mal, nach einem gewissen Purpose von Menschen. Und ich glaube, wenn man das halt mit AI ersetzen will, ich glaube, dann wird es richtig problematisch. Und ich glaube, es gibt eben diese rein technische Komponente, was kann AI alles. Das ist ein interessanter Diskussionspunkt. Der zweite wichtige Diskussionspunkt soll da eben sein, wo steht der Mensch sozusagen in dieser Kollaboration?
Jan: Ja, finde ich super wichtig. Also auch, dass man ja Purpose und Bedeutung beibehält und dann nicht das Gefühl hat, dass man selbst am Ende der Agent von irgendeiner AI ist, die halt sagt, du solltest jetzt diese drei Sachen machen, dann läufst du los und machst die. Sondern wie bleibe ich da die Person, die mit der Agency langfristig losläuft?
Nils: Also ich meine, wir sind ja auch alle, wir haben ja auch alle sehr, wir sind ja sehr frei in dem, was wir irgendwie so beruflich und so weiter machen. Das heißt, da geht es ja nicht darum, dass wir irgendwie einen möglichst einfachen Job haben wollen, sondern wir wollen halt einen Job haben, der uns eine gewisse Erfüllung, eine gewisse Anerkennung und so weiter auch bringt. Und ich glaube, das sollte man eben bei sowas nicht und außer Acht lassen.
Jan: Ja, dann kommen wir doch mal auf das nächste Thema und zwar hast du im Vorgespräch erzählt, dass du immer so eine gewisse Inkompatibilität siehst, dazwischen in der Leadership-Rolle als Produktmensch zu sein und einen klaren Fokus auf Experimente zu haben. Und es fällt ja auch auf, dass wir wenig CPOs haben, die die ganze Zeit nur stark machen, wie wichtig Experimente sind, sondern da kommt immer irgendwie andere Themen, die das überlagern. Erzähl doch dazu mal was zu.
Nils: Ja, also ich glaube, das ist halt so ein Ding, was ich mich immer frage. Also wir waren ja auch vor kurzem so auf der booking.com-Konferenz und da ist mir das halt auch irgendwie so aufgefallen, dass da sind Leute, die sind seit 10, 20 Jahren im Experimentation-Game und sagen dann halt immer noch so was wie naja, das Leadership, das hat uns irgendwie nicht die Ressourcen gegeben oder das hat irgendwie das Ding abgesägt oder irgendwie sowas. Und ich denke mir halt, naja, aber das Leadership existiert ja so in dem Sinne nicht. Also es hindert ja auch keinen aus der sozusagen Experimentation-Bubble, dass mal so ein bisschen Erwachsener oder ja, also ich will nicht despektierlich klingen, aber das so ein bisschen reifer anzugehen und zu sagen, hey, ich habe jetzt hier eine Methode, das ist sozusagen mein Spezialgebiet und da bin ich Experte drin. Aber mir geht es letzten Endes schon darum, dass ich in eine Position komme, wo ich sozusagen diese Vision, die ich habe von einer bestimmten Produktentwicklung auch umsetzen kann. Und dann ist es eben nötig halt auch in diese gewisse Funktion reinzukommen und dann halt auch mal mit ganz neuen Herausforderungen zu kämpfen. Also das, was ich ganz am Anfang gesagt habe, auch wenn du CPO bist oder selbst wenn du CEO bist, bist du nicht befreit von Stakeholdern und Interessen aus verschiedenen Richtungen. Und da musst du das auch navigieren. Aber du hast halt ein sehr gutes Verständnis von einer bestimmten Methode, die dir bei ganz vielen Entscheidungen, die halt besonders wichtig sind, helfen kann. Und gleichzeitig musst du dann halt auch, glaube ich, so ein bisschen besser verstehen, okay, welche Entscheidung muss wirklich sozusagen in dieses ganz rigide Konstrukt Experimentation und welche muss ich eben so ganz schnell treffen, um irgendwas nicht aufzuhalten, obwohl ich weiß, die kann falsch sein. Und ich glaube, letzten Endes geht es eben um Entscheidungsfindung. Und deswegen, ich verstehe das nicht so ganz, dass man das eben so selten sieht. Also, dass es eben so wenige CPOs und so wenige Product-Lieder gibt, die sich das halt mehr auf die Fahne schreiben. Weil ich glaube, das würde der Community auch ziemlich gut tun.
Jan: Hätte ich ja eine Hypothese zu.
Nils: Sehr gerne.
Jan: Aber ich glaube, du hast es in anderen Worten ja gerade auch so ähnlich gesagt. Aber was ich persönlich öfter beobachte, ist, dass Leute eine Weile sehr stark Karriere machen, indem sie in einem Thema Experte, Expertin werden. Also ich fange an mit einer Junior-Position und ich lerne so die Basics und dann merke ich, ah, hier ist ein Thema, in dem kann ich excelen. Und dann werde ich drei, vier, fünf Jahre jedes Jahr immer nur mehr gelobt und weiter befördert, weil ich so ein Experte in meinem Feld bin. Ich kann aber aus eigener Erfahrung in Leadership-Rollen sagen, das ist nicht eindimensional. Es reicht nicht, Experte in einer Sache zu sein. Oft ist es sogar eher schlecht, Experte in einer Sache zu sein, weil es meinen Blick so ein bisschen sehr einengt auf eine Dimension. Und ich habe das Gefühl, das ist oft so eine Frage von, wann lasse ich bewusst so ein bisschen die Sache wieder los, die mich eigentlich mal stark gemacht hat. Und das total schwer auszutarieren in der Situation selbst.
Nils: 100 Prozent, ja. Also das ist genau, also da kann ich dir natürlich auch keine, keine glasklare Antwort geben. Aber ich sehe das, glaube ich, genau wie du. Und was ich eben auch sagen will ist, wie gesagt, Experimentation ist eine Methode, die hilft dir in ganz vielen Bereichen. Aber du musst auch verstehen, dass das eine Methode von vielen ist, dass das eine sehr neuartige Methode ist. Und wie halt die, die, ich sag mal, organisationale Realität eben aussieht. Und ich glaube, natürlich kann man schnell sozusagen so in diesen negativen Modus kommen und sagen, jedes Mal, wenn die irgendwie ein neues Feature fahren, ist das grundsätzlich blöd, weil die den Impact nicht gemessen haben. Und ich glaube, so ist das ein bisschen zu negativ. Und ich glaube, da musst du halt so ein bisschen verstehen, wie du sagst, wann man Dinge loslassen muss, wie man mit Dingen umgehen muss und eben nicht immer darauf bestehen, dass bestimmte Prozesse oder bestimmte Methoden angewendet werden muss, obwohl du darin Experte bist.
Jan: Dir ist es ja offenkundig gelungen. Du wärst jetzt nicht in den Rollen, in denen du jetzt bist, wenn du so als ganz klar immer nur diese eine Sache forcieren würdest, wärst du nicht da, wo du jetzt bist. Trotzdem hast du deinen Fokus für dein Profil bewahrt. Wie ist dir denn das persönlich gelungen? Vielleicht kann deine Geschichte anderen Leuten helfen, sich da auch ein bisschen rauszulösen.
Nils: Das ist eine gute Frage, wie ich das gemacht habe. Ja, also ich würde jetzt auch nicht sagen, dass ich irgendwie so krasser Product-Leader bin. Vielleicht mal irgendwann in der Zukunft. Aber ich glaube halt, wie gesagt, man muss einen bisschen reiferer blicken. Man muss ein bisschen rauszoomen. Ja, und sich eben nicht nur sagen, okay, meine Methode ist die richtige und alle anderen, die checken das nicht oder kapieren das nicht. Ich glaube, Stephanie hat das doch auch bei dir gesagt, dass man eigentlich immer das Gute in den Leuten annehmen sollte. Und ich glaube, das hilft einem ganz oft weiter. Also wenn ich jetzt zu einem Team gehe und versuche, die davon zu überzeugen, ein bestimmtes Experiment zu machen, und die sagen nein, dann sollte ich halt nicht sagen, die sind dumm, sondern dann sollte ich halt versuchen, die zu verstehen. Weil da gibt es bestimmt ganz viele gute Gründe, warum die das nicht machen. Und wenn ich dann halt diese fünf Weiß abfrage, warum die das eben nicht machen, und dann komme ich drauf, naja, da ist ein anderes Team und die pushen die. Und da gibt es Alignment-Schwierigkeiten und so. Dann habe ich doch wieder was über meine Organisation gelernt. Und dann kann ich wieder sagen, ah, ein weiterer Case in Point, den ich dann wiederum benutze in meiner Karriere, um sozusagen diesen Aspekt oder diese neue Erkenntnis sozusagen so zu verändern, dass das halt, was ich mir vorstelle, funktioniert. Das heißt, eine gewisse Geduld, eine gewisse Einsicht, dass man nicht alles auf einmal verändern kann. Ich glaube das, ja. Ich glaube, wenn das Leute hören, dass ich sage, ich bin geduldiger Mensch, da würden alle so sagen, was? Aber ja.
Jan: Ja, der Anspruch, den ich an mich selber habe, der spiegelt sich auch nicht immer in jeder Geste. Aber Leben ist halt auch an sich selbst arbeiten, ne?
Nils: Genau, ne.
Jan: Cool, okay. Bevor wir gleich mal ein Wrap-Up um das ganze Experimentierungsthema machen, fände ich es cool, noch mal so aus deiner praktischen Erfahrung mal ein Beispiel zu hören, wo du ein Experiment gemacht hast, wo du dachtest, okay, das ist echt in die Hose gegangen. Und danach reden wir auch noch mal über ein echt erfolgreiches. Aber fangen wir mal beim schlechten an.
Nils: Also, ich meine, es gibt ja, genau, hier muss man auch so ein bisschen unterscheiden zwischen was meinen wir mit schlecht oder was meinen wir mit Fehler, ne? Ich glaube, es gibt natürlich, ich kann dir tausend Beispiele nennen von Experimenten, wo wir halt das Tracking vergessen haben, wo wir irgendwas mit dem Assignment falsch gemacht haben und so. Aber das sind ja nicht so die Interessanten. Ich glaube, die Interessanten sind eher so diese intelligent failures, die wir eben hatten, wo wir irgendwas angenommen haben und dann hat das eben nicht so funktioniert. Ich sag immer so mein Lieblingsexperiment, was ich in so einem Kontext immer nenne. Das hatten wir damals bei Likeminded. Da hatten wir damals nicht so eine große Userbase und da haben wir fast mit allen sozusagen gesprochen und halt ein Interview geführt. Alles Mögliche abgefragt und dann am Schluss diese klassische Frage gestellt, wenn du einen Zauberstab hättest, was würdest du dir wünschen? Genau. Und das war ja Gruppentherapie online und ich glaube, also wirklich 90 Prozent oder so haben gesagt, wir würden uns Single Sessions mit unserem Mentor zusätzlich noch wünschen. Dann haben wir so gesagt, wow, das wäre ja krass. Da müssen wir mehr Mentoren anstellen. Da müssen wir das Payment System ändern. Da müssen wir das machen, das machen, das machen. Ein Riesenaufwand in so einer frühen Phase und sehr, sehr entscheidend. Und dann haben wir halt gesagt, nee, das müssen wir noch ein bisschen besser validieren. Und dann haben wir eben gesagt, hey, wir schicken mal noch eine Survey raus und fragen die so, wie viel würden die zahlen und wann würden die das machen, wie oft würde ich es nutzen und so weiter. Und weiter alles super, alles. Sie würden ganz viel zahlen und das jede Woche nutzen und so weiter. Dann haben wir gesagt, ja, das reicht uns immer noch nicht. Wir schicken einfach eine E-Mail raus mit einem Calendly-Link, wo du auch bezahlen kannst und schauen mal, wie viele sich da tatsächlich was buchen. Und was kam heraus? Niemand hat das gebucht. Und das war ein Riesen-Learning. Und das hat uns danach auch noch nicht gereicht. Wir haben dann gesagt, na ja, vielleicht ist so eine E-Mail so ein bisschen zu shady. Einfach so ein E-Mail mit einem Calendly-Link. Dann haben wir sozusagen einfach so einen Button auf unsere Webseite draufgepackt und gesagt, ja, hier kannst du das jetzt auch buchen. Ein bisschen schöner, ein bisschen valider. Aber auch da hat sich nur eine einzige Person angemeldet für ein Gespräch. Und jetzt kommt natürlich der entscheidende Punkt. Was haben wir daraus gelernt? Wenn Leute aus einer Gruppentherapie-Sitzung kommen und dann in ein Interview gehen und sagen, wir wollen eine Einzelsession, was meinen die dann damit? Vielleicht haben sie einfach in dieser Gruppentherapie nicht genügend Aufmerksamkeit bekommen oder kamen nicht genug zum Reden. Und das ist genau das Learning, das wir haben wollten. Was haben wir dann gemacht? Wir haben den Mentoren, die diese Gruppen betreuen, gesagt, bitte achtet darauf, dass die gleichzeitig also ungefähr die gleiche Redezeit haben, haben dem beispielsweise auch noch so einen Tracker eingebaut, dass die eben sehen, wer hat wie viel geredet, haben das dann auch so ein bisschen ausgewertet noch. Und wir haben dann nochmal diese Umfrage gemacht. Da waren es dann nur noch so 40 Prozent, die das ungefähr gewollt haben. Und ich glaube halt wirklich, dass das das große Learning aus dieser Geschichte war. Sehr ausführliche Story, aber das ist eigentlich so mein Lieblingsexperiment.
Jan: Ja, spannend. Das Experiment. Ich habe dich ja ursprünglich gefragt nach einem besonders positiven und besonders negativen Beispiel. Ich habe das Gefühl, das war gerade beides eigentlich.
Nils: Genau, eigentlich war das beides. Wie gesagt, das ist ein intelligent Failure. Also das ist meiner Ansicht nach etwas, was man herbeiführen will. Ja, also obwohl man sozusagen die Grundhypothese, die man hatte, nicht beweisen konnte, trotzdem hat man halt ultra viel über sein Produkt und seine User gelernt. Und ich meine an sich nach, die positiven oder die halt wirklich zu was führen, da sind meine Lieblings eigentlich immer so diese Remove-Experimenter. Also dass man irgendwas aus der Experience rausnimmt und dann halt irgendwie so feststellt, so wow, okay, jetzt ist die Conversion um 30 Prozent, hat sich erhöht. Und da habe ich auch 1000 Beispiele. Sowas ist natürlich auch super nett, ne. Aber ich glaube, so diese Learnings kriegt man halt eher so aus diesen, ich sag mal, fehlgeschlagenen oder intelligent Failures.
Jan: Ja, das ist wirklich auch eine sehr, sehr coole Geschichte, die ich finde, die das sehr, sehr greifbar macht. Aber das, was du gerade nur in der Randnotiz gesagt hast, sollte sich, glaube ich, auch jeder mal abspeichern. Man denkt schnell beim Experimentieren an, ah ja, das brauche ich, wenn ich mal etwas Neues baue. Lass uns mal mehr darüber nachdenken, wann wir Experimente machen, um Sachen rauszuschmeißen.
Nils: Genau, ganz genau, ja.
Jan: Cool. So, zum Abschluss unseres großen Blogs über das Hauptthema Experimentieren im digitalen Produktmanagement. Wir haben ganz schön viele Steine umgedreht. Wir haben über viele Aspekte geredet. Welche Kernaspekte sollte jeder Zuhörer, jede Zuhörerin aus unserem heutigen Gespräch, aus deiner Perspektive mitgenommen haben?
Nils: Das ist eine gute Frage. Ich glaube, das erste ist eben diese Grundvoraussetzung, die wir in ein paar Situationen erwähnt haben. Dass du letztendlich deine Features oder alles, an was du eben arbeitest, so auf den Kern reduzierst. Also dass du halt sagst, was steckt hinter einem bestimmten Wunsch, hinter einem bestimmten Produkt, das ich entwickeln will. Und dass du wirklich auf so eine Hypothese versuchst, herunterzubrechen. Also hypothesenbasiert zu arbeiten. Ich glaube, in dem zweiten Schritt dieser Gedanke von, was braucht es eben als organisationelles Backing? Ja, sodass man eben sagt, psychological safety und diese Unterscheidung zwischen den drei verschiedenen Fehlertypen. Dass du das sozusagen förderst und auch aktiv irgendwie ansprichst als Leader vor allem. Und ich glaube, im dritten Schritt dieses AI-Thema, weil das natürlich auch immer wieder aufkommt, ich glaube diesen Aspekt, den ich angesprochen habe, eben wie interagiert der Mensch mit AI? Was könnten wir dabei vergessen bzw. was sollten wir dabei beachten? Ich glaube, das sind so die drei Hauptthemen, die ich allen Leuten mitgeben würde.
Jan: Cool, vielen Dank. Gibt es, bevor wir jetzt in die schnellen Schlussfragen übergehen, noch ein Thema, das du platzieren möchtest, über das wir aber noch nicht gesprochen haben?
Nils: Ich glaube, wir haben fast alles besprochen. Von daher können wir gerne in die Kurzfragen, in die Lightning-Session gehen.
Jan: Ja, dann machen wir genau das. Also Nummer eins, welches Produkt, digital oder physisch, hat dich zuletzt so richtig begeistert?
Nils: Ja, es ist immer so schwierig. Ich wollte immer, also ich weiß nicht, ob du dieses, dieses Reklam-Notizbuch kennst.
Jan: Nee, kann ich noch nicht erzählen.
Nils: Also ich meine, es gibt ja diese, diese berühmten Reklam-Bücher, diese gelben Bücher, die alle so in der Schule gelesen haben. Und was da eben so besonders faszinierend ist, also dieses Buch ist einfach so ein Notizbuch, ja. Das heißt irgendwie Notizen steht da als Titel drauf. Und gleichzeitig hat dieses Buch den Red Dot Design Award gewonnen irgendwann. So, jetzt hast du folgenden Aspekt. Du hast ein Notizbuch, das hat den Red Dot Design Award genommen. Und wie sieht denn dieser Red Dot Design Award aus? Das ist ein roter Punkt. Das heißt REC, also REC Notizen. Und ein Notiz von RECKLAM. Das ist absolutes Supernova. Und ich glaube, niemand kann jemals ein besseres Produkt erschaffen als das.
Jan: Ich habe es mir gerade schon mal angeguckt hier, das sieht tatsächlich gut aus. Vielleicht bestelle ich mir das gleich.
Nils: Sehr cool.
Jan: Welcher private Bereich deines Lebens wurde am stärksten durch deine Produktarbeit beeinflusst?
Nils: Ich würde sagen, so der sportliche Bereich. Also beziehungsweise dieser generelle Nutrition- und Sportsbereich. Weil ich eben da auch so sehr, also ich sage mal, das klingt immer so blöd, aber dass man eben so auch dort experimentiert und versucht, für sich zu verstehen, ich sage mal auch teilweise banale Aspekte, ja, also ist es besser für mich, wenn ich morgens Sport mache oder abends oder in der Mitte vom Tag, ist es gut, wenn ich irgendwelche bestimmten Produkte esse versus wenn ich sie eben rauslasse, wenn ich sie ersetze. Und ich glaube, da ist es auch so ein bisschen, dass man halt, ja, sich selbst so ein bisschen hinterfragen muss und sich halt immer weiter verbessern will, hypothesenbasiert, ja. Cool.
Jan: Und was war das beste Fachbuch, das du je gelesen hast?
Nils: Wow, das beste Fachbuch, das ich je gelesen habe. Also ich, das hat wahrscheinlich jetzt jeder gesagt, oder? Aber wahrscheinlich ist es halt schon so Continuous Discovery Habits, ne? Es war halt einfach, ja, das hat halt einfach nochmal so alles zusammengefasst, was man eben irgendwie so als moderner Produktmanager braucht. Von daher würde ich schon das nennen.
Jan: Cool. Ja, das hat auf jeden Fall viele Leute beeinflusst. Wir haben es zu einem Eingang des Gesprächs schon angekratzt, aber was ist heute der beste Weg, um ins Produktmanagement einzubrechen?
Nils: Ja, also ich glaube halt, man hat als Produktmanager halt, das ist einfach noch nicht so etabliert. Und du musst da schon ein bisschen, ich sag mal, kreativer sein. Ich glaube, was ich vielen, vielen Leuten so auf den Weg geben würde, ist, du lernst am meisten Produktmanagement halt in möglichst kleinen und jungen Unternehmen. Und in kleinen und jungen Unternehmen ist eigentlich noch gar nicht so sehr etabliert. Das heißt, da ist es auch wert, dass man halt mal eine E-Mail schreibt oder bei LinkedIn jemanden anspricht und sagt, hey, ich habe Lust, das zu machen. Und ich bin interessiert am Produktmanagement. Und dann so sozusagen versucht, sich dem Ganzen zu nähern. Ja, sei es durch ein Praktikum, sei es vielleicht sogar schon durch eine feste Stelle. Also dadurch kommst du halt ziemlich schnell, also kommst du halt am schnellsten sozusagen in diese reine Produktmanagement-Position. Das wäre so meine erste Empfehlung. Die zweite Empfehlung wäre halt so, dass man so ein bisschen in, ich sag mal, nahe ähnliche Berufe kommt. Also man sieht ja zum Beispiel sehr oft so was wie CIO-Manager, was vielleicht so ein bisschen etablierter ist oder was es vielleicht so ein bisschen öfter gibt. Und ich sag halt, hey, bei ganz vielen nennen die das so, aber das ist eigentlich ganz oft Produktmanagement. Und ich glaube, sowas bringt einen halt auch weiter. Und wenn man dann halt auch beim nächsten Arbeitgeber oder bei einem anderen Arbeitgeber auch so ein bisschen erklärt, was hat man da eigentlich in dem vorigen Job gemacht, dann werden richtig gute Produktleute auch verstehen, dass das eigentlich Produktmanagement war. Und dann haben die auch nicht mehr so viel zweifelig, als Produktmanager einzustellen.
Jan: Okay, cool. Und wenn ich einen Productjob gerade gelandet habe, ich habe gerade eine Junior-PM-Stelle bekommen, was sollte ich da berücksichtigen, wenn ich gerade ganz frisch am Einstieg bin?
Nils: Ja, also ich glaube, das ist wie bei allen. Also es unterscheidet sich nicht von, ich sage mal, Experienced-Hiren versus Junior-Hiren. Ich glaube, man muss bei allem erst mal wirklich verstehen, wer sind meine Stakeholder, was ist mein Unternehmen, was muss ich darüber verstehen? Und wirklich diesen Verstehen oder dieses Aufsaugen ganz am Anfang, ich glaube, das unterschätzen ganz viele Leute viel zu sehr. Also ich kann dir nur sagen, bei Zalando habe ich eine große Listening-Tour ganz am Anfang gemacht und also man versteht so ein bisschen, ein bisschen vom Unternehmen, aber es ist wirklich sehr, sehr schwer, gerade bei größeren Unternehmen. Und ich glaube, das sollte am Anfang eher so, das wird am meisten unterschätzt. Man muss das Unternehmen verstehen, man muss den Job verstehen. Und dann kann man so langsam auch verstehen, was macht Sinn an Akzenten, die man setzen kann. Cool.
Jan: Und was ist deiner Ansicht nach wichtig, um langfristig als Produktperson sich immer weiterzuentwickeln?
Nils: Ich glaube, was am wichtigsten ist, sind so diese, was am meisten umsetzbar auch ist, sind so diese Reflektions-Steps. Also ich glaube, wir verlieren uns natürlich immer so in unserem Daily-Doing. Also man kann bei jeder Company als Produktmanager sich komplett treiben lassen und immer wieder also sozusagen Busy-Work machen. Aber ich glaube, so diesen Schritt, dass man mal so ein bisschen seinen Prozess und seine Arbeit so hinterfragt, okay, habe ich jetzt gerade Impact gemacht? Und dann, das ist ja bei den meisten so, dann denkst du manchmal, wow, diese Woche, ich war so gestresst, aber ich habe eigentlich nichts so richtig gemacht, ne? Ich glaube, das ist bei den meisten so. Und ich glaube, das kann man ganz gut sozusagen in seine Habits integrieren, in Form von, dass man einfach die nötige Selbstdisziplin hat, aber natürlich auch durch entsprechende Mittel wie Coaches oder irgendwelche Kurse oder so. Und ich glaube, das, würde ich sagen, ist notwendig für den langfristigen Erfolg, sich immer weiter zu entwickeln, verstehen, wie man mit neuen Dingen umgeht, sowas, ja.
Jan: Das ist auch eine sehr gute Brücke zur vorletzten Frage. Was ist der beste Ratschlag, den du je im Rahmen deiner beruflichen Tätigkeit bekommen hast?
Nils: Hm, ich glaube, das, was ich jetzt schon ein paar Mal gesagt habe, letztendlich, dass es nicht schlimm ist, falsch zu liegen, aber dass es halt problematisch ist, wenn du halt sozusagen wartest oder Sachen delaysst. Ich glaube, die besten Organisationen oder die besten Leader treffen halt sehr, sehr schnell Entscheidungen bzw. haben sehr gut verstanden, welche Entscheidung es wert ist, dass man wartet und welche Entscheidung einfach nur sehr, sehr schnell getroffen werden muss. Und ich glaube, sowas ist so die größte Erkenntnis, die ich so bisher mitgenommen habe.
Jan: Cool. Und dann letzte Frage. Wie glaubst du, wird sich Produktmanagement in den nächsten fünf Jahren verändern?
Nils: Das ist eine sehr gute Frage. Wie wird sich das verändern? Also ich glaube, wir sind ja immer noch an einem Punkt, würde ich sagen, wo das ein sehr, ich sag mal, unstrukturiertes Feld ist. Also Produktmanagement in allen Organisationen, in denen ich bisher war, wurde das vollkommen anders umgesetzt. Also war das ein komplett anderer Job eigentlich. Und ich glaube halt, dass dadurch, dass es einfach viel mehr Ressourcen heutzutage auch gibt und dass es auch viel einfacher ist, sich sozusagen theoretisch in diesen Job einzulesen, dass wir schon sogar noch etablierter werden. Also beispielsweise, also für keinen sollte irgendwie so in fünf Jahren, weiß ich nicht, irgendwie Opportunity Solution Trees oder OKRs oder irgendwie so was, sollte halt was Neues sein, sondern das sind halt einfach Konzepte, die man kennt, die jetzt keine große Erklärung mehr brauchen. Und ich glaube, man kommt dann einfach viel schneller so in einen bestimmten Operations Modus rein. Ich glaube, ich bin da eigentlich ziemlich optimistisch, dass dieser Job sich noch viel mehr etablieren wird, weil man hat so viel zusätzliche Geschwindigkeit durch Tools wie LLMs und so weiter bekommt, dass es halt diese Generalisten mit dem größeren Überblick noch mehr brauchen wird.
Jan: Cool, danke für die Einschätzung. Kann ich mir auch gut vorstellen. Danke für die Einschätzung und auch danke für das Gespräch. Es hat mir sehr, sehr viel Spaß gemacht, mich mit dir auszutauschen.
Nils: Auf jeden Fall. Ich danke dir nochmals für die Einladung. Es ist mir natürlich eine absolute Ehre, nach so großen Product-Leadern hier zu sein. Also vielen Dank nochmal.
Jan: Gerne, gerne. Damit sind wir am Ende dieser Episode. Vielen Dank an Nils Stotz für den spannenden Austausch. Vielen Dank auch an Tim Nippert für das Audio Engineering dieser Episode und für euch ans Zuhören. Eine Schlussbemerkung erlaube ich mir noch. Ich selbst unterstütze Unternehmen und Teams mit freiberuflicher Produktarbeit und biete individuelles Coaching im Produktmanagement an. Wenn ihr oder du Bedarf habt, meldet euch gerne via LinkedIn oder jan@produktkraft.com. Macht's gut.