Hallo und herzlich willkommen zu Ein Geek kommt selten allein, dem Podcast zum Status in der Digitalisierung. Mein Name ist Stephan und gemeinsam mit meinen Gästen mache ich eine Bestandsaufnahme, wohin uns die letzten 40 Jahre Digitalisierung in Deutschland gebracht haben und wie es von hier aus weitergehen kann. Heute geht es um die Entwicklung digitaler Produkte, digitale Projekte und wie man Wert identifizieren und natürlich auch schaffen kann. Da freue ich mich sehr, dass ich mit Ralf Westbrock einen erfahrenen Produktpuzzler an meiner Seite habe. Hallo Stephan, ich freue mich sehr, dass ich heute dabei sein darf und ein wenig mit dir mitgegen darf. Aber jetzt bevor es losgeht und wir in die Thematik abdriften, lass uns nochmal bei dir bleiben, Ralf. Ich habe mir aufgeschrieben, ich wollte dich eigentlich fragen, warum du dich für Produktentwicklung begeisterst. Aber dieser Aufkleber, der mich da so anguckt, Failure is not an Option, ich fürchte, den muss ich thematisieren. Oh mein Gott, ich glaube, jetzt haben wir die nächste Viertelstunde schon belegt, deines Podcasts. Tatsächlich, Failure is not an Option. Ich war in Cape Canaveral, ist das glaube ich, habe diesen Aufkleber gesehen, Failure is not an Option. Es gibt diese berühmte Geschichte der Apollo 13 Mission. Wunderschön verfilmte Doku mit Tom Hanks, der damals auf dem Mond war. Ist das das mit Houston, We Got a Problem? Genau, Houston, Wir haben ein Problem. Und da gibt es halt diesen wunderschönen Moment. Also es geht, also was passiert? Es passiert etwas, was man nicht erwartet hat, wie so oft. Irgendwie, man guckt auf die Instrumente und die Daten, wenn man sie misst. Und dann stellt man fest, oh, da ist ja etwas anders als erwartet. Lohnt sich also immer wieder zu testen, könnte man jetzt schon gleich da ableiten. Und stellt fest, uiuiui, wenn wir so weitermachen wie bisher, dann werden das unsere Astronauten nicht überleben. Abgesehen davon, dass eine Mondlandung jetzt nicht mehr in die Tüte kommt. Und dann gibt es halt diesen wunderschönen Moment, wo halt eben gesagt wird, ja, was passiert denn, wenn wir scheitern? Und die Antwort ist halt eben, ja, scheitern ist einfach für uns nicht vorstellbar. Also Failure is not an option. Dieser Aufkleber, der lag bei mir seit 2006, als ich dort war, eigentlich die ganze Zeit immer schön in der Schublade und der war so riesengroß, also ich sah dann hinter das halbe Laptop-Cover ein und ich habe immer gedacht, ja, wo tue ich den hin? Und dann gab es aber irgendwann zunehmend dieses Fail Early, Fail Often. Und ich habe also tatsächlich bei einem größeren deutschen Unternehmen, das sehr börsennotiert ist, habe ich damals mit dem HR Transition Team gearbeitet an Business Agility. Und da war das auch so ein Claim, Fail Early, Fail Often. Und die haben das total erfolgreich umgesetzt. Die sind sehr viel gefehlt. Genau. Und dann gibt es ja diese Fail Night und dieses Feiern. Und da kommt man so auf ein Grundproblem, das ich sehe, ist, dass wir oft glauben, dass wir aus Fehlern lernen können. Also, Und Variante A, die wir probiert haben, hat nicht funktioniert. Und deswegen glauben wir, das geht allgemein nicht. Und dann ist Variante B wahrscheinlich richtiger. Also das kannst du dir so vorstellen, du fährst mit, also du machst keinen Führerschein, du machst keinen Kurs, steigst in ein Auto ein, legst einen Gang ein, gibst Gas, versuchst zu steuern, fährst gegen eine Wand. Also mit dem Prinzip könntest du jetzt sagen, Autofahren funktioniert nicht. Oder du könntest sagen, Lenkung funktioniert ja nicht oder was auch immer. Also du kannst viele Hypothesen rausmachen. Und das, was ja eigentlich wir wollen, ist ja, dass wir früh scheitern oder früh merken, dass etwas nicht in Ordnung ist. Also wir merken, oh, das wird nicht klappen mit der Mondlandung oder wir merken, der erste Fix, den wir uns überlegt haben, der reicht nicht aus, wir müssen noch mehr tun oder, oh, ist es noch was passiert? Wir nehmen die ganze Zeit Messwerte und die ganze Zeit müssen wir herausarbeiten, was ist eigentlich gerade falsch gelaufen? Also wieso ist das eigentlich passiert? Und ich habe sehr, sehr viel mit verschiedenen Accelerator-Programmen zusammengearbeitet, also mit Startups, die dann Marktmärkte testen, mit Initiativen in größeren Unternehmen, aber auch eben mit ganz normalen Produktteams, das, was man heute so gerne als Product Discovery auch vereinfacht beschreibt. Und da ist es auch dann so, dass es oft so ein naives Testing gibt. Also du sagst zum Beispiel, wir müssen mal gucken, ob sich da jemand für interessiert. Also sagen wir mal, Stephan macht einen neuen Podcast. Dann könnten wir also sagen, okay, wir nehmen mal eine Folge auf, dann laden wir die mal hoch und dann sehen wir ja, ob sich da Leute für interessieren. Das ist so ein bisschen hier Kevin Kostner fällt der Träume Baus und sie werden schon kommen und dann guckt man mal. Wenn da tausend Leute sind, bin ich happy. Genau, We Built It and They Didn't Come ist ja so eine gängige Geschichte. Aber an der Stelle ist halt einfach, du hast noch gar nicht rausgefunden, ob du, Ob sie wirklich da ist, ob sie funktioniert hat, ob Leute überhaupt drauf gestoßen sind, ob der Content nicht richtig war, ob die Länge zu lang war, ob du die falsche Zielgruppe adressiert hast mit deinen Maßnahmen. Und das ist so, wie wenn wir, also wahrscheinlich kann ich ein bisschen so Softwareentwickler-Kontext hier nutzen bei der Digitalkompetenz deiner Hörer. Und das ist ja auch so, wenn wir jetzt also irgendwie eine Gesamtapplikation gebaut haben und wir machen einen sogenannten End-to-End-Test. Also ich probiere mal einmal den wichtigsten Use Case einmal aus, wenn der nicht funktioniert, dann fängt die Arbeit erst an, weil dann muss ich rausfinden, hey, was ist denn da jetzt passiert, an welcher Stelle, in welcher Komponente, welche Dinge haben nicht zusammengespielt, war es ein zeitlicher Sondereffekt oder sonst was und so wie uns da klar ist, dass wir diese Komplexität zerlegen müssen, es ist halt bei diesen Marktseitigungen mit Kundentesten oft sehr, sehr, sehr naiv, also dann wird mit der falschen Zielgruppe getestet und so weiter und so fort. Ach, ich könnte schon wieder übergehen. Boah. Das ist aber so spannend, ich könnte sofort darauf einsteigen, weil gerade, also was mir da in den Kopf kommt, ist ein Ende-zu-Ende-Testen möchte man machen. Und da explodiere ich schon, weil ich mir die Frage stelle, was ist denn das Ende und was ist das andere Ende? Das machst du ja in der Regel, wenn du es selber gebaut hast, alle Enden sind in-house. Also mein QR-Ingenieur kann vielleicht vom Benutzen, vom Anfang gehen bis zum, es spuckt eine Excel-Liste aus oder was immer die Software dann da tun wird. Ja. Aber sobald ich einen Kunden reinbringe, ist das Ende an einer ganz anderen Stelle. Also es ist nicht das Ende des Use Cases, sondern es ist dann auf einmal in einer Organisation, zu einer bestimmten Zeit, wo eine bestimmte Umwelt sich in irgendeiner Form verhält. Und diese Enden sind auf einmal ganz anders. Und ich glaube, das zu unterscheiden und zu sagen, was ist denn jetzt innen passiert, was ist außen passiert, festzustellen, dass wenn ich innen alles in Ordnung habe, habe ich immer noch viele Fragezeichen, weil ich das gar nicht unter Kontrolle habe. Aber wenn ich außen dazu hole, wo die Welt wirr ist und viele Drachen existieren, wo ich ja gar nicht weiß, ob etwas funktionieren kann, auch wenn die Zeit sich verändert. Während der Corona-Pandemie funktioniert Zoom als Aktie super, geht durch die Decke, weil alle sitzen zu Hause. Oder Netflix kriegt viele Abonnenten. Hat Netflix das richtige Produkt gebaut? Weiß man nicht. Während Zoom ja. Aber die Antwort kann nicht sein, immer und Gott gegeben. Also hast du auf einmal eine Umwelt, die da noch mit reinspielt. Und das ist super spannend. Und wir sind eigentlich ja noch mitten in der Vorstellung, aber ich denke jeder wird gehört. Der Anschluss ist schon wieder perfekt. Ich habe auch gerade gedacht, okay, du hast dir eine andere Struktur vorgestellt. Aber die Überschrift ist ja Produkt. Und genau dieses Thema, was ist das Ende? Was wir häufig sehen bei verschiedenen Menschen, die digitale Produkte bauen, ist, dass sie dann tatsächlich sich sehr mit dem Nutzer beschäftigen, wenn wir Glück haben, noch Differenz zwischen Nutzer und Kunde, sich bewusst machen, dass das nicht dasselbe sein muss und wie wichtig das ist. Aber dann zum Beispiel ihre Journeys entlang der eigenen User, also Benutzeroberfläche machen der eigenen User Interfaces und das ist zum Beispiel auch eine ganz spannende Sache zu verstehen mit Ende zu Ende ich bin in einem Kontext, der beginnt weit außerhalb das heißt, das ist jetzt nicht nur die Vermarktungssache also ein schönes Beispiel für mich ist Amazon zum Beispiel natürlich hast du auf der einen Seite die Sache, wie kommst du überhaupt dazu dass die Leute zu dir auf den Shop kommen, aber eben auch, Es hört dann eben nicht auf, wenn du zum Beispiel deinen Checkout gemacht hast. Und da finde ich zum Beispiel ganz, ganz, ganz spannend, wenn du genau diese Betrachtung machst, wie geht die Benutzer-Journey weiter, dann reicht es nicht, dass du sagst, so jetzt habe ich das abgeschickt, sondern dann musst du halt eben rausfinden, ja was passiert denn, wenn jetzt tatsächlich irgendwelche anderen Firmen die Sachen für uns verschicken. Und das kann man ja sehr, sehr schön mit der Schaffung dieser Amazon Locker nachvollziehen, also quasi der auf den Amazon Use Case optimierten Packstation. Wie du dann Probleme identifizieren kannst, die du gar nicht verschuldet hast. Und das ist für mich übrigens auch ein ganz wichtiges Prinzip im Produkt, dass du eine echte Ownership übernimmst und nicht sagst von wegen, das bin ich nicht schuld, das ist nicht mein Problem. Am Ende, wenn dein Dienst deswegen nicht mehr funktioniert, dann ist es egal, was auf dieser Welt das verursacht hat oder wer, dann musst du dich halt eben darum kümmern. Und das ist eben Unternehmertum dann an der Stelle. Absolut, da habe ich eine schöne Anekdote für, weil wir sind kurz nach Weihnachten und zu Weihnachten, also eigentlich für den Advent, habe ich einen Adventskalender geschenkt bekommen. Toller Adventskalender, 24 Teesorten, weil ich gerne Tee trinke. Ich finde Schokolade doof und so, dann hat man halt 24 mal Tee, toll. Dann habe ich die aufgemacht. Beim ersten Tag schon bröckelte der Teebeutel kaputt, während er in der Kanne war. Ein sehr unschönes Erlebnis. Das passierte an weiteren acht Tagen. Es bröckelte einfach der Tee in meine Kanne hinein. Das Ministerhaltbarkeitsdatum war deutlich überschritten von den meisten dieser Tees. Macht nichts, also mir macht das persönlich jetzt gar nichts. Und dann habe ich die angeschrieben. Habe ich gesagt, so Leute, ich recherchiere mal kurz, da steht doch eine E-Mail-Adresse drauf. Wer hat den denn verschickt? Hab den geschrieben. Leute, nur dass ihr es wisst, euer Adventskalender hat meine Standards nicht erfüllt, eure hoffentlich auch nicht. Die T's bröckeln alle weg, ich muss sie alle in extra Sieb tun, damit es nicht total kaputt geht und dieses Mindesthaltbarkeitsdatum ist schon irgendwie komisch. Wie war die Antwort? Der wurde für mich gekauft. Also ich habe ihn nicht selber gekauft, aber ich wurde gefragt, wir machen die nicht selber, schicken Sie mir bitte die Bestellnummer, dann können wir uns drum kümmern. Absolut nicht die Reaktion, die ich erwartet habe. Also zumindest, dass sie sagen, oh, das tut uns leid, wir hätten gedacht, wir hätten einen tollen Adventskalender, haben wir nicht. Gut, dass sie uns das gesagt haben. Natürlich habe ich so ein bisschen an diese, kennst du vielleicht, wenn du bei irgendwelchen FMCGs hinschreibst an Mars und sagst, meine M&Ms waren schlecht, kriegt man 40 Packungen M&Ms geschickt manchmal. Das war jedenfalls vor ein paar Jahren noch so, dass man da zumindest irgendeine Art von Kulanz sieht, war aber nicht. Und da siehst du dieses Ownership-Problem. Also du hast denen halt gesagt, Leute, ihr habt ein Problem mit eurem Produkt. In eurem Namen wird es vertrieben. Und dann sagst du aber, nee, Dropshipping sind wir gar nicht. Da ist irgendeines, oder Lieferant macht ein Riesenproblem. Genau, genau, genau. Da krankt es dann, wenn du sagst, du hörst Lieferung bis Bordsteinkante, hörst eben auf, Aftercare ist mir egal, go to market, wir machen große Launchparty, wir laden Silicon Valley Style alle ein und sagen toll, wir sind jetzt im App Store oder so. Aber danach sind es die Sterne egal, die wir da kriegen und wir kümmern uns auch nicht um nichts. Ich glaube, wir dürfen es auch nicht zu schwarz-weiß malen. Es gibt ja auch immer Grenzfälle. Ich habe gerade zum Beispiel ein Erlebnis mit, wir kaufen ein Auto. Ach so, wir springen weiter in das Format noch kurz. Selbstverständlich. Okay, danke, danke, danke. Also immer, wenn mir was passiert, was schief geht, dann frage ich mich ja immer, machen die das mit Absicht? Weil wann auch immer wir irgendwie Produkte geführt haben oder führen, dann wissen wir, manchmal gibt es einfach diese Momente, da ... Da kannst du es nicht finanzieren. Also auch wenn wir uns wünschen würden, dass es zu jedem Zeitpunkt immer den perfekten Service, die perfekte Markenrepräsentanz und so weiter gibt, gibt es einfach Ausnahmefälle. Und ich frage mich gerade, ob ich genau so ein Sonderszenario habe. Also Geschichte ist, wir kaufen ein Auto. Mein VW-Campingbus hat gerade einen Motorschaden. Ich habe mich nun schweren Herzens entschieden, dass ich mich von ihm trennen werde. Und jetzt habe ich da einen Campingbus stehen mit ausgebautem Motor, der schon eine echte seniorin geworden ist die gute und wie verkaufen mit wenig zeit so also wir kaufen ein auto preis genannt bekommen alles klar dass. Eine webseite oder jemand der die so ein kärtchen an die. Webseite total super also kann es vielleicht vom riech um es kann es vielleicht momox also irgendwann sozusagen einer der erfinder des riech um es mit dem christian wegner ganz ganz tolles Business. Die haben den einfachen Fall, du hast irgendwie sowas wie Medien, kannst rausfinden ungefähr, was gerade die Verkaufspreise sind, wie gut die drehen in bestimmten Shops und so weiter. Und bei Autos, da hast du ja ein bisschen ein anderes Spiel, du musst irgendwie abschätzen, was ist tatsächlich das heute auf dem Markt noch wert, hast du dann viel Expertise und so weiter. Du nimmst dann die Stackeliste oder sowas als Ausgangspunkt und dann guckst du nochmal so ein bisschen nördlich oder südlich. Und verkaufst auch selber, also hast dann wieder da die Verkaufsseite mit dabei und so weiter und musst dann halt Zustand schnell bewerten und hast da relativ schnell gute Heuristiken, was du wofür bekommst. Und jetzt gibt es aber halt diese Sonderfälle, Campingbus zum Beispiel mit Motorschaden. So, und das haben die jetzt auch noch mit dabei. Und jetzt, seitdem ich da aber halt diesen Preis genannt bekommen habe, habe ich ein paar Fragen. Zum Beispiel, hey, ich habe da so einen Ersatzmotor gehabt. Der wurde jetzt angeschaut, weil da war eventuell noch Gewährleistung drauf. Soll ich den wieder einbauen? Macht wahrscheinlich keinen Sinn, weil wenn den dann jemand repariert, muss er ihn ausbauen. Ist ja irgendwie Verschwendung. Soll ich den überhaupt noch zurückschicken lassen oder sollen die den gleich irgendwie zerlegen und entsorgen? Und solche Dinge. Und dann kannst du sagen, hey, Rückruf vereinbaren. Dann habe ich dann gemacht dreimal. Tolle UI, wie man sie kennt, wie man sich das wünscht. Ich mache eine Zeit und einen Termin und dann werde ich angerufen. Hat alles funktioniert, bis auf ich werde angerufen. Dann gibt es keine E-Mail-Adresse, dann gibt es eine Telefonnummer, da rufst du dann an und bist irgendwie 20 Minuten in der Warteschleife. Also die wollen nicht telefonieren. Also fahre ich zur Filiale und sage, hier, ich habe mal noch eine Frage wegen des Motors. Und telefonisch war niemand erreichbar. Können Sie mir dazu was sagen? Dann sagt der zu mir, Ja, sie konnten zwar hier die Filiale als Abgabeort wählen, das habe ich verstanden, aber sie würden wir gleich wieder wegschicken, weil hier die Einfahrt ist so eng, da kann gar kein Sattelschlepper zum Autotransport drauf, deswegen werden sie dann wieder weggeschickt. Wo ich dann denke, okay, das wäre doof gewesen mit so einem kaputten Auto auf dem Transporter und dann ans andere Ende von München müssen. Dann sage ich, ja, haben sie denn eine Telefonnummer für mich? Nee, wir haben alle keine Telefone. Also Geschäftsmodell ist klar gestreamlined, du willst nicht, dass zu viele Leute diskutieren und nachverhandeln und so weiter, aber sie können mein Problem nicht lösen und dann denke ich so, okay, also entweder haben die ganz klare Metriken und ich bin da einfach ein Sonderfall, hab Pech gehabt oder…, irgendwas funktioniert da gerade echt nicht bei denen und die haben dann auch schon so diesen elitären Status ein bisschen verloren. Oder es ist einfach egal bei dem, was sie an Umsatz machen, ich weiß es nicht. Funktioniert ja wohl sehr gut das Geschäft. Ich bin mir nicht sicher, aber ich würde jetzt mich weiter so ein Fett zerlehnen und sagen, das machen die nicht extra, um dich zu ärgern. Nee, persönlich nehme ich das auf gar keinen Fall. Das machen die bei mehreren. Also und tatsächlich, ich will gar nicht schlecht, also ich finde immer noch diese Geschäftsidee finde ich super. Da gab es ja auch mehrere Anläufe davon. Wir in München hatten Easy Auto Sales, Das waren die späteren Cluno-Gründer. Also tolle Gründungsinitiativen, tolle Businesses, die da aufgebaut wurden. Ich finde es fabelhaft, dass solche Dinge eben auch in Deutschland gehen und so hoch skalieren. Aber natürlich merkst du dann auch irgendwann, hast du das Gefühl, die degradieren dann so ein bisschen an einigen Stellen. Und das ist vielleicht gerade so ein Moment. Damit haben wir ja zwei Fälle gefunden, die relativ konkret sind und wo wir ein bisschen Potenzial hatten, wo wir Raum für Verbesserung sehen. Hast du irgendwas, und wir tauchen jetzt mal langsam ins Thema ab, hast du irgendwas, wo du sagst, das ist eigentlich ein gutes Zeichen, so sollte digitale Produktentwicklung funktionieren? Gibt es da im deutschsprachigen Raum irgendjemanden oder irgendein Produkt, wo du sagst, das könnte man mal nehmen und sagen, es ist gut gelaufen? Ja, ich glaube, es gibt tatsächlich viele Sichtfenster, wo man immer wieder sagen kann, da gab es eine richtig gute Zeit. Also meine Erfahrung ist, dass Organisationen da nicht stabil sind. Also du kannst sagen, bei der Firma XY war ich, die haben eine agile Transformation gefahren zum Beispiel und haben Produktmanagement genauso aufgebaut, wie man es tun sollte. Und dann kann es einen Inhaberwechsel geben oder Management-Teamwechsel und es kann sich alles wieder verändern. Deswegen aus der Vergangenheit, ich weiß, dass die Scout-Gruppe, da habe ich mit einem Teil der Scout-Gruppe sehr eng gearbeitet, dass wir 2013 dort zum Beispiel direkt am Geschäftsmodell orientiert mit KPA Drivertree damals schon Hypothesen getriebene Entwicklung gemacht haben. Das heißt, ich kann es mir so vorstellen, jede Story im Backlog wurde abgeschätzt. Auf welche KPI zahlt sie ein? Und du wusstest halt genau, wenn du zum Beispiel, im Dating gibt es so ein paar einfache Regeln, wie zum Beispiel, wenn du die Chat-Aktivität erhöhen kannst, dann tatsächlich bleibt die Retention hoch und dann hast du auch höhere Abo-Abschlüsse. Also hast direkt einen Einflusstreiber auf den Umsatz. Und die waren da sehr, sehr weit schon. Und dann haben wir halt eben wirklich dafür gesorgt, dass tatsächlich jede Story im Backlog vereinfacht gesagt diesbezüglich bewertet wurde und dann frühzeitig getestet wurde. Das heißt, erst mal mit Mockups, möglichst direkt an die betroffene Zielgruppe, also nicht mit irgendwelchen Kollegen oder im Biergarten, losgehen und genau herausfinden, okay, verstehen die das? Wie reagieren die darauf? Das heißt, du fragst nicht, wie findest du das? Und du sagst, okay, wir haben hier eine Variante skizziert. Versuch doch mal irgendwie das, also was würdest du normalerweise an dieser Stelle tun Oder erinnerst du dich, was du getan hast in den letzten Tagen? Versuch das mal zu tun. Simulierst dann halt wirklich mit Papier zum Beispiel genau die Aktivität, die da drin war. Dann kannst du halt sehr, sehr viel darüber lernen. Funktioniert das besser? Ist das verständlicher? Die neue Idee, die du drin hast, wird dir verstanden oder wird dir nicht verstanden, was du gerade testen willst? Und kannst das eben alles machen, bevor du da tatsächlich Software draus baust. Oder du hast zum Beispiel eine konkrete Idee, die wir damals hatten, war angelehnt von einer Airbnb-Story, auf die wir gestoßen waren. Airbnb hatte damals die Erfahrung gemacht, dass die Vermietungen hochgegangen sind, wenn die Fotos der Räumlichkeiten besser werden. Also wenn du die Wohnung wertiger darstellen kannst und besser erklärst, wie schön das da ausschaut, dann tatsächlich gehen auch die Buchungsdaten hoch. Und da haben wir gedacht, vielleicht funktioniert das ja auch im Dating, ist ja eine coole Sache. Also könnten wir hingehen und könnten sagen, komm, wir machen mal hier irgendwie kostenlose Profi-Shootings und dann geht ja vielleicht die Matching-Aktivität hoch. Und da haben wir einen sehr viel einfacheren Weg gewählt damals oder hat das Team einen einfacheren Weg gefunden. Und zwar haben die einfach ihre Data Scientists genommen und haben gesagt, lass uns doch mal in die Daten reinschauen. Und dann haben sie einfach mal 100 zufällig gewählte Profile genommen und haben mal, also kann man natürlich alles methodisch dann diskutieren, aber aus unserer Sicht war das damals zulässig, die Bilder einfach mal zu ranken, nach wie qualitativ sind die denn. Also eher nach handwerklichen, nicht nach geschmacklichen Dingen. Genau. Nach dem Thema, würde ein Fotograf so ein Ergebnis erzielen oder ist das quasi so lässig locker aus der Hand mit einem schlechten Gerät geschossen. Und haben dann halt das zugeordnet und dann tatsächlich danach erst die Aktivität geprüft. Und dann haben sie halt zwei Dinge festgestellt. Zum einen, also die Qualität des Fotos spielt weniger eine Rolle. Und Nummer zwei, dass es halt aber ganz andere Heuristiken zu geben scheint, die zum Beispiel so etwas sind, dass wenn ein männlicher Teilnehmer auf der Plattform, ich sage auf der Plattform, weil Dating-Plattformen natürlich immer unterschiedliche Segmente bedienen, auch wenn die das oft gar nicht merken. Und dass halt auf der Plattform es so war, dass Männer vor allen Dingen Status symbolisieren müssen. Es war dann tatsächlich so ein bisschen enttäuschend. Ansprechen. Also dass du irgendwie Sicherheit und Geborgenheit und finanzielle Stärke, das heißt es war gut, wenn du dich mit einem dicken Auto oder vor deinem eigenen Haus oder vor deiner Yacht hast. Wie damals war der Spaß, mein Haus, mein Auto, mein Boot, wenn die mit auf Fotos sind, ist das eine gute Sache, wenn du alleine irgendwie auf der Wiese stehst, womöglich nicht ganz so ziehen. Ja, also es war interessant damals und ich hoffe, dass die Welt sich da ein bisschen weiterentwickelt hat, weil wir natürlich alle andere Ideale haben. Aber das war damals halt ein wesentlicher Treiber und da haben wir halt dann herausgefolgert, okay, es ist eigentlich nicht zu erwarten. Du kannst natürlich immer noch dann so einen Lucky Shot probieren, manchmal geht das ja auch gut. Aber zu dem Zeitpunkt gab es für uns halt eben keinen Anlass zu glauben, dass das fortgeführt werden sollte und war halt sehr, sehr günstig verprobt. Auch an der Stelle ganz wichtig, ohne den Einsatz von Development-Kapazität in der sogenannten Delivery dann, weil dort ist es ja dann so, dass du den Code eben nicht mal kurz baust, sondern dann baust du den ja idealerweise so, dass er halt skaliert, dass er performant ist, dass er wartbar ist, dass er schnell released werden kann und, und, und, und, und, und, also all diese Qualitätsmerkmale. Und das ist natürlich eine sehr teure Aktivität. Deswegen in der sogenannten Discovery wollen wir vorher mal rausfinden, Nummer eins, ne? Also... Würden denn tatsächlich unsere Kunden positiv darauf reagieren? Also schaffen wir für die einen Wert, sodass sie tatsächlich auch noch stärker bereit sind, etwas dafür zu geben? Monetarisierung oder ähnliches. Und Nummer zwei, dann können wir das halt eben schaffen und wird das für unser Business insgesamt funktionieren. Das ist natürlich eine ganz spannende Sache, das zu machen, bevor du es baust und nicht erst hinterher. Um noch kurz das Beispiel abzuschließen, also was funktioniert denn auch? Die Geschichte war dann tatsächlich mit der Discovery nicht beendet, sondern dort ist es tatsächlich auch so gewesen, dass dann nach der Delivery, also wenn das dann live war, erst mal tatsächlich im A-B-Testing auf einer kleineren Minderheit, also damals war, ich glaube pro Woche waren da locker 100.000 Leute durchgegangen. Und da war es halt so, dass du sehr, sehr, sehr, sehr schnell einfach im AB-Testing gucken konntest. Erstens, erreichen wir denn auch auf Produktion die Ziele, die wir erreichen wollten und was ich auch häufig sehe, dass das verpasst wird, haben wir einen negativen Einfluss durch Seiteneffekte auf andere KPIs und das ist dann wieder so ein Punkt, wo man sagen kann, okay, das ist ein Fail, aber jetzt wird es spannend, weil dann hörst du halt nicht auf, sondern jetzt geht es halt los, okay, wenn ich das Ziel nicht erreicht habe, glaube ich, dass ich das nachschärfen kann. Also wir sind ja oft mit in time, in quality, in budget. Aber Produktentwicklung ist für mich immer mehr das Bild der Verzinsung. Also es kommt nicht darauf an, von wegen was ist der Betrag, den du ausgibst so sehr. Also spare ich jetzt 100 Euro oder spare ich 110 Euro im Monat? Wenn ich darauf schaue, dann schaue ich auf die falsche Zahl. Denn eigentlich jedes Mal, wenn ich eine Conversion verbessere in meinem Driver Tree, dann ist das so wie der Zins, das ist Zinseffekt. Also es ist egal, ob das einen Monat früher oder später kommt. Weil die Verzinsung über die Jahre an der Stelle einfach so massiv wirkt, dass das viel, viel wichtiger ist als alles andere. Und deswegen ist eben wichtig, dass wir noch danach messen und nicht mit einem Shot probieren, schaffen wir das oder schaffen wir das nicht, sondern eigentlich mehr darauf schauen, wie kann das hebeln, wenn wir es schaffen und, Bis dahin, also dann gebe ich mir halt eine Startrampe, sage ich halt okay, ich habe dafür maximal, keine Ahnung, zwei Monate Zeit oder so, aber in diesen zwei Monaten, Failure is not an option. Wenn die Zeit abläuft, okay, dann explodiert unsere Apollo 13 Kapsel, Pech gehabt, hoffentlich keine Astronauten an Bord, aber bis dahin versuchen wir einfach, weil dieses Ziel, wenn wir es erreichen können, ist das so ein großer Hebel, dass wir bis dahin alles dafür tun und einen Scheitern tatsächlich für nicht möglich halten. Das ist natürlich so ein interessanter, ich weiß nicht, ob das schon so ein Reality-Distortion-Field ist, dass du also wirklich eine Zeit lang bewusst ignorierst, möglichst, wenn es nicht klappt und sagst, dann probieren wir es halt nochmal anders, dann probieren wir es halt nochmal anders. Das muss gehen, wir müssen dieses Puzzle lösen. Deswegen mag ich auch dieses Bild des Puzzles so gerne. Wenn das dann eben erfolgreich gelaufen ist, dann ist alles gut. Schlimm ist halt eben, wenn es nicht klappt und du dann sagst, okay, wir haben jetzt alles gegeben und jetzt lassen wir es aber los. Irgendwann brauchst du deinen Exit. Ich versuche mal so ein ganz kleines bisschen zu strukturieren, dass wir versuchen, so eine Art roten Faden zu entwickeln, weil wir könnten über alles reden. Also einmal durch den Garten galoppieren, ist gar kein Problem. Es ist ein sehr spannendes Thema insgesamt. Ich finde, du hattest dieses In-Time, In-Quality, In-Budget schon erwähnt und da klingelt natürlich bei jedem sofort die Glocke, das ist ja klassisches Projektmanagement. Du machst ein Projekt und wir haben alle festgestellt, Projekte, in vielen Fällen sind die nicht so erfolgreich, wie man sie eigentlich haben möchte. Gerade wenn die lang dauern, so eine Elbphilharmonie oder andere Themen, irgendwas passiert immer auf dem Weg. Und wir haben ja jetzt vor Ewigkeiten irgendwo in irgendeinem Ski-Resort haben sich ein paar Leute zusammengeschlossen, die haben mal so ein agiles Manifest gebastelt und daraus ist irgendwie Scrum gekommen. Aber diejenigen waren ja eigentlich lieferverantwortliche Menschen oder liefernahe Menschen, die dann gesagt haben, wir sehen, die Projekte laufen nicht so richtig gut, irgendwas müsste man mal machen. Und haben dann das ganze Agile reingebracht. Ich glaube, wir haben so ein hartes. Schwergewicht auf so einer Mach-Projekte irgendwie besser. besser, also optimiere dieses Dreieck mit in Time, in Quality, in Budget. Es hat aber niemals diese Puzzle-Perspektive so richtig reingebracht. Und ich sehe so in den letzten Jahren kippt das so ein bisschen, dass man feststellt, dass man nicht immer IT-Projekte macht, wo man dann sagt, wir wollen folgendes bauen, wir führen ein CRM ein, und zwar mit Ellbogen und allem, was dazugehört. Sondern jetzt stellt man fest, auf dem Weg lernen wir vielleicht viele Sachen dazu, die wir gerne einfließen lassen würden. Und dafür braucht es eine etwas andere Denke, als einem Projektmanager den Auftrag zu geben, keep the scope, keep the time, keep the budget. Das funktioniert so dann nicht mehr. Und da ist, glaube ich, der Switch, dass du halt aus dem Lieferkeller, aus der Lieferverantwortung über die Wasseroberfläche mit dem Kopf nochmal kommst und dich orientierst. Macht das überhaupt noch Sinn, mich abzustrampeln in diese Richtung? Oder möchte ich vielleicht doch die Richtung so ein bisschen korrigieren? Denn da ist für mich immer so ein, also ich benutze immer gerne die Worte Geschwindigkeit und Richtung. Andere Leute sagen Effizienz und Effektivität oder du könntest sagen Können und Wollen. Wenn du in die falsche Richtung rennst, ist es genauso doof, wie einfach nur stehen zu bleiben oder vielleicht sogar viel, viel schlimmer, weil du irgendwo hinkommst, wo du gar nicht sein möchtest. Du hast Leute verbrannt auf einem Weg, die eigentlich dachten, du hast eine gute Mission und es ist so wahnsinnig wichtig, diese Kursnachsteuerungen in das System einzubauen und nicht zu sagen, ich bin sehr schlau und jetzt laufen wir mit meiner Idee bitte los und am Ende bleibt diese Idee. Selbst solche Steve Jobs Messias Themen haben ja nicht so funktioniert. Er hat ja nicht am Anfang sich eine Sache überlegt, 20 Jahre gebaut und dann ist er genau da angekommen, sondern das ist ja das. Was auch bei Startups, wir machen das Feld ganz breit, ich mache momentan Startup-Beratung, wo ganz viele Startupper denken, meine Idee ist jetzt das Ding, das darf ich mit keinem teilen und ich ziehe die durch und dann bin ich Milliardär. Nee, bist du nicht, weil diese Idee ändert sich auf dem Weg und es muss nochmal verdaut werden, es muss überlegt werden, du musst nicht unbedingt ein Pivot machen, aber du musst schon mal überlegen, die neuen Erkenntnisse, die ich habe, ändert das irgendetwas in dem, was ich tue. Netflix, die erst DVDs verschicken und dann irgendwie streamen und dann Stranger Things drehen und dann Content-Produzent werden, ist ja was ganz anderes als das, was sie vorher gemacht haben. Einfach Blockbuster-Konkurrenz zu machen, weil die jetzt einen Briefmarker auf die Höhle kleben können. Okay, jetzt kann ich das Kompliment zurückgeben. Jetzt hast du eine ganz schöne Palette von Themen hingelegt, lieber Stephan. Lass es uns breit machen. Wo sollen wir anfangen? Also ich glaube, zwei Dinge, die du genannt hast. Das eine war die Agilität und Und das Zweite darin, was du gesagt hast, war ja die Richtung und die Effizienz. Also was ich immer mag und wenn wir jetzt mal auf Scrum, wenn wir das mal rausgreifen, dann glaube ich, dass wir dort, also dort unterscheide ich immer, also der Product Owner zum Beispiel, der hat halt die Verantwortung, dass das Richtige getan wird. Und das Team hat die Verantwortung, dass die Dinge richtig getan werden. Also was wird entwickelt versus wie entwickeln wir es? Wie sorgen wir dafür, dass das dann richtig umgesetzt wird? Ich glaube ganz wichtig, keine Exklusivität. Man darf auf gar keinen Fall in den Tanzbereich des anderen reinreden. Ich glaube. Es ist schon wichtig. Dass die quasi so ein bisschen semipermeabel sind, dass man miteinander reden kann. Aber ich finde diesen Fokus so wichtig zu sagen, Einer hat diesen Hut auf und sorgt dafür, dass das richtig getan wird und soll den anderen auch beraten und sagen, so ist es nicht. Aber dass das Missverständnis nicht kommt, jeder macht seins, bitte bleibt auseinander. Ganz wichtiger Punkt. Also tatsächlich, wir haben, ja, von Höcksken auf Stöcksken sagt man glaube ich hier in Westfalen, kommt es ja schnell von einem aufs andere. Also da kommt ja das nächste Dilemma. Also die Begrifflichkeit Produkt ist ja schon schwach definiert oder anders. Wir sind ja in der VUCA-Welt und das heißt, wir haben natürlich Ambiguity. Das liegt auch daran, weil Begrifflichkeiten dieselben Wörter benutzen für unterschiedliche Kontexte. Das heißt, wenn wir zum Beispiel auf den Product Owner schauen und in der Scrum-Welt, dann so wie ich das erlebt habe, muss ich dazu sagen, weil es gibt auch andere, die haben das anders erlebt dann schon, aber zu der Zeit, als ich damit zu tun hatte, ging es halt bei Scrum allgemein um Softwareentwicklung. Ja, das heißt also, wenn ich irgendwie, keine Ahnung, einen Badge-Job gebaut habe, der Daten im Format A in Daten in ein Format B wandelt, dann war das eine klar definierte Aufgabe und das war halt ein gültiges Software-Projekt. Da würde ich nicht unbedingt sagen, dass das jetzt ein Produkt ist, das man dann danach versucht zu vermarkten. Aber das Produkt einer Softwareentwicklung kommt daraus. Und der Product Owner eben als Idee, ich habe jemanden, der gegenüber dem Team als Vertreter der Anforderungen steht. Und da beginnt dann zum einen dieses Dilemma um, was heißt Produkt? Produkt, weil wenn ich von Produkt spreche oder wenn du auf eine Konferenz fährst wie Mind the Product oder so, dann geht es halt darum, dass es vor allen Dingen darum geht, Produkte vor allem am Markt, wo du mit dem Risiko zu tun hast, dass du etwas baust, das dann entweder eine Million Mal gekauft wird und du kannst sagen, okay. Jetzt baue ich mir so einen schönen Palast hin, wie dieser Stadtteil da in der Nähe von Heidelberg von SAP mit der riesengroßen Marmorkugel und dergleichen. Oder du hast halt, Auf der anderen Seite Produkt im Verständnis von egal, was wir mit Software entwickeln, wenn da irgendwie fünf Experten zusammensitzen und Software basteln, am Schluss kommt ein Softwareprodukt dabei raus als Ergebnis des Prozesses. Genau. Das ist dann ja quasi dasselbe Wort wie Inkrement, man sagt statt Inkrement Produkt, aber ich glaube vom Setting her, sehr viel wurde ja Agile oder auch Scrum gegen Wasserfall gestellt und da merkst du sehr, sehr schnell, das ist kein Produktentwicklungsframework, das ist ein Projektframework. Du kannst es halt für beides benutzen. Jetzt haben wir halt dieses Dilemma, dass wenn wir über Produkt sprechen, dass oft Menschen miteinander sprechen und der eine spricht halt über die Herausforderung Produkt und befasst sich halt damit, was muss ich denn tun, damit ich das baue, was meine Kunden da draußen am Markt auch wirklich kaufen wollen. Und der andere sagt, was muss ich denn tun, damit tatsächlich das gebaut wird, was sie eigentlich will, das gebaut wird. Und natürlich hat der erstere das zweite Problem auch. Also es gehört immer zusammen. Aber da haben wir einfach Begrifflichkeitsherausforderungen. Und in der agilen Welt ist es natürlich so, dass jetzt auch das Positive ist, dass ganz, ganz viele von den Werkzeugen, die wir verwenden, um dann Produkte am Markt zu validieren, auch ganz hervorragend benutzt werden können für interne sogenannte Produkte. Also etwas, was wir dann zum Beispiel für interne Nutzergruppen bauen, wo wir in der Vergangenheit einfach nur gesagt hätten, Du musst halt Anforderungsmanagement machen. Ja. Es gibt einen Requirements Engineer, der arbeitet länger und dann schreibt er ein langes Dokument, dann wissen wir, was wir tun sollen. Das ist ja in dem agilen Kontext, eigentlich möchtest du ja Risiko rausnehmen, indem du sagst, ich weiß, die Welt ist irgendwie anders, als ich es mir vorstelle. Da ist Risiko. Welches Risiko adressiere ich? Wie kann ich das denn validieren? Dieses Hypothesen getriebene, was du schon gesagt hast. Wie kann ich es schaffen, Sicherheit in meine Business-Entscheidungen hereinzubekommen? Und darüber schweigen sich ja viele der Dokumentationen aus. Also es gibt ja den ominösen Scrum Guide mit 26 Seiten, sehr viel zu lesen. Und der spricht nicht über, ich nenne es immer gerne, Links vom Backlog. Also die Welt beginnt im Backlog. Wenn schon klar ist, was man tun möchte, dann darf man nochmal Fragen stellen, ob das überhaupt das Richtige ist. Aber niemand hilft dir die Frage zu klären, woher weiß ich denn, was ich in die Maschine, die hoffentlich gut geölt und effizient arbeitet, reinstecke, um welches Ziel zu erreichen. Auch das ist ja noch die Frage. Es ist ja nicht definiert. Wenn jemand sagt, baue mal ein neues Produkt, was willst du machen? Möchtest du mehr Names haben? Also wenn wir nicht über B2C denken, sondern wir denken jetzt an B2B. Möchtest du mehr benannte Kunden haben? Möchtest du ein Land erschließen? Möchtest du viel Umsatz generieren? Was möchtest du erreichen dadurch? Durch und wenn dann noch verschiedene Gruppen innerhalb des Unternehmens verschiedene Ziele damit verbinden, hast du nicht nur diese Ambiguität im Begriff, sondern auch noch in den Ideen und in der Bewertung, sodass für manche das ein erfolgreiches Produkt ist, die anderen sagen, was ist das für eine Todgeburt, das hilft ja überhaupt nicht. Da drin dann abzuschichten, da braucht es glaube ich jemanden und das ist vermeintlich ja auch der Product Owner oft, der sagt, ich nehme das Heft in die Hand, ich sage mal, wo dieses Schiffchen jetzt hinfährt, wir bauen folgendes, der so ein bisschen eine Vision, eine Strategie, irgendwas. Transportieren hilft, damit man, Buzzwords kommen hier ganz viele, kannst gleich Bingo sagen, Alignment schafft. Damit die Leute wirklich in dieselbe Richtung gehen, nicht nur innerhalb des Entwicklungsteams. Volle Zustimmung, ja. Sondern darüber hinaus. An der Stelle muss ich allerdings sagen, ich bin mir jetzt nicht sicher, ob du gesagt hast, du vermisst da was bei Scrum. Also nämlich, dass das tatsächlich sich damit beschäftigt, wie man denn die richtigen Dinge auswählt. Fachlich oder für den Markt oder ähnliches. Denn eigentlich finde ich es ganz passend, dass es nicht drin steht, denn Denn Scrum sagt ja auch nicht, wie ich als Softwareentwickler Software bauen muss. Das sagt ja auch nicht, guck mal, das ist der Styleguide, den du machen sollst. Das sind die Bibliotheken, die du verwendest. Und genauso ist es halt so, wie du dann halt eben die Kompetenz brauchst, um jetzt Software zu bauen. Also grundsätzlich mal Code zu schreiben oder zu testen oder Data Science zu betreiben oder ähnliches. Genauso ist es halt so, dass du natürlich auch auf der anderen Seite Handwerksmittel haben musst, um tatsächlich rauszufinden zum Beispiel, was Kunden denn tatsächlich benötigen. Oder wie du Kunden segmentierst oder ähnliches, wie du eine Strategie dazu aufbaust. Auch das kann man alles lernen, aber ich glaube, Safe versucht das so ein bisschen immer mehr davon da in das System reinzuwerfen. Zumindest fühlt es sich so an, dass man irgendwie Product hinterherläuft und versucht das zu lernen. Und das wird auch besser an der Stelle, muss man auch sagen. Aber eigentlich, denke ich, macht es Sinn, dass das in dem Framework erstmal nicht drin ist, weil es ist beantwortbar. Auf der anderen Seite gleichzeitig, und jetzt kommt das Spannende, wenn wir auf sowas wie Lean Startup schauen, was ja nichts anderes ist als ein testgetriebenes Vorgehen beim Aufbau von Geschäftsmodellen, ist leider…. Das ist ein unfassbar schlecht gewählter Begriff gewesen, weil viele denken dann, guck mal, es geht um unterfinanzierte kleine Unternehmen und wie die vorgehen. Gerade in Deutschland denkt man an die unterfinanzierten. Und deswegen tatsächlich mit Kunden, mit denen ich gearbeitet habe, haben wir es dann oft auch umbenannt und haben es dann agile Geschäftsmodellentwicklung genannt. Weil das ist eigentlich genau das. Also die Grundidee ist halt wie bei Agile, dass du halt sagst, guck mal, ich sage nicht, das ist der Plan, den ich habe, wie mein Geschäftsmodell aussieht und jetzt renne ich los. Groß und dann nach drei Jahren tausche ich meinen CEO aus und dann zwei Jahre später muss ich dann irgendwie meine komplette Sales-Mannschaft rauswerfen oder ähnliches, sondern du sagst halt auch, okay, das hier ist der Plan, den wir haben und den machen wir mal explizit und dann machen wir tatsächlich ein cross-funktionales, übergreifendes Team, das an diesem Geschäftsmodell arbeitet. Und wir machen halt auch Iterationen. Wir setzen uns Ziele, indem wir halt zum Beispiel bestimmte Kennzahlen auf diesem Geschäftsmodell dann tatsächlich erreichen wollen, indem wir anfangen, den Channel langsam aufzubauen, den Channel zu testen. Also das heißt, wie werden überhaupt Kunden auf uns aufmerksam? Wie können sie rausfinden, ob das für sie das Richtige ist und so weiter und so fort. Und dieses Geschäftsmodell halt auch in Iteration messgetrieben mit Feedback-Zyklen, die klassischen Elemente von Agile, dann immer wieder schaust, geht es in die richtige Richtung, gleichzeitig Retrospektiven in diesem Team machst, funktioniert das alles, was wir zusammen machen, passen die Systeme zusammen, ist die Kommunikation ausreichend, was auch immer, wie geht es uns allen dabei und da kannst du halt eben ganz genau, wie du Software entwickelst, kannst du halt auch dieses Gesamtsystem aufbauen und weil du gesagt hast, arbeiten mit Startups, also da ist das ein absolut absolut phänomenales Vorgehensmodell, gerade wenn du halt sagst am Anfang, okay, erzähl mir nicht, was dein Produkt ist, sondern versuch mal, mir zu erklären, wer genau sind die Leute, die das brauchen und was tun die denn heute? Und dann kommst du halt ganz, ganz schnell darauf, dass die Situation, in der die heute sind und wie die heute versuchen, das zu lösen oder warum sie es nicht versuchen zu lösen, dass das schon mit die wichtigsten Segmente sind, wie du halt ein Thema adressierst. Damit haben wir schon einen... Aus meiner Sicht einen mega wichtigen Bereich rausgearbeitet. Also es gibt einmal diese Doppeldeutigkeit in dem Produktbegriff, also dass du es einmal verstehen kannst, als eigentlich ist es auch nur das Inkrement und das, was ich hinten rausmache. Oder du kannst es umfassender betrachten. Es klingt jetzt sehr wertend, aber ich glaube, es ist größer als nur ein Inkrement. Nämlich, was ist mein Business-Modell, was mein Geschäft, was dahinter steckt. Du kannst mehrere davon haben, kannst mehr Produkte als eins haben in deinem Portfolio. Aber ich glaube, das ist es, wenn du mit dem Mindset herantrittst und sagst, eigentlich ist die Produktdenke etwas, die soll die Projektdenke ersetzen. Ist es der Holzweg, weil das tut es nicht. Sondern die Produktdenke gibt eine neue Dimension, gibt einen neuen Kontext, indem du deine Projektdenke hast, weil du machst ja weiterhin kleine Projekte, um Dinge rauszufinden. Das heißt, eine Projektdenke aufgeben ist das Falsche, aber erweitern um die Komponente mit, jetzt überlege ich, was möchte ich mit meinem Business machen, da kommen dann diese KPI-Themen, OKRs, was nicht alles rein, wo du sagst, ich möchte jetzt über mein effizientes Abwickeln eines Projektes hinausgehen. Und ich glaube, dass viele Menschen tatsächlich da so einen kleinen Disconnect haben, wenn sie miteinander sprechen, weil manche meinen den einen Teil mit dem Inkrement, manche meinen den Teil mit, oh, ich liefere jetzt ein neues Businessmodell, ich probiere was aus, wird der Kunde es akzeptieren, funktioniert das mit unseren Supportstrukturen, die wir haben, haben wir eigentlich die richtigen Channel-Partner, die das mit in den Markt bringen können. Und dadurch, dass du auf diesen unterschiedlichen Flughöhen bist, ist so ein bisschen hier dieses Apollo 13 Thema, was du da am Anfang gebracht hast, das ist wie wenn zwei Teams arbeiten, die einen rechnen in Metern, metrisch, die anderen in Fuß und die treffen sich halt nicht so ganz, weil die was anderes meinen und ich glaube es ist wichtig, dass man zumindest sehr explizit macht, worüber reden wir hier eigentlich? Ist es für uns Teil eines neuen Business, was wir erschließen wollen oder Teil generell eines Business oder ist es Eigentlich ist alles klar, das muss man nur bauen. Das alte ERP wird irgendwie abgelöst, weil es weg muss. Und wir müssen halt das Neue machen. Es geht gar nicht darum, was Neues herauszufinden. Hier geht es nur darum, eins zu eins ein Teilchen anderes zu ersetzen. Also das Spannende zwischen diesen Projekt- und Produktstrukturen ist, dass du sie mit hoher Wahrscheinlichkeit in jedem Unternehmen langfristig parallel finden wirst. Was mir gerade so in den Kopf schießt, ist einer der Kunden, mit denen ich gerade arbeite, die jetzt also mehrfach sehr erfolgreich für eine große deutsche produzierende Marke eine Lösung B2B implementiert haben. Lösung heißt in dem Fall mehrfach ein Projekt umgesetzt, also im selben Aufgabenbereich. Und jetzt ist die Frage, wie können wir ein Produkt daraus machen? Dann geht es natürlich auch los. Okay, was ist denn die Situation der Kunden am Markt? Wie seht ihr denn die verschiedenen Segmente und so weiter? Okay. Dort ist zum Beispiel für mich momentan zu erwarten, dass es zwar einen Kern gibt, der ein Produkt wird, wo also die Arbeit tatsächlich in diesem Bereich Discovery ist, wo eine Standardkomponente stehen wird oder mehrere Standardkomponenten, die dann also selber Innovationstreiber sind, wo du dann die Erwartungen hast, die du als Firma eben auch an ein Produkt hast. Dass es also kontinuierliche Verbesserungen gibt, dass Fehler bereinigt werden, dass das tatsächlich von vielen verwendet wird, dass damit auch unterschiedliche Best Practices da einfließen, dass tatsächlich die Wertschöpfung dadurch ansteigt und so weiter. Und gleichzeitig erwarte ich, dass die als Anbieter in eine Situation kommen, dass sie immer wieder Integrationsprojekte drumherum haben, weil in ihrem Zielsegment sehr historisch gewachsene Strukturen sind mit sehr heterogenen Landschaften. Und jetzt stellen wir uns mal vor, diese Produkteinheit, die wird in einer Discovery funktionieren. Die muss rausfinden, wo ist der nächste Schritt, den wir tun müssen, um zum einen unsere stärksten Segmente glücklich zu halten, aber zum zweiten auch, wie du es bei Netflix vorhin angedeutet hast, wie können wir denn wachsen? Also welche zusätzlichen Geschäftsfelder können wir öffnen, aber auch welche neuen Kundengruppen können wir erschließen für diese Lösung? Und das ist aber eine grundsätzlich andere Arbeitsweise, als wenn du dir jetzt vorstellst, du bist in diesem Team, das halt die Integration macht oder die Projekte, dann ist die wichtigste Kundenfrage, wann geht's los? Wann ist es fertig? Was kostet's? Das ist dann von vornherein die Frage und das heißt, es sind auch die Kennzahlen, die dich steuern. Da kannst du halt nicht sagen, ja, wir machen mal die Discovery und das Wichtigste ist, dass wir die und die Conversion an der und der Stelle erreichen, sondern dann ist halt einfach die Erwartung, dass es eine bewältigbare und abschätzbare Größe ist. Ein bisschen kannst du vielleicht noch da Puffer reinrechnen und so weiter, aber du bist grundsätzlich in der anderen Arbeitsmodus. Es ist nicht das Wichtigste, dort rauszufinden, wo wird dieser Kunde in fünf Jahren stehen, in drei Jahren oder wie bewegt sich die Branche, sondern du musst ihm jetzt beschreiben, wie auf seine jetzige Situation du genau herausarbeitest, wie sie aussieht. Und das Gute ist ja auch, du kannst das herausarbeiten. Also während unser Produktteam jetzt etwas baut für Kunden, die dann sich später herausstellen wird, ob sie ihre Kunden sind und bei denen es halt sehr viel abschätzen muss und die Zukunft vorliegt. Prognostizieren oder deuten muss aus dem, was gerade passiert, kann halt dieses Team natürlich auch sehr viel genauer sich zusammensetzen mit der Zielgruppe, das rausfinden und genau das rausarbeiten. Und damit hast du grundsätzlich unterschiedliche Aufgabenstellungen. Die Werkzeuge in den beiden Teams sind dann wiederum ganz viele ganz gleich. Du wirst auch so eine Art Produkt-Trio haben, also jemand, der tatsächlich für die Business-Seite sorgt, dass es sowohl den Deckungsbeitrag sichert oder das Investment irgendwie sinnvoll ist, wie auch, dass der Scope passt. Du wirst jemanden von UX haben, der sicherstellt, dass das tatsächlich verstanden wird und als nützlich empfunden wird und im Idealfall auch Freude macht, ja, zu benutzen. Und du wirst natürlich ein Tech Lead haben, der dann an der Stelle er oder sie dafür sorgt, dass das eben umsetzbar ist und dass halt das in Time, in Quality, at Scale, wie auch immer, was es da noch alles an Anforderungen gibt, dann geliefert werden kann und betrieben Ja. Das ist ja die Dreierheiligkeit sozusagen aus der Produktwelt eher, wo wir sagen, es ist die Feasibility, also das ist der Mensch mit dem Geld, der sagt, es lohnt sich das zu bauen, die Viability, der sagt, das kann man auch bauen und die Desirability, wo jemand sagt, das möchte auch jemand tatsächlich haben. Ja, genau. Und ich mag es noch tatsächlich, wenn ich dann Richtung Marty Kagan gucke, der da tatsächlich diese vier Uncertainties hat, der dann also die Desirability nochmal unterscheidet zwischen, du hast ein Value Risk, also empfinde ich das tatsächlich als wertvoll, will ich das haben? Ganz einfach gesagt, will ich das haben, also brauche ich das? Und dann auf der anderen Seite, kann ich das nutzen? Also du kennst das irgendwie, du siehst auf Kickstarter eine tolle Sache und dann denkst du, du willst das haben und dann kommst du dir nach Hause und schätzt, es ist unbenutzbar. Du warst bei mir zu Hause offensichtlich schon. Ich habe ein paar Kickstarter-Sünden hinter mir. Die haben jetzt ein paar Begriffe schon gedroppt, wo ich nicht weiß, ob jeder damit was anfangen kann. Ich benutze die auch regelmäßig einfach so. Wir haben ja auch darüber gesprochen über Discoveries und Deliveries und dergleichen. Und wenn wir jetzt mal sagen, wir kommen so aus einer klassischen Welt, Menschen kennen Scrum und die wissen, da gibt es einen Sprint und da baut man irgendetwas. Wie passen jetzt Delivery und Discovery rein? Wie würdest du die definieren? Also es gibt ja so eine fachliche Definition. Oder fangen wir mal an. Die meisten Scrum-Teams, die erleben das so, da kommt ein Backlog ums Eck. Vielleicht hat man vorher schon gegroomt oder vielleicht hat auch... Das darf man nicht mehr sagen, es heißt Refinement. Entschuldigung, Refined. Was auch immer man damit gemacht hat. Auf jeden Fall, man hat irgendwie schon vorgearbeitet, aber irgendwann geht es dann in den Sprint und ab dem Moment, wo das im Sprint drin ist, sind wir definitiv in der Delivery. Da geht es dann darum, dieses Investment zu tun, im wahrsten Sinne des Wortes. Also dann wird umgesetzt und so weiter. Die Discovery, die würde jetzt, ich glaube, Marty Kang jetzt hat mal so formuliert, dass er gesagt hat, eigentlich wollen wir den Backlog validieren, bevor er umgesetzt wird. Also genau diese vier Risiken rausnehmen. Also das ist tatsächlich, du hast es vorhin schon gesagt, viable, desirable und feasible. Du hast halt diese unterschiedlichen Risiken und du kannst natürlich schon weiter vorher anfangen. Du kannst natürlich eigentlich anfangen mit der Frage, okay, wo beginnt, also anders, wenn du in einem Scrum Team drin bist, frag dich mal, woher diese ganzen Themen kommen und wie die Entscheidung gefällt wird. Und die Discovery ist eigentlich der Versuch oder ist eigentlich die Mission, dass du die besten Entscheidungen dafür fällst, was reinkommt. Das ist eigentlich diese ganze Kunst rund um die Discovery und da haben sich halt, ja jetzt, wann war das, Kagan Buch 2009, ich glaube damit hat es angefangen oder 2011, ich bin mir jetzt gar nicht ganz sicher, die erste Version, da ging es halt zum ersten Mal darum zu sagen, okay, guck mal, wir müssen tatsächlich uns zum einen damit beschäftigen, welche Fragen stellen wir auf, also wie identifizieren wir, welche Kunden, die gerade die wichtigsten sind und wie identifizieren wir, was dort am meisten hebelt, Für die und für uns. Und es wurde zum ersten Mal darüber oder ganz klar in Verbindung gebracht für die Masse der Produktmenschen in der digitalen Welt, dass es halt diese Symbiose gibt aus. Du hast einen Kundenwert, den du schaffst, also Wert für einen Kunden. Das heißt, der erkennt, wenn ich das Produkt nutze, dann verbessert sich mein Alltag, mein Leben, mein Glücksgefühl, was auch immer so, dass es signifikant ist und dass ich das jetzt verändern will. Und dass du das sozusagen als Basisspannung brauchst auf deinem Motor namens Geschäftsmodell, damit du den so weit in den Schwung kriegst, dass du dann am Schluss damit Geld verdienst oder was auch immer das Ziel ist deines Geschäftsmodells. Da gibt es ja auch Non-Profit-Geschäftsmodelle und ähnliche. Ja. Discovery ist nicht der Teil, womit es anfängt. Eigentlich müsste man ja vorher schon irgendeine Art von Überlegung haben und mich interessiert jetzt, was steht eigentlich am Anfang, also was will man discoveren, weil du kannst ja alles discoveren über die Welt und du musst ja so ein bisschen den Fokus setzen, damit du nicht irgendetwas herausfindest, was natürlich dann den Rückbezug nicht hat. Und die Frage ist, steht eigentlich die Idee am Anfang oder sollte der Markt am Anfang stehen oder sollten Nutzer oder gar Kunden am Anfang stehen? Was ist der Input für eine Discovery? Okay, jetzt sagen wir eigentlich nicht mehr, was ist der Input für die Discovery, sondern was ist der Ausgangspunkt von einer Strategie. Da sind wir jetzt eigentlich mit der Frage, okay, in welche Richtung wollen wir uns jetzt eigentlich insgesamt bewegen. Und genau mit dem, was ich gesagt habe, du willst dein Geschäftsmodell in irgendeiner Form entwickeln. Sagen wir mal, wie es häufig so ist, dass du profitabel sein möchtest und oder dabei wachsen möchtest, dann suchst du ja, also Wachstum oder auch Profitabilität heißt ja vor allen Dingen auch immer, welche Kunden kann ich bedienen oder kann ich zusätzlich bedienen. Und das heißt, dass der wichtigste Punkt von allem, also natürlich kann sein, dass du eine technische Innovationsidee hast und dann dazu etwas findest, aber der typischerweise stärkste Treiber ist, dass du erkennst, dass irgendwo ein Markt oder ein Kundensegment, also typischerweise eine Gruppe von Kunden, in einer Situation ist, in der sie eine Chance verpassen oder ein Problem haben, das signifikant ist, oder irgendein Bedürfnis, das sie haben. Es gibt dieses schöne Begriff, underserved ist, also unterversorgt ist. Und das ist ein schöner Moment. Also du kannst dir so vorstellen, das hat wahrscheinlich jeder schon mal erlebt, du sprichst irgendwie mit Leuten und dann merkst du, hey, so wie die das machen, das ist aber echt teuer. Das kostet irgendwie viele Personen, das kostet viel Zeit oder das generiert immer wieder Qualitätsprobleme und damit dann in der Folge auch wieder Zeit und Geld, das verloren geht. und dann fällt dir auf, dafür gibt es eine Lösung. Du hast eine Idee, wie man das machen könnte, so dass es in Zukunft nicht mehr passiert. Also man könnte zum Beispiel sagen, guck mal, hier gibt es Leute, die machen so und so Projekte und merken erst nach zwölf Monaten, dass das Produkt floppt, was sie an den Markt bringen wollten. Die sollten mal agil arbeiten. Oder hey, Informationsfluss rund um Digital Business in Deutschland ist schlecht, da sollte man mal einen Podcast machen mit mindestens einem Geek, der vielleicht noch Gäste dabei hat. Da kannst du so verschiedene Ideen haben. Aber auf jeden Fall, jetzt hast du eine Lösung und hast ein Problem, kannst sagen, wie du die Leute erkennst, die das Problem haben. Das ist ja schon der Anfang einer Strategie. Jetzt hast du also hier eine Potenzialgruppe, du hast eine Lösung und kannst sagen, die brauchen in etwa im Schnitt brauchen die sieben bis acht Personen, die das ganze Jahr mit einem Monatsgehalt von, keine Ahnung, brutto sieben arbeiten. Das kann man doch irgendwie effizienter machen. Dann können die an was anderem arbeiten, weil die haben ja alle zu wenig Leute. Und damit hast du dein erstes Segment. Und jetzt steht das im Wettbewerb zu anderen Ideen. Das ist idealerweise das, wie du deine Strategie aufbaust. Wenn du zum Beispiel ein Produkt machst, dann sagst du, das ist meine Produktidee. Und dann überlegst du dir die Segmente, in welchen Ausgangssituationen sind die. Und dann machst du wie so eine Art Fahrplan. Also Roadmap könnte man fast sagen von, na, guck mal, wir fahren dahin, dann können wir das Kundensegment bedienen, dann können wir das Kundensegment bedienen, dann das oder das. Stärker binden oder stärker durchdringen oder ähnliches. Genau, und dann bist du halt natürlich in der Strategie. Und diese Strategie würde dann natürlich hilfreicherweise die Discovery so ein bisschen führen. Aber das ist tatsächlich nicht immer gegeben. Also während das ja jetzt so klar klingt, nach meiner Erfahrung ist aus irgendeinem mir nicht erschließbaren Grund für Menschen unendlich schwierig, einfach mal zu potenziellen Kunden zu gehen und zu sagen, können wir uns bitte mal erklären, wie ihr das heute macht. Wir würden gerne dazulernen und wir haben da ein paar Ideen und danach würden wir euch gerne vorstellen, was wir denken, wo da Ansatzpunkte sind. Also stell dir vor, es kommt jemand zu dir und sagt, Stephan, dein Podcast, geile Idee. Lass mich doch mal einmal schauen, wie du das planst, wie du das releast und wie du dein Content strukturierst. Und ich will das nur erklärt bekommen und danach würde ich dir mal erklären, wie wir dafür sorgen, dass es die 20-fache Reichweite hat. In dem Augenblick wärst du interessiert, den Leuten das vorzustellen. Aber aus irgendeinem Grund ist es extrem schwierig, das zu tun. Also es ist tatsächlich eines meiner Standardportfolio-Elemente. Hey, guck mal, wir können das machen. Und in dem Augenblick, wo Menschen so ein Business starten, dann gibt es einmal diesen Effekt, du hast schon 3000 Mal erzählt, wieso das erfolgreich wird. Dann glaubst du das, dann glaubst du nicht, dass du noch auf Überraschungen stößt, bis du dann auf Überraschungen stößt. Und dann ist es halt oft spät. Und das heißt ganz häufig Leute, die darauf ansprechen, sind Leute, die schon beim ersten Versuch mal eine große Überraschung hatten oder wo es nicht mehr funktioniert. Aber das ist zum Beispiel eine der einfachsten Sachen, um auf diese Strategie zu kommen. Trotzdem passiert es häufig nicht. Und das heißt, der Effekt, den wir häufig haben, ist, dass wir Teams haben, die gerne Discovery machen würden und jetzt sagen, ja, was ist denn unsere Strategie? Da kann man erst mal sagen, locker bleiben. Denn tatsächlich, wenn du Strategie oder wenn du deine Discovery wieder umgekehrt damit anfängst, dass du sagst, lass uns doch mal kontinuierlich mit Kunden in Kontakt treten, dann hast du automatisch einen Hebel. Also es gab von Meetup vor Ewigkeiten, ich glaube zehn Jahre oder länger her, gab es einen schönen Artikel, Five Days to Validation. Das war das erste Mal, dass ich das gelesen habe. Die haben damals in New York, wo natürlich viel Laufkundschaft auf der Straße ist, haben die halt einfach gesagt, hey, jeden Donnerstag machen wir uns Customer Testing Day. Und das heißt, egal welche Idee wir haben, wir sorgen dafür, dass wir donnerstags Leute da haben, aus unserer Nutzergruppe, aus beiden, also sowohl Organisatoren wie auch Teilnehmer. Und wir sorgen dafür, dass sie da sind. Und unsere Produktleute, die können einfach mit allen Hypothesen, mit allen Experimenten, die sie haben, wo sie mit Menschen sprechen dürfen, also den qualitativen Teil des Testings zu machen, da können sie sagen, hey, we have a maximum of five days to validation. Dation. Also spätestens Donnerstag sind die Leute da. Der vierte Tag ist ja Testtag. Ich kenne das. Hasso Plattner, glaube ich, hat mit Design ein bisschen was zu tun. Und es ist dann der Google Design Sprint, der dann natürlich auch Ja. Wobei es geht schon darüber hinaus. Ich finde das ganz interessant. Der Design Sprint wird oft so als Holy Grail irgendwie dargestellt. Und wenn wir aber von Product Discovery sprechen, dann meinen wir eigentlich Continuous Product Discovery. Absolut. Und ich habe 2020 bis 2022 in einem Verlag zum Beispiel geholfen, aus dem Printprodukt ein Digitalangebot zu machen. Und eine der ersten Sachen, die ich halt sofort dort etabliert habe, ist, dass wir halt kontinuierlich mit Kunden in Kontakt waren. Das heißt, wir haben in unserer gesamten Nutzerkommunikation immer einen Absatz, hey, gefällt dir das Produkt oder hast du Feedback für uns? Ja, hier kannst du einen Termin buchen. Und dann sind die halt über eine Buchungsseite, konnten die sich halt eintragen und dann haben wir halt kontinuierlich in den Spätnachmittagsstunden dann halt mit Abonnenten des bestehenden Angebots oder auch Nutzern des Digitalangebots gesprochen, haben das immer wieder in die Marketingkampagnen integriert und haben so dafür gesorgt, dass wir halt dazu wöchentlich dann tatsächlich mehrere Leute einfach zum Gespräch da hatten und kontinuierlich, testen konnten. Und womit hat es angefangen? Es hat damit angefangen, erstmal rauszufinden. Warum hast du heute das Abo? Was machst du mit dem Ding? Was machst du noch? Also auch da wieder, nicht nur, ich schaue auf mein Produkt, sondern auch den ganzen Kontext. Wie kommt es überhaupt, also da ging es um Sprachenlernen, wie kommt es überhaupt, dass du dich mit der Sprache beschäftigst? Hast du da Ziele? Was hast du noch gemacht? Und jetzt sind wir wieder bei Wert. Wenn du dann also tatsächlich darüber sprichst, oh, wir sind uns aber nicht sicher, ob wir sieben Euro pro Monat für eine App nehmen können. Und dann erzählen dir die Leute, was sie gerade dafür ausgeben, um jemanden zu treffen irgendwo und bei einem Abendbrot oder bei einem Dinner dann tatsächlich in der Sprache sich ein bisschen zu üben mit Amateuren und Ähnliches. Und du kriegst mal mit, welches Ausgabeverhalten ist da. Dann kriegst du plötzlich eine andere Wertbemessung. Und so kannst du halt super, super schnell, sehr, sehr einfach, noch bevor du dein Angebot hast, schon viele, viele Leitplanken für das rausarbeiten, was du dort in nächster Zeit machst. Und deswegen, auch wenn ich keine Strategie habe oder wenn ich... Kann ja auch mal vorkommen, dass ich der Strategie nicht so ganz vertraue oder dass eine Strategie da ist, aber andere Features gerade auch noch gemacht werden müssen. Es ist immer richtig, die Zielgruppe zu treffen, möglichst nah an dem, was ich bauen will. Also idealerweise die, die das hinterher auch vermutlich nutzen werden. Und dann immer erstmal rauszuarbeiten, okay, was ist eigentlich die Ausgangssituation, bevor ich dann hingehe und sage, guck mal, ich habe ein paar Mockups mitgebracht. Erstmal muss ich wissen, warum würde die Person das überhaupt tun wollen. Also was tut ihr heute? In diesem Value-Teil stellt sich natürlich die Frage, woher finde ich denn raus, was wertvoll ist? Wie nähe ich mich dem? Featuren nähern ist total einfach, weil das kennst du ja auch, wenn man irgendjemandem eine Idee sagt und du zeigst jemandem, was du schon gebaut hast, sagen die, oh, du könntest auch Folgendes noch machen, du könntest auch Folgendes noch machen. Und ich denke mir dann immer, ja, das könnte ich machen, aber würde es irgendjemand benutzen, dass es technisch geht, fasziniert mich total. Aber das ist wie diese Jurassic Park Zitat. Du musst halt überlegen, wo kommt der Wert her? Hast du eine Antwort darauf? Es gibt diesen schlecht übersetzbaren Begriff der Problem Validation. Ich glaube, inzwischen sind wir vom Problem Space sprachlich schon weitergekommen auf den Opportunity Space. Aber das ist ein spannender Skill, der zum einen Dinge möglich macht, die vorher nicht so zugänglich waren und gleichzeitig in der falschen Situation eingebracht dafür sorgen kann, dass Teams komplett verloren gehen. Also vielleicht erstmal, wann sollte ich damit vorsichtig sein? Stell dir vor, du bist ein B2B-Unternehmen. Du bietest vielleicht eine Software an, die die Dokumentenbearbeitung in einer bestimmten Form macht oder sehr formale Dinge und du hast neue Regularien und jetzt ist das Wichtigste, dass du dafür sorgst, dass das alles compliant ist und natürlich solltest du auch dann in der Discovery mit Kunden testen. Dann bist du sehr lösungsgetrieben, weil es ist schon gesetzt, was du tun sollst. Wenn es so ist, dass du vielleicht in einem Bereich bist, wo einfach nur das, was heute nicht digital gemacht wird, in Zukunft digital gemacht werden soll, das eins zu eins übertragen keinen Sinn macht, dann macht es viel mehr Sinn, erstmal zu sagen, okay, erzähl mal mal die Situation oder kennst du die Situation, dass du vor folgender Aufgabenstellung stehst. Oder dass, keine Ahnung, irgendein Trigger kennst du, kennst einen Kontext und einen Trigger, der typischerweise dafür sorgt, dass eine bestimmte Aktivität gemacht wird. Und dann sagst du einfach, okay, erzähl mir das mal, so eine Situation, erzähl mir mal die gesamte Geschichte. Und gehst dann in einen Interviewmodus, wo du tatsächlich so ein bisschen wie so ein Dokumentarfilmer dir vorstellst, du willst jetzt komplett das Ding durchdrehen. Das heißt, die Person fängt an zu erzählen und du gehst immer weiter mit Nachfragen rein, dir die Details erzählen zu lassen. Und du stellst nicht gezielt Fragen nach dem Wert oder ähnliches, sondern du guckst, wann tauchen Emotionen auf. Du guckst, was generiert Aufwände. Du guckst nach, wo entstehen Qualitätsprobleme. Also die üblichen Nachteile, die in dieser Lösung da sind und in dieser Journey des Problemlösens oder Aufgabeerledigens. und umgekehrt suchst du, schaust du dann, okay, was sind so positive Momente. Also kannst du zum Beispiel vorstellen, du willst Apotheke digitalisieren. Und dann könntest du jetzt sagen, okay, das ist blöd, ich bin eh schon krank und jetzt soll ich vor die Tür gehen. Ich bin doch eh schon matt. Ich soll im Bett bleiben, aber jetzt muss ich zur Apotheke gehen. Wen treffe ich an der Apotheke? Zig andere Leute, die krank sind. Eieieiei. Wäre doch schön, wenn ich das nach Hause bekomme gleichzeitig. Okay, kann sein, dass du das ein bisschen deinen Kreislauf anstupst. Kann aber auch sein, dass du einfach da nochmal jemand aus der Nachbarschaft triffst, zufällig ins Gespräch kommst und die Person dann vielleicht sogar das mitbekommt, dass du krank bist und dir anbietet, die Einkäufe zu erledigen. Also was auch immer. Das können ja total zufällige Dinge sein. Und jetzt ist halt das Spannende, wenn du das halt erzählt bekommst, dann findest du halt zum einen diese Pains, die da sind, also die Nachteile. Kannst also danach gucken, hey, wie könnten wir das denn irgendwie auflösen? Was sind denn tatsächlich die Pains? Also da ist auch spannend, wenn Leute sich über was aufregen, Emotionen zeigen, ist das später immer gut für Kampagnen. Also damit kriegst du die Aufmerksamkeit wieder. Aber das heißt nicht, dass du das Feature brauchst, sondern das kann sein, dass das mal kurz als Ventil benutzt wird, die Leute sich darüber beschweren. Spannend ist immer, wenn du die die Frage stellst, hast du mal versucht, das zu ändern? Also entweder gibt es tatsächlich einen verständlichen Grund, warum es überhaupt nicht änderbar ist, aber in vielen Fällen, wenn du mitkriegst, okay, es wurde nicht versucht zu ändern, dann brauchst du auch nicht zu erwarten, dass jemand bereit wäre, ein neues Produkt zu benutzen, zum Beispiel. Also das heißt, du kannst da sehr, sehr viel machen, kannst methodisch geschickt fragen und es gibt halt da sehr, sehr viel, Möglichkeiten von Interviewtechnik, Auswertetechnik und so weiter, um dann halt genau diese Muster zu identifizieren, aus denen du dann tatsächlich Wert schöpfen kannst für die Kunden und damit damit auch für dich dann Business aufbauen kannst. Ich bin großer Fan von Jobs to be done versus Tools to be used, weil der Ansatz einfach ein schöner ist. Und da hatte ich auch mal einen sehr augenöffnenden Moment, weil du bist ja immer sehr eingefahren. Du denkst ja an deine Lösung. Du willst jetzt eine App bauen für Leute, damit die mit der App irgendetwas erledigen können. Und wenn du dann überlegst und fragst, wie nutzt ihr das denn heute? Und die sagen dann Excel oder ich mache das auf einen Zettel. Und du merkst dann, es gibt einen Kontext, in dem du dich bewegst. Also die werden ja niemals diesen einen Job des ich muss zur Apotheke nicht zustandslos, wie du schon sagst. Also ich muss ja auch nochmal irgendwann an die frische Luft oder aber ich muss zur Apotheke nicht nur, wenn ich gerade todkrank bin, sondern auch zu anderen Zeiten. Und dann habe ich den Job trotzdem bei der Apotheke etwas abzuholen und zu überlegen, was sind die Szenarien, was sind die Werkzeuge, mit denen man das macht, was sind die Alternativen und wir hatten das, nee genau, es war beim Business Model Canvas, als wir den mal ausgefüllt haben, dann hast du ja auch immer ein Feld, wo du deine Competitors hast und dann war es glaube ich eine BI-Lösung und dann wurden alle BI-Lösungen hingeschrieben. Aber eigentlich der Competitor war Excel an der Stelle. Sich selber bauen und es ist nicht so, du verlierst das, weil ein anderer Anbieter das bauen darf, sondern weil die Leute das mit Visual Basic einfach in Excel sich selber machen. Und da zu verstehen, wo kommen die Leute eigentlich her und was wollen sie erreichen. Bei dem Sprachenbeispiel vielleicht schön, ich möchte in meinem Urlaub eine Paella bestellen können. Muss ich dafür die Sprache lernen? Kann ich so einen Babelfisch mitnehmen? Also ich habe ja verschiedenste Varianten oder ich lese aus meinem Buch einfach die Phrase vor, weil ich die zehn wichtigsten Phrasen habe und kann das klein aufbauen und kann gucken, wo ich den Wert schaffe. und damit bin ich wieder bei diesem Business-Aspekt, wo du sagst, was ist das Business, was verkaufe ich, muss ich denen eine App verkaufen? Und wir haben das Hammer-Problem, sobald wir das Software-Team da hinsetzen, haben wir den Hammer und das Problem muss doch ein Nagel sein. Es kann nicht anders gelösen. Das ist richtig, also genau, ganz wichtiger Punkt. Also bevor du tatsächlich, also dieses Klassische, ich baue schon mal mein Software-Team auf und dann danach fange ich an mit der Validierung. Das kann natürlich verpasste Chancen geben, sagen wir mal. Ich habe das auch erlebt, du hast da so Unzufriedenheit, weil die Engineers würden gerne was bauen und das finde ich auch gut und dann musst du aber sagen, ja wartet noch kurz, wir sind uns noch nicht so ganz sicher, wir müssten noch mal ein bisschen was überlegen und dann erzeugt es so einen Druck und es gibt eine Eigendynamik, dass du gar nicht mehr frei über den Wert nachdenken kannst und auf einmal bist du in so einer Lieferfalle und dann so ein bisschen Sankt-Cost-Fallacy passiert irgendwann, du hast ja schon investiert, du hast dann vielleicht schon was getan, dann machst du da auch mal weiter, und bist gar nicht mehr frei davor und löst eigentlich ein strategisches Problem, was mehr oder weniger evident ist vielleicht. Und da sich daraus zu befreien und jemanden zu haben, der sagt, ich denke, dass als Produkt und meine Verantwortung ist es, den Wert bei denen, die dafür Geld ausgeben, zu schaffen. Vielleicht Wert bei den Nutzern, das finde ich übrigens auch ein Thema, was ich sehr, sehr spannend finde. Wer kauft ein und wer nutzt? Und wir haben ja mit UX auch eine starke Rolle, die sich auf den Nutzer fokussiert, aber ultimativ kümmerst du dich ja auch darum, wer kauft es denn? Natürlich. Aber das ist ja die essentielle Produktrolle. Genau, und da kann man sich nicht darauf verlassen und sagen, UX kümmert sich schon, weil die kümmern sich nicht um den, der es kauft. Die kümmern sich, wenn das die Personalunion ist, auch um den, der es kauft, aber in einer anderen Rolle. Ja, ich glaube, die kümmern sich nicht. Also es gehört nicht oder... Also nicht der harte Fokus. Genau, also es ist nicht originär der Teil der UX. Es gibt allerdings zum Beispiel auch bei UX, kenne ich diese Dreifaltigkeit von useful, usable, delightful. Dann ist useful im Prinzip das, was wir als Business Value oder als Value für den Kunden verstehen würden. Also du brauchst es überhaupt nicht, kannst es benutzen und macht es dir Freude. Also momentan siehst du ja ganz häufig, dass Menschen in ihren Rollen unterschiedlich noch Seitenthemen mitbelegen. Also du triffst irgendwie Produktmanager, die coden können. Du triffst Coder, die irgendwie gleichzeitig UX-Experten sind. Du triffst UXler, die einen Teil von Produktkompetenz schon mit dazu belegen und so weiter. Deswegen dieses Schwarz-Weiß. Also letzten Endes drei Kompetenzen, die du brauchst und das möglichst gut entwickelt. Was glaube ich tatsächlich. Immer noch irgendwie schwach entwickelt ist, ist diese Kombination von Digitalkompetenz und Business Model Expertise. Also, dass ich wirklich in einem Geschäftsmodell denke und dass ich in Go-To-Market schon denke. Also, wenn wir zum Beispiel jetzt über diese Interviews sprechen, dann bin ich bei dir an ganz vielen Stellen, wo dann die Design- oder UX-Agentur irgendwie Interviews mit Nutzern führt. Dann sagen die, wer ist auf unserer Webseite unterwegs? Die nimmt man dann irgendwie in Interviews und dann fragt man die irgendwie, warum sind die da und ähnliches. und wo ich dann drauf schaue und sage so, ja okay, das hilft uns jetzt nur begrenzt, weil erstmal müssen wir in Segmenten denken. Das heißt, es ist nicht die Frage, wer war zufällig da, sondern wie kommen wir an die Segmente ran, und dann müssen wir erstmal rausfinden, was wollen die denn eigentlich tun, was sind alternative Lösungen, das können Webwerbe oder Workarounds sein oder auch einfach, die haben nichts getan, weil es ist nicht irgendwie so wichtig, dass sie es überhaupt lösen wollen. Alles schlechte Nachrichten für uns vielleicht. Und dann, wie du es auch richtig sagst, alles, was ich an Lösungen finde, wo ich nicht eine komplexe Software bauen muss, ist für mich ja auch eine gute Nachricht eigentlich. Außer auch das, wenn du jetzt also irgendwie schon eine Development-Mannschaft da stehen hast, das habe ich tatsächlich bei meiner Zeit bei einem großen deutschen Finanzdienstleister gehabt, dass ich gesagt habe, hey, wir müssen jetzt erstmal hier ein bisschen Validierung machen, also ein bisschen Validierung machen, also den Research nachholen und wir müssen erstmal genau herausarbeiten, was wir brauchen. Und da hat mir damals tatsächlich mein Quasi-Chef gesagt, also der Thought-Leader sozusagen im Unternehmen, der hat halt gesagt, hey, pass auf, wenn du jetzt dein Development hier vier Wochen ignorierst, dann wirst du danach ein innenpolitisches Problem haben, verlass dich drauf, mach das lieber nicht. Und da habe ich gesagt, ach Quatsch, das ist ja alles so rational erklärbar. Nach zwei Wochen habe ich aber gemerkt, oh, okay, jetzt habe ich gerade die Sensoren ausgefahren, tatsächlich das passiert. Also da kann ich nur sagen, okay, für bestehende Produkte, du hast immer Dinge, die wichtig zu tun sind. Also gerade wenn das etablierte Sachen sind, auch wenn du gut mit Technical Adapt umgehst und so weiter. Es gibt immer diese Möglichkeit, Themen zu adressieren, die dem Team die Welt leichter machen oder dem Service oder sonst jemandem. Es gibt immer was, was du irgendwie aufräumen kannst. Und das sind dann oft für mich gut kombinierbare Sachen. Also inzwischen, wenn ich dann merke, okay, wir haben hier irgendwo festgestellt, wir haben noch ein Verständnisloch, was uns gerade vielleicht in die falsche Richtung schicken würde und wir kommen mit der Discovery oder mit dem Lernen darüber nicht schnell genug hinterher, wenn wir jetzt tatsächlich die Themen gleichzeitig treiben wollen, dann kann es schon mal sein, dass ich plötzlich ganz, ganz, ganz, ganz besonders großes Verständnis dafür habe, dass wir so ein paar Hygieneaktivitäten priorisieren. Wir müssten das automatisierte Testing nochmal unterstützen. Ja. Das ist, also da ist bis jetzt mein Eindruck immer, okay, das hast du entweder in der Kultur deines Teams so drin, dass es nie verhandelbar ist oder du hast es in den Lippenbekenntnissen immer drin und die Leute freuen sich, wenn sie es dann doch nicht machen müssen. Aber da sind wir ja Gott sei Dank jetzt bei Codecentric in der Situation, dass ich den zweiten Fall nicht erleben brauche. Wir waren schon bei den ganzen Menschen, die dabei sind und bei den Zuständigkeiten. Eine Sache, die ich so ein bisschen beobachte, ich weiß nicht, ob du das auch teilen kannst oder ob du es anders siehst, wir waren schon beim Product Owner. Und der Product Owner ist ja diese Galleonsfigur, der eigentlich wie Atlas die Welt auf seinen Schultern trägt. Der ist derjenige, der quasi das Backlog befüllt, der dafür sorgt, dass die Sachen auch alle wertvoll sind, der sie priorisiert und alles insgesamt nach vorne bringt und am Ende für das Inkrement gerade steht. Eigentlich ist er auch der Produktmanager und der kann auch die Vision vertreten. Also viele Dinge, die zumindest aus einem Scrum Guide heraus, die nicht in der Umsetzung liegen, liegen bei dem. Und ich beobachte so ein bisschen, dass eigentlich der Begriff des Product Owners gerade bei größeren Kunden eher ein Unterstützer einer effizienten Entwicklungsmaschine ist, im Sinne von sorgt dafür, dass der Prozess richtig ist, was eigentlich der Scrum Master ja auch macht und sorgt dafür, dass Storys da sind, dass die verstanden werden, holt bei Stakeholdern vielleicht noch rein, was da genau sein muss. Aber er ist gar nicht so sehr der Treiber und es gibt eher so ein Gespann, also dass es ein Produktmanagement gibt und Product Owner, wo die Teams selber immer glauben, das ist derjenige, der hat ja die gesamte Verantwortung und das dann aber nicht hat. Und viele benennen den dann einfach um und sagen, wir etablieren einen Proxy-PO. Das ist im Grunde jemand, der kennt sich gut aus mit einer effizienten Entwicklung und der schreibt im Grunde genommen dann die Tickets für den anderen, weil der kann das nicht so richtig gut. Oh, das ist ein sehr leidenschaftliches Feld, was du da beackerst. Also im Sinne von, dass ich merke, dass da extrem viele Emotionen auch unterwegs sind. Also ich hätte den Product Owner, so wie du es beschreibst, ist heute oft die Erwartung, das ist die Person, die Produktmanager ist und dir die Shots ansagt. Meine Wahrnehmung war immer, erstmal ist es eine Rolle. Das ist eine Rolle, die dafür verantwortlich ist, dass nicht Siegleute auf dem Development Team zutreten und widersprüchliche Informationen geben, wo die Reise hingehen soll. Das heißt, erstmal wäre mein Verständnis, das ist eine Moderationsrolle. Das heißt nicht, der muss wissen, was die wichtigste Priorität ist, sondern er muss dafür sorgen, dass die wichtigste Priorität herausgearbeitet wird. Das kann, so blöd das klingt, ein Meeting mit irgendwie verschiedenen Stakeholdern sein. Und wenn die dann uneinig sind, dann ist das auch tatsächlich durchaus herausfordernd, darauf zu kommen. Und natürlich auch nicht ideal, wenn man dann nicht den Eindruck hat, okay, man kann hier durch oder man hat hier einen methodischen Weg, kompetent das rauszuarbeiten. Diese Trennung von Produktmanager und Product Owner am Team habe ich früher auch sehr, sehr, sehr, sehr, sehr radikal kritisch gesehen. Ich glaube, heute ist es gut, wenn ein Produktmanager viel Zeit mit dem Team verbringt, dass die Klarheit da ist, dass quasi das, was du von Kunden und Markt weißt, auch sehr direkt mit dem Team erarbeitet wird. Das Dilemma ist, dass auch das Zeit braucht. Es gibt so Ausprägungen, die ich gerade sehe am Markt, wie es gibt ein Delivery-Team und ein Discovery-Team. Da bin ich dann mit einigen Zweifeln ausgestattet, ob das gut funktioniert, weil ich mir nicht vorstellen kann, also das ist wieder diese Handover. Aber das ist wie früher, wir holen mal eine Agentur und die macht für uns das Market Research und danach wundere ich mich, dass wenn ich dann die Produktdetails danach entscheide, aber nicht dabei war, dass ich dann eigentlich gar nicht so richtig diese Kundenperspektive so richtig empathisch nachleben kann. Das wundert mich gerade in der jetzigen Zeit, weil ein Thema, was ich ganz oft sehe, ist dieses Braindrain, also das Wissen nicht vorhanden ist. Entweder wir haben es nicht selber gebaut, es war ein Dienstleister, wir verstehen es gar nicht oder aber jetzt die Babyboomer gehen alle weg. Wir wissen gar nicht mehr, was die Leute vorher wussten. Und eigentlich musst du ja Wissensmanagement auch in den Mittelpunkt stellen und sagen, wir brauchen dieses Wissen. Und immer, wenn wir noch ein Handover haben, wird Wissen verloren gehen. Es ist einfach so. Und diejenigen, die das Wissen brauchen, müssen direkt beteiligt sein. Da könnte man ja clever die Teams mixen. Du könntest sagen, es gibt aus dem Delivery-Team einen Klassensprecher, zwei Leute, die gehen mit in die Discovery hinein, damit sie das Hands-on auch dabei haben. Oder dass du irgendwie das besser verzahnst, glaube ich, als zu sagen, es gibt einen Block hier auf der rechten Seite und einen Block hier auf der linken Seite. Na. Ich bin immer noch davon überzeugt, dass du alles tun solltest, dass du das nicht trennst, dass du nicht zwei Teams hast. Also in dem, wie ich arbeite, wenn ich tatsächlich, also mein Prinzip ist, dass ich auf der einen Seite tatsächlich coache und berate und tatsächlich auch Trainings gebe. Und auf der anderen Seite ist es aber so, dass ich sage, ich will alle paar Jahre in eine Interimsrolle arbeiten. Damit ich weiß, dass ich immer noch die Welt verstehe und nicht selber in meine eigene Echokammer gekommen bin. Also dieses Problem von vorhin, wenn du irgendwie 20 Mal was erzählst, dann glaubst du, dass es richtig ist, weil du hast es ja selber oft genug gehört. Und deswegen habe ich so den Anspruch an mich selber, dass ich das immer wieder auch im Feld tatsächlich hart nochmal nacherlebe. Also zuletzt 2020 bis 2022. Und da ist es ja zum Beispiel wirklich so, also wenn in dem Augenblick, wo wir Storys machen, wo wir Design machen, wo wir uns fragen, okay, wie muss es jetzt sein, damit es funktioniert? Kombiniert und Analytik haben wir noch nicht drüber gesprochen, weil das ist in dem Augenblick, wo du Analytik kombinierst und Discovery kombinierst, in dem Augenblick findest du raus, ob du vorher Discovery erfolgreich warst oder ob du tatsächlich in der Discovery eigentlich noch deinen Werkzeugkasten nachrüsten musst, weil wenn du Discovery machst und danach geht die Analytik dann immer auf eine andere Entscheidung als das, was du vorher discovered hast, dann lernst du halt, okay, du musst dein Werkzeug noch kalibrieren vorne. Da sieht man aber in dem Augenblick, wo ich also vorne erst tatsächlich mir aus dem Gedanken heraus, die ich mir gerade um die Lösungsgestaltung mache, aus dem Gedanken heraus, die ich mir gerade um die Implementierung mache, wenn ich dementsprechend die Fragen von der Discovery treibe und umgekehrt die Discovery wiederum das direkt beeinflusst, wie viel habe ich denn da an Handover? Also bis dahin war immer mein Dilemma, oh krass, Product Management im Sinne von, ich finde raus, welche Kunden welche Probleme haben und transformiere das in Lösungen, die die dann haben wollen wollen und muss dann trotzdem noch kommunizieren mit dem Produktmarketing, was für mich heißt, okay, da ist eine großartige Lösung für eine definierte Zielgruppe und die sollen dafür sorgen, dass das auch tatsächlich niemand verpasst, dass es das gibt und gut genug erklärt wird und so weiter. Also diese Symbiose zu leben, dachte ich, wäre irgendwie das Maximum an Kommunikation, was man mit Bandbreite füllen muss. Und jetzt kommt dieses andere Thema noch dazu, dass ich dort auch noch irgendwie zwei Dinge voneinander entkoppel. Dann kriege ich langsam Angst, ob das leistbar ist. Zumal ich ja auch noch in die Situation komme, dass ich nicht irgendwie ein Team habe. Genau. Das würde ich jetzt auch noch. Also ich habe ja Topologien, da haben wir das schöne Wort. Also ich liebe tatsächlich den Zusammenschrieb von Team Topologies. Nicht, weil die die beste Erfindung seit geschnitten Brot machen, sondern weil ich das Buch gelesen habe und gedacht habe, hey cool, das deckt sich so eins zu eins mit allem, was ich die letzten 15 bis 20 Jahre gelernt und gemacht und selber angewendet habe. Es gibt dem Begrifflichkeiten, es gibt dem einfache Muster, die für mich völlig ausreichend scheinen und die sich dann auch tatsächlich im nächsten Schritt in der Realität bewährt haben. Also von dem Plattform, ob du es früher Framework oder sonst was genannt hast, Plattform, dann halt tatsächlich diese Value-zentrierten Teams. Und da gibt es halt diesen sehr, sehr schönen Satz, ob ich den jetzt zusammenkriege, sonst muss ich nochmal nachschlagen und nachreichen, aber da geht es um Ownership und im Prinzip sagen die halt, schau mal, wenn du ein Team hast, das halt tatsächlich an einem konkreten Value-Thema arbeitet, das kann ein Kundensegment sein, das kann ein Produkt sein, das kann ein Teilprozess sein, was auch immer, Dann ist es halt wichtig, dass die Abilities to strategize, to deliver und dann tatsächlich, du musst halt rausfinden, was wäre das Richtige zu tun oder wo können wir entscheidend Mehrwert schaffen oder unsere Ziele erreichen, wenn wir dort angreifen, dann wie können wir das umsetzen und wie können wir dann auch tatsächlich die Ergebnisse so verwerten, um rauszufinden, ob es das Richtige war und daraus lernen und so weiter. Wenn ein Team das alles kann, dann kann es Ownership übernehmen. Und das heißt umgekehrt für mich, wenn ich jetzt zum Beispiel die Discovery und Delivery trenne, dann habe ich ein sehr, sehr hohes Risiko, dass die Ownership verloren geht. Weil die einen sagen, wir bauen nur das, was vorne discovered wird und die anderen sagen, womöglich irgendwann, ja, was die da bauen, ist ja nicht das, was wir discovered haben. Und für mich einer der größten Hebel, die ich erlebt habe, die eine Veränderung bringen, ist eben genau das, die Leute, die das Produkt definieren, also die wirklich dann für die Gestaltung die Entscheidung im Detail auch feiern, dass die vorne bei den, Kundeninteraktionen mit dabei sind, also so in der Discovery. Und deswegen ist das glaube ich ein essentielles Thema an der Stelle. Team Topologies, absolute Leseempfehlung für jeden. Gerne Marty Kagan vorher lesen, wer Produkt macht. Die beiden Dinger greifen fantastisch ineinander und helfen sich gegenseitig sehr für digitales Produktgeschäft. So gegen Ende machen wir es erst mal richtig groß, weil wir sind schon bei der Trennung. Wir sind am Ende, da müssen wir auch noch muss ich mich noch vorstellen dann am Ende oder lassen wir das? Dann kommen wir noch zu. Okay. Gut. Aber wir haben doch erst, wie viele Stunden haben wir denn? Sind wir schon bei drei, vier? Wir treffen uns wieder. Ralf. Wir treffen uns einfach wieder, weil das Thema ist ja riesig groß und wir versuchen echt jeden Baum einmal anzufassen in diesem Wald, aber der Wald ist riesig. Es wird ein bisschen schwierig, das zu machen. Ich glaube, da können wir einen Call for Deep Dives in deiner Hörerschaft machen. Also tatsächlich, wenn euch Themen interessieren, die der Stephan weiter beleuchten sollte mit Experten, also vielleicht anderen oder vielleicht auch mit mir, dann glaube ich, könnt ihr dem Stephan gerne schreiben und sagen, Stephan, wir hätten gerne einen Deep Dive zum Thema. Was euch interessiert? Wir sprachen über die getrennten Discovery-Teams und Delivery-Teams. Und ich wollte es nochmal groß machen. Und groß heißt skalieren. Und wie heißt das so schön? No man is an island. Jetzt gehen wir in Unternehmen, in denen wir auch häufiger unterwegs sind, die größer sind. Da ist nicht ein Tech-Stream unterwegs oder ein Team kann ein Produkt bauen, sondern es verzahnen sich Dinge. Und jetzt wird es schwierig. Wie kriege ich eine Arbeitsteilung hin? Ich habe meinen Product-Owner. Ich würde gerne mit meinem Team ein bisschen Discovery machen. Aber ich mache quasi den API-Layer für eine große Lösung, die da existiert. Und von meinem API-Layer, was bedeutet Discovery für mich? Ich muss doch eigentlich nur machen, was in dem großen Ding drin ist. Und dann ist man schnell in einem zum Beispiel Safe-Umfeld, wo man sagt, wir versuchen irgendwie viele verschiedene Kleinteile miteinander zu synchronisieren, dass sie in dieselbe Richtung gehen. Welche erfolgreichen Modelle kennst du, um groß zu werden? Oh. Mein Gott, mein Kopf platzt allein bei den neuen Stichwörtern, die du nebenbei gedroppt hast. Also du sagst API, ich denke an Developer Experience und wie unterdefiniert dieser Begriff zurzeit ist. Also allein das Beispiel API zeigt ja schon wieder sehr, sehr schön auf. Auch hier musst du UX berücksichtigen. Dein User ist aber tatsächlich, sind entweder andere Entwickler oder sogar technische Bots möglicherweise oder KIs in Zukunft. Das heißt irgendwie eine neue Aufgabenstellung, weil jetzt gehst du nicht mehr hin und machst ein Moodboard irgendwie zu einem Konsumenten. Ja. Genau. Oh Gott, Personas. Personas und, Segmentation by Jobs, das ist ein sehr, sehr schönes Thema, über das wir reden können. Aber das wäre dann tatsächlich ein separater Podcast. Also Personas tatsächlich habe ich hinter mir gelassen und muss noch lernen, diesen Begriff tolerant damit umzugehen. Also du schaffst ja mit Personas eigentlich nicht eine Unklarheit, aber das ist ein anderes Thema, andere Folge vielleicht mal oder anderes Feierabendbier. Genau, wo waren wir? Wir waren bei große Strukturen schaffen. Da ist genau ja das Spannende, wann koppelst du und wann entkoppelst du, wie alignst du, wie machst du Portfolio und das Ganze kann natürlich, je größer es wird, desto schwieriger wird es. Also erstmal fängt es ja damit an, dass du irgendwie sagst, okay, wir haben vielleicht irgendwie ein kleines Produkt und dieses kleine Produkt hat vielleicht verschiedene Aspekte und jetzt wird das Produkt größer und damit du es schnell entwickeln kannst, machst du die Zellteilung und dann dann wendest du genau diese Topologien darauf ein, dass du sagst, okay, wir machen mal so ein bisschen Fundamentarbeit, die ganze Cloud-Komplexität und so weiter, erst mal wegkapseln. Und dann haben wir vielleicht irgendwie zwei unterschiedliche Benutzergruppen, die da drauf unterwegs sind, und die geben wir zwei Teams. Oder wir sagen, guck mal, Growth und Acquisition, das gibt ein eigenes Team und, und, und. Also was du immer versuchst, ist, dass du tatsächlich den Teams eine Mission gibst. Und gleichzeitig beginnt jetzt etwas, was wir in der agilen Welt, glaube ich, manchmal wie irgendwie ein Schmähwort haben. Jetzt geht es nämlich dann tatsächlich um Führung. Und Alignment. Mir kommt es so vor, als wäre heute eine Führungskraft zu haben, irgendwie ein Problem. Aber an der Stelle möchtest du ja dann sagen, okay, du hast jetzt, keine Ahnung, fünf, sechs Module. Dann brauchst du natürlich irgendwie ein Product Lead, also ein Lead Product Manager. Und zwar tatsächlich da dieses Produkt zu führen. Also das heißt jetzt für dieses Produkt die Strategie zu machen, das wäre ja verrückt, wenn da jetzt irgendwie fünf Komponenten irgendwie Komponentenstrategien machen. Also stell dir vor, keine Ahnung, bei Spotify, die Discover Weekly Team würde zum Beispiel jetzt einfach mal eine Strategie machen, die komplett entkoppelt ist vom Monetization Stream oder sonst was. Das wäre unvorteilhaft. Würde aber vielleicht auch erklären, was mir gerade mit meiner Discover Weekly Playlist passiert, aber das ist ein anderes Thema. Da muss ich rein, weil da sieht man das wunderbar. Spotify, eines meiner Lieblingsthemen, hat sich positioniert, sie wollen gerne auch Hörbuchanbieter sein. Und wenn du ernsthaft in diesen Listen guckst, es gibt ja immer, this is the Beatles, this is Rolling Stones und dann gibt es, this is drei Fragezeichen. Track 27 von Folge 15, Track 39 von Folge 2. Oh ja. Das macht gar keinen Sinn. Und das ist für mich ein gutes Beispiel, wie diese Teams nicht allein funktionieren. Also du hast halt das Technische einfach angewendet und gesagt, das stülpen wir auf alles. Aber wir behandeln alles gleich. Und da fehlte jemand, der mal drüber nachgedacht hat. Ja. Ich glaube, da sind wir spekulativ unterwegs. Also dass das natürlich irgendwie ziemlich misslungen ist an der Stelle. Genauso wie ich höre irgendwie ein Audiobuch und dann lege ich mein Spotify zur Seite und dann weiß es nicht mehr, an welcher Stelle ich war. Und ich soll das dann wieder finden? seriously, bye bye, hello Audible, dass das nicht gut ist, ist klar. Woran das liegt, ist aber eine ganz schwierige Frage. Also ich glaube, die haben natürlich die letzten Jahre einen ordentlichen Business-Druck gehabt. Und mussten halt schnell irgendwie neue Geschäftsfelder belegen. Podcasts haben zum Beispiel geboomt und den hätten sie fast verpasst, den Markt. Dafür haben sie sehr, sehr schnell darüber geschwenkt und haben ihn sehr erfolgreich belegt. Also wenn ich daran denke, heute in einem Termin haben wir tatsächlich irgendwie auf zwei Episoden von CodeCentric hingewiesen, rund um das Thema Large Language Models und was man damit so machen kann. Zwei tolle Folgen übrigens, die ich sehr empfehlen kann. Der Link war ein Spotify-Link. Also ich bin da immer noch nicht angekommen, weil ich immer noch den Schmerz der Migration spüre. Aber ich nehme wahr, dass Spotify es gelungen ist, da ganz vorne mit dabei zu sein. Und sie haben es tatsächlich auch an anderer Stelle wiederum sehr richtig gemacht, weil sie tatsächlich Monetarisierung wiederum für die Content-Provider mit anbieten. Und das ist ja an vielen anderen Stellen sehr, sehr viel schwieriger gewesen. Ich glaube, Podcasts sind inzwischen okay unterwegs. Das nutzt sich zu wenig, als dass ich sagen kann, auf welchem Niveau das ist. Bücher tatsächlich sehe ich auch noch nicht ganz, dass sie da angekommen sind. Aber die sind ja immer besser unterwegs. Von daher schauen wir mal, was da noch kommt. Die sind ein gutes Beispiel dafür. Die haben ja auch tausende von Entwicklern stehen als Vorbild, wie man mit Tribes und Squads und eben Spotify-Modellen, die man vor Jahren mal gedanklich machte, aber nie so gelebt hat, wie es dann in diesen Papieren steht. Das ist, glaube ich, ein gutes Beispiel. Es gibt Jünger im Markt, die ich sehe, die folgen einem Safe-Modell, die wollen das gerne implementieren, damit man weiß, wie organisiere ich denn bitte schön so komplexe Umgebungen und dann gibt es diejenigen, die sagen, das Spotify-Modell ist gut, da ist ein bisschen Autarkie für die einzelnen Teams, machen meistens Leute, die A, nie bei Spotify gearbeitet haben und B, die auch vielleicht andere Probleme damit lösen, als die Probleme tatsächlich den Business-Wert zu schaffen, weil du orchestrierst dann anders. Und es ist okay, weil du hast verschiedene geschichtete Probleme, die du lösen musst natürlich. Aber ich glaube, gerade diese... Großen und komplexen Umgebungen brauchen einen Startpunkt, an dem du dich bewegst und dann eine angepasste Lösung für das, was du hast. Du kannst nie sagen, ich nehme aus dem Regal einfach mal die Blaupause, das wird schon passen bei mir. Du musst viel Arbeit da rein investieren, dass Menschen sich darum kümmern, diesen Haufen zu strukturieren. Und du nanntest es gerade Leadership. Ich finde genau das ist es. Es braucht ein paar Leute, die sagen, wo streben wir eigentlich gemeinsam hin und wie versammeln wir uns, dass wir möglichst mit wenig Reibungsverlusten dahin kommen. Reibungsverluste wird es geben, gerade wenn du größer wirst, gibt es das immer. Aber du musst halt gucken, wie kann ich mit wenig persönlichem Schmerz und wenig organisatorischem Schmerz ein Modell bauen, was du dann auch wieder austarieren musst. Je nachdem, willst du eher vorhersehbar sein, willst du schneller sein, was willst du optimieren. Das ist ähnlich wie bei technischen Architekturen. Und wenn du das aussprechen kannst, wenn du in dem Leadership sagst, so unsere Mission ist es jetzt schnell Wasser zu machen oder Land zu machen oder ist es eben verlässlich zu sein oder oder oder und nach diesen Kriterien transparent zu sein. Auch da, das könnten wir jetzt schon wieder auf so viele Themen zerlegen. Also allein zu sagen, Spotify macht das so. Also bei der Größe des Unternehmens, die du beschrieben hast, müssen wir eigentlich davon ausgehen, dass es unterschiedlichste Kulturen, Prozesse und Realitäten gibt in diesem Unternehmen. Dann werden die auch, wie du es beschrieben hast, jedes Unternehmen schaut danach, was sind gerade meine wichtigsten Ziele. Also ich fand zum Beispiel eine Zeit lang extrem irritierend, wenn irgendwie eine Mobile App für ein iPhone ganz andere UI Elemente teilweise hat und auch andere Terminologie, als es dann irgendwie auf meinem Laptop heißt vom selben Anbieter. Und das sind ja manchmal einfach Entscheidungen, dass du sagst, okay, dieses Geschäftsfeld entwickelt sich gerade so schnell weiter und die Plattform entwickeln sich so schnell weiter, dass ich sage, wir machen das bewusst. Wir geben denen große Freiheit, um zu sehen, dass sie sich dann gegenseitig befruchten. Dann kann es dir natürlich passieren, dass die sich nicht wieder so richtig einfangen untereinander. Dann ist das mal nicht gut gelaufen, das fällt ein bisschen auf und man sagt, oh, oh, oh, was habt ihr denn da gemacht? Aber war es deswegen die falsche Entscheidung. Da bin ich mir dann immer noch nicht so sicher. Die Art und Weise, wie ich eine Skalierung angehe, musst du auf jeden Fall auf den Einzelfall reinschauen. Also jede Firma hat ja einen Startpunkt. Und mir fällt es auf, gerade bei größeren Unternehmen, so vielschichtig wie die sind, gibt es dann doch immer wieder den Moment, wo ich merke, okay, das hier ist irgendwie ein Teil ihrer Identität. Zum Beispiel, dass auch Konzern, mit dem ich arbeite, dass es dort nicht möglich ist, dass die Vorstände tatsächlich einfach von oben etwas durchweisen. Einfach, weil tatsächlich die Leute, die das Business tragen und die dafür verantwortlich sind, die sind, die über zig Jahre besonders geschützt wurden, Aus guten Gründen, weil die halt das groß gemacht haben, was jetzt da ist. Und jetzt kommen aber halt Transformationssituationen, in denen sie damit hadern. Und bei denen jetzt darauf zu schauen, was wäre denn jetzt der richtige Weg für eine agile Transformation, wie kann man die angehen, würde ich zum Beispiel dann ganz anders beleuchten als in anderen Strukturen. Für mich persönlich ist immer die, eine der spannendsten Sachen, dass ich irgendwie mal so zehn Jahre am Stück hatte, wo ich gemerkt habe, so komisch, wenn ich irgendwo reinkomme und die Prozesse laufen richtig gut in der digitalen Welt, das ist ein toller agiler Prozess und so weiter und so fort, dann merke ich irgendwann kurz danach so, das Business funktioniert nicht richtig. Die sind immer noch irgendwie extern gefundet. Und umgekehrt, wenn ich irgendwo reingekommen bin und gedacht habe so, boah, was ist denn das hier für ein Chaos in der Entwicklung, dann war es oft so, das waren halt die Könige am Markt. Und da habe ich dann zwischendurch mal so eine Phase gehabt, wo ich gesagt habe, okay, wenn ich irgendwo reinkomme und die Prozesse laufen gut und es ist eine gute agile Struktur, dann kriege ich Angst, weil wahrscheinlich sind die übermorgen insolvent oder werden verkauft oder sonst was. Und da war dann so ein bisschen in mir drin so die Frage, was ist mir lieber? Und deswegen, ich glaube, das Allerwichtigste ist immer, dass du weißt, wer sind deine Kunden, welchen Wert kannst du für die generieren und was musst du dafür liefern? Wenn du das hast und wenn du das wirklich mit einer Klarheit hast, dann sind die agilen Strukturen für dich als Unternehmen auch erstmal irgendwie, wenn die dann fehlerhaft sind, das kannst du verkraften. Und umgekehrt, wenn du jetzt eine tolle agile Struktur aufbaust, aber du hast oben immer noch nicht das Verständnis, was wird am Markt erfolgreich sein und du bringst irgendwie ein neues Angebot nach dem anderen raus und alle funktionieren nicht. Und sind aber alle nicht so richtig gestresst, weil das ist ja das, was man gewohnt ist, dann habe ich echte Probleme. Deswegen egal, egal ob das safe ist, ob das, keine Ahnung, ein Less ist oder ob das, was haben wir denn jetzt nochmal hier, Unfix? Es gibt ja zig Frameworks und egal welches Framework du nimmst, das Erste, was mich interessiert und da ist dann bei mir manchmal so eine Scheuklappe drauf, dass ich sage, ist mir erstmal egal, wie ihr Development macht. Erstmal will ich wissen, was baut ihr für wen? Warum brauchen die das? Pitch mir das mal. So als wärst du ein Startup und du würdest jetzt das Investment suchen, überhaupt was aufzubauen. Wenn ihr da falsch aufgestellt seid, dann ist es mir egal, ob ihr safe oder sonst was macht. Ehrlich gesagt. Im Kern die Richtung muss stimmen. Naja, genau. Du musst vor allen Dingen wissen, wo tatsächlich, also warum sollten Leute dir Geld geben? Und den Rest kannst du dann immer noch besser machen. Ob du das mit Safe machst und dann dich wunderst, dass du sehr weit weg bist vom Kunden oder den nicht weit genug integriert bekommst und fast bei viel Overhead hast oder was auch immer da noch mit drin ist. Du hast vielleicht dann den Vorteil, dass du aber bestimmte Rollen, die es vorher gab, irgendwie ohne Gesichtsverlust in diese Welt integrieren kannst. Das kann ja ein guter Grund sein. Kann aber auch einfach sein, hey, das gibt dir nicht nur eine Antwort, wie Development funktioniert, Sondern es gibt ja auch irgendwie ein paar Leitplanken darüber, dass du mit Kunden regelmäßig checkst. Es gibt ja wahnsinnig agile Firmen, die nie mit Kunden wirklich dann interagieren und so weiter. Das kann alles Vor- und Nachteile haben. Also bin ich vergleichsweise agnostisch, wenn ich feststellen kann, okay, wir kriegen zumindest da irgendwie erstmal diese Business-Richtung richtig eingeschlagen. Und dann, klar, habe ich natürlich Vorlieben, wie ich lieber arbeite und was ich da gerne sehen möchte. Aber das ist dann eigentlich immer Kunde, Kunde, Kunde und Geschäftsmodell gegenhalten und Go-to-Market mit einbeziehen und so weiter. Ich weiß nicht, wie es dir geht, aber ich könnte jetzt hier stundenlang weiterreden darüber, aber ich versuche es mal so langsam in eine Zielgerade zu lenken. Das ist eine gute Idee, weil sonst müsste ich nämlich auch einen neuen Tee machen. Gut, wir vermeiden es, einen neuen Tee machen zu müssen. Erstmal bin ich super happy. Ich finde das Gespräch sehr gut. Ich finde vor allen Dingen gut, dass du quasi mein Kollege bist, dass wir gemeinsam in Projekten sind, weil du einen sehr breiten Erfahrungsschatz hast und diesen breiten Erfahrungsschatz und das Wissen und, Was man eben braucht, um zu identifizieren, ob man gerade erfolgreich oder nicht erfolgreich ist, bevor man ganz am Ende ist. Also das schon vorher rauszufinden, ist super wertvoll. Und ich würde zum Schluss nochmal versuchen, das alles, was wir hier heute auf den Tisch geworfen haben, zusammenzubinden, indem ich dich frage, ob es so ein, zwei, drei Tipps gibt, wo du sagst, das sind so Dinge, die würde ich meinem jüngeren Ich geben. Also mit all dem, was ich jetzt mitbekommen habe in der Branche, in der Digitalisierung, der junge Ralf Westbrock sollte diese Dinge wissen oder Menschen, die zuhören und heute in diesem Feld unterwegs sein wollen? Ich glaube, drei Dinge habe ich. Das erste ist tatsächlich, dass ich auch so lange Zeit über Dinge nachgedacht habe, so Konzentrierung, Konzentrierung, Konzentrierung, Konzentrierung und dann fragst du dich, der Nutzer, der braucht was. Und dann läufst du dir oft eine blutige Nase. Und die Lösung ist, dass Geschäftsmodell und Kundenbedürfnisse eine Symbiose bilden müssen. Also du willst, egal wie toll das für deine Kunden ist, was du brauchst, ist, dass du in fünf Jahren, in sieben Jahren, in zehn Jahren für deine Kunden immer noch tolle Sachen machen kannst. Und dass es dir gut geht dabei. Und deswegen ist es halt total wichtig, dass du immer auch ein Geschäftsmodell mitbringst, bei dem halt du dann auch sicherstellst, dass du das alles leisten kannst. Und deswegen diese Symbiose zu bauen, also irgendwann habe ich das mal verstanden, habe ich immer gesagt, hey, wenn Apple nur kundenzentriert wäre, dann gäbe es doch damals iTunes, als es noch cool war, für Android. Wenn du das mal kurz überlegst, es macht total Sinn, dass es das nicht gibt. Weil es würde halt eben ganz, ganz viel mit ganz, ganz vielen Dingen brechen, die halt sowohl in ihrer Marke als auch in ihrem Geschäftsmodell drin sind. Und deswegen genau das tust du nicht, wenn das ein Konflikt ist. Und das ist für mich die wichtigste Aufgabe, die wir als Produktmanager haben, dass wir uns tatsächlich mit beiden Firmen machen. Das Zweite ist dieses ... Und sag nicht nur, dass man beim Kunden sein soll, sondern bau kontinuierlich Kontakte zu Kunden auf. Die ganze Zeit. Schau, dass du die ganze Zeit mit Kunden darüber sprichst, was tun sie heute. Also wenn ich jetzt zum Beispiel gerade irgendwie Produktmanagement, Beratung oder Interimsarbeit oder so anbiete, dann kann ich hingehen und ich kann sagen, guck mal hier, du kannst mit uns Discovery lernen, du kannst mit uns Customer Research sehr pragmatisch so machen, dass es sehr, sehr schnell wirkt. Aber eigentlich ist das erste spannend, dass ich sage, hey, was ist denn bei euch gerade los? Was bewegt euch gerade? Okay, und was versucht ihr zu tun? Brennt mir auf den Lippen, aber ich hoffe, dass wir nicht zu weit abbiegen. Die Frage, die mir in den Sinn kommt, ist, mit Kunden sprechen. Bestehende oder potenzielle? Ja. Gute Antwort. Also das heißt, auch mit denen sprechen. Ja, genau. Das ist keine Exklusivität. Natürlich, du brauchst ja beides. Also du musst, also du hast ja für heute eine Kundengruppe, die dich ernährt. Und natürlich musst du zum einen dafür sorgen, dass die weiter gebunden sind. Dort hast du auch Innovationspotenziale, weil du bei denen natürlich auch schon siehst oder Verbesserungspotenziale, weil du schon siehst, was sie tun. Und natürlich interessiert dich auch, was sind denn Zielgruppen, die du als nächstes machen kannst. Apropos, wenn übrigens jemand in Dortmund oder in München im Großraum das hört, es gibt ein ganz fantastisches Brettspiel, das heißt Playing Lean. Bei dem geht es tatsächlich darum, dass vier Startups gegeneinander antreten und in der Branche, was war das, entweder quasi Uber-like oder Airbnb-like gegeneinander antreten und mit Markt-Testing, Vertrieb und Produktentwicklung in diesen Phasen mit unterschiedlichen Experimenten und dergleichen versuchen, von dem Einstiegsmarkt in den Massenmarkt fortzustoßen als erstes, weil das ist dann, wenn man Winner takes it all hat. Und dieses wunderschöne Brettspiel, das könnte man spielen mit dem Stephan und dem Ralf am Standort Dortmund oder am Standort München, wenn man Lust hat. Dann wäre der Ralf ein Facilitator und ihr könnt gegen Stephan antreten und ihm mal zeigen, dass ihr noch besser Startup macht als er. Und auf jeden Fall, wer Lust hat, also wir tatsächlich werden das mal wieder machen und dann kann man auch genau diese Dinge, wie funktioniert das denn mit dem Einstiegssegment, dem Massensegment, wie tastet man sich vor? Das wird in diesem Spiel ganz wunderbar illustriert und wir haben dann auch die Geschichten dabei, wie das denn tatsächlich in der Realität sich dann angekühlt hat für Startups. Ist das ein Tag. Ist das eine Woche, ist das eine Stunde? Ich denke gerade an einen Abend, den ich bei eGym verbracht habe. Der war sehr, sehr, sehr lang. Die waren sehr ausdauernd in ihren Debatten. Die haben das zu zweit und zu dritt als Teams gespielt. Da ist es ein bisschen ausgeartet. Ansonsten sind wir so zwei Stunden maximal unterwegs. Dürfen dabei aber auch Kaltgetränke oder Grillgut oder ähnliches haben. Kannst auch einen Tee haben noch. Ach, einen Tee, fabelhaft. Genau, solche wilden Sachen können wir dabei auch machen. Genau, und dann tatsächlich kann man eben auch diese Segmentierung und wie man da geschickt reingeht, vorgeht, weitergeht, beschreibt das Spiel alles fantastisch. Ich hatte dich unterbrochen bei Punkt zwei. Wir hatten, glaube ich, zwei Tipps für den jungen Reitwerk. Den dritten, den dritten. Und der dritte, der ist, das ist eine ganz schlimme Sache. Messen. Also jeder kennt den Begriff Product Analytics. Es ist total spannend. Bisweilen treffe ich ja, also man sieht es öfter, Startups, viele Startups, die schnell wachsen und die tatsächlich ihre Investments rechtfertigen müssen, die haben das. Aber im breiten Sportproduktentwicklung in der deutschen Wirtschaft ist es immer noch ein, man müsste mal, Thema. Und ich finde es total spannend, weil es so ein bisschen so ist, als würdest du tatsächlich im Jahr 2024 immer noch mit einem Auto durch die Gegend fahren in fremdem Terrain und hättest kein GPS. PS. Also du weißt schon, auf welchen Hypothesen du abgebogen bist, aber du hast irgendwie, du weißt jetzt nicht sicher, wo du gerade bist. Und das finde ich bemerkenswert. Wenn du Glück hast, stößt du mal irgendwie auf ein Stadtteilschild, das du auch noch kennst und in der Karte wieder findest. Aber genau, was wir vorhin gesagt haben, wenn du jetzt mit den Kunden frühzeitig sprichst, wenn du Product Discovery machst und dann hast du keine Analytik hinten raus und hast nicht deine wichtigsten Kennzahlen und kannst da nicht rausfinden, waren denn meine Investments jetzt die die richtigen, weil wir reden ja bei Produktentwicklung von Investments und dafür wollen wir einen Return on Invest haben. Und wir haben diesen Zinseszinseffekt. Wenn ich das nicht messe, dann weiß ich tatsächlich nicht, ob ich heute einen guten Job mache. Und wenn also irgendjemand da draußen ist und sagt, ja, unser Produkt ist nicht so erfolgreich, wie es das sein sollte und wir wissen gar nicht, ob diese Investments, die wir da reintun, ob die denn tatsächlich so das Richtige sind und wir haben immer wahnsinnig viele Meinungen, ganz viel Streit darum, was denn jetzt das richtige Feature ist, dann kann ich nur sagen, dafür gibt es ganz klare Hilfe und gibt es auch wirklich ich ein Kochbuch und das kann man einfach mal so Schritt für Schritt rezeptweise abarbeiten. Das wäre das dritte Ding, das ich gerne viel, viel, viel, viel früher gehabt hätte. Ich habe es dann tatsächlich angefangen zu dem Zeitpunkt, als ich ein Payment-Produkt gemacht habe, da mussten wir noch Dinge selber bauen und es war magisch. Also dann haben wir zum Beispiel, damals haben wir halt die Hypothese gehabt, es war ein Prepaid-Produkt, wenn jemand mehr als zweimal aufgeladen hat, dann ist er mit 90%iger Wahrscheinlichkeit Dauerkunde für die nächsten Jahre. Und dann hatten wir halt tatsächlich an der Stelle etwas, worauf wir hin optimieren konnten. Dann konnten wir halt an der Stelle dann tatsächlich sagen, okay, wir versuchen die Leute jetzt dazu zu bekommen, das mehrfach zu zahlen. Und dann konnten wir halt rausfinden, es ist jetzt eine Korrelation, eine Kausalität und zack, Hebel gefunden, Produkt ausbauen. Wunderschöne Geschichte. Und nur weil man misst, großartig. Sehr großartig. Also die drei Dinge sind es, um sie ganz plakativ ans Ende zu stellen. Nummer eins war Symbiose von Kundenbedürfnis und Geschäftsmodell. Die beiden gehören immer zusammen. Es geht nicht darum, das eine oder das andere zu tun. Also Geschäft zu tun ist nicht böse. Nein, nein, nein, das ist der Grund, warum wir das alles machen. Und Kundenbedürfnis ist Grundvoraussetzung für ein erfolgreiches Geschäft. Es gibt Varianten, die wollen wir aber meist nicht machen. Dann das zweite war tatsächlich das Testen mit Kunden. Und die Nummer drei war Messen, Messen, Messen, Messen, Produktanalytik. Das war ein Geek kommt selten allein. Vielen Dank fürs Zuhören und großen Dank an dich, Ralf. Das war super. Es war mir ein Fest und ich kann das Kompliment von vorne zurückgeben. Mein Eindruck war, dass du unfassbar viel erzählt und beigetragen hast und hier immer die Pässe so gespielt hast, als wüsstest du ganz genau, was ich schon alles gemacht habe und welches Detail du rauskitzeln willst. Ich bin beeindruckt. Das gebe ich gerne zurück. Euch wünsche ich, dass ihr es gut habt. Lasst es euch gut gehen. Lasst ein Abo da. Wir sehen uns oder hören uns bei der nächsten Folge. Tschüss.