Harald Wild: Neue Folge im Agile Focal Point Podcast. Heute beschäftigen wir uns mal mit Produktentwicklung, beziehungsweise wollen das Ganze mal unter das Mikroskop legen. Und wen kann man sich da besser einladen als einen der Top Experten für agile Produktentwicklung in Deutschland? Und deswegen haben wir heute Tim Kleingesuchter. Hallo Tim. Tim Klein: Hallo ihr beiden, hallo Mike, hallo Harald. Schön hier zu sein. Harald Wild: Schön, dass du da bist. Jetzt hast du ja ganz lange Erfahrung in nicht nur agiler Produktentwicklung. Du warst davor auch lange in linearen Projekten unterwegs. Aber wenn wir jetzt mal in die agile Produktentwicklung schauen und zu deinen Kundenprojekten, was sind denn da größtenteils die größten Herausforderungen, die du da siehst? Tim Klein: In Bezug auf Produktentwicklung meinst du? Harald Wild: Mhm, genau. Tim Klein: Also ich denke mal, eines der großen Themen ist heutzutage immer noch, dass wenn wir in IT-nahen Organisationen unterwegs sind und sehr viel dann über Agilität gesprochen wird und vielleicht Scrum-Ansätze versucht werden, dass das noch sehr delivery-lastig ist. Was meine ich damit? Dass es sehr stark um Liefern geht und noch viel zu sehr eines der, für mich der Hauptthemen von Produktmanagement, nämlich Product Discovery vernachlässigt wird. Sprich, dass viele Firmen einfach definieren, das brauchen wir. Und das muss jetzt möglichst schnell, meines Wins auch mit Scrum oder einem anderen Framework, meint man auch Kanban oder einer Kombination, gelöst werden, ohne wirklich zu hinterfragen, welche Annahmen stehen dahinter, wie viel Evidenz haben wir dazu, was wir hier ausliefern wollen. Und ich glaube, und da war ich auch in den linearen Projekten, klassischen Projekten, bin ich oft beteiligt. Ich glaube, da wird immer noch viel Geld verbrannt, dass Dinge gebaut werden, die dann hinterher von Kunden und Nutzerinnen einfach nicht gut genug angenommen werden, weil nicht früh genug auf Produktrisiken geguckt wird. Harald Wild: Jetzt hast du ja gerade gesagt, in linearen Projekten ist es ähnlich. Vielleicht beleuchten wir das nochmal kurz. Du warst nicht immer in agiler Produktentwicklung und warst vorher auch in linearen Projekten unterwegs. Wie bist du denn zur agilen Produktentwicklung eigentlich gekommen? Tim Klein: Ich habe immer noch mehr Jahre Erfahrung im klassischen Projektmanagement. Das habe ich so 13 Jahre lang gemacht und bin jetzt ungefähr seit 12 Jahren im agilen Produktmanagement unterwegs. Ich habe einen klassischen Hintergrund als Unternehmensberater im IT-Kontext. Also wirklich so angefangen als Junior mit Testmanagement, Fachkonzeption, also wirklich klassisches Fahrmodell entwickeln. über dann Teilprojektleitung, PMO Offices aufgebaut und Projektleitung, Migrationsprojekte, Post Merger und der ganze Kram. Und habe in der Funktion das auch noch für einen großen, damals der führenden Anbieter von Notellvermittlung, also Notellplattform gemacht als Leiter Projektmanagement. Und dann kam dort irgendwann, das war so ungefähr 2011, dieses Thema hoch, hey, wir müssen agil werden, hey, wir müssen jetzt Scrum machen. Und warum? aus meiner heutigen Sicht, weil es halt alle machen, weil man das halt so macht. Und in dem Zuge hatte ich sehr viel Skepsis durchaus erst mal, das sage ich ganz bewusst immer dazu, weil auch bei mir hat das länger gedauert sozusagen, in die Birne kriegt man es schnell rein, also kognitiv das zu verstehen, Agilität, Scrum etc. oder Kanban ist noch vergleichweise machbar, aber bis das dann sozusagen bis in meinen Bauch und später in mein Herz gewandert ist, also ich so ein bisschen Überzeugungstäter geworden bin. hat es durchaus gedauert. Ich sage immer so, mindestens ein, ein Viertel, anderthalb Jahre hat es gedauert, bis ich meine Lernreise, die natürlich immer noch heute anhält, relevant begonnen habe. Ich war skeptisch. So und das erzähle ich immer deshalb, weil ich jedem gegenüber und jeder gegenüber, die auch heute noch ja mit Transformation und Agilität und agiler Produktentwicklung jetzt in konkreten Berührungen findet, dass ich jedem zugestehe, da erstmal eine gesunde Skepsis an den Tag zu legen, nach dem Motto Warum soll das denn jetzt besser funktionieren? Und natürlich brauchen wir auch nicht sagen, ich will das Alte nicht verteufeln. Also gut gemachtes Projektmanagement mag immer noch seine Berechtigung haben. Aber, und das möchte ich noch hinzufügen, ich würde behaupten, dass, ich würde so festmachen, seit 2007, 2008 das Thema Komplexität. in unserem Umfeld wesentlich intensiver geworden ist. Also die Vorhersagbarkeit, die Komplizität von Systemlandschaft, wenn wir Anwendungen oder Produkte entwickeln, die war meiner Ansicht nach früher nicht so stark gegeben. Da ist durch alle möglichen Herausforderungen im Umfeld, Informationstechnologie, Geschwindigkeit von Informationen, meiner Ansicht nach so viel passiert, dass wir heute viel, viel öfter im komplexen Umfeld Produkte entwickeln als vielleicht früher. So wäre meine These. Und das erfordert eben auch ein Umdenken im Produktmanagement. Mike Leber: Du hast jetzt erwähnt, dass diese Änderung für dich nicht nur kognitiv war, also dass im Ende offensichtlich ein längerer Prozess dahinter stand. Jetzt wird uns interessieren, was hat sich denn für dich da geändert? Also was ist denn, wenn du jetzt zurück schaust, das sind ja jetzt doch ein paar Jahre, was ist denn so das Spektrum des Perspektivenwechsels? Tim Klein: Ich mache das ganz gerne an diesem fast schon gefährlichen Begriff agiles Mindset fest. Ich mag den Begriff eigentlich nicht so gern, aber ich folge einer Theorieschule oder einer Erklärung von Svenja Hoferth oder auch Dennis Willkomm, der das aufgegriffen hat. Und Dennis hat uns mal, wir haben mal so eine sehr frühe Podcastaufnahme bei uns auch gemacht, mit ihm gibt es ein Product Owner Mindset. Und er hat uns erklärt, ein Mindset, also eine Haltung. ist im Endeffekt ein Dreiklang aus Fühlen, Denken und Handeln. Also Fühlen der emotionalen Bewertung einer Situation, Denken der kognitiv-rationalen Bewertung einer Situation und Handeln im Endeffekt der wahrnehmbaren Umsetzung. Mike Leber: Ups, jetzt glaube ich, ich muss mal einen Cut machen. Wie heißt das schon? Beim... Harald Wild: Genau, dass auch die Audiospur wieder passt. Mike Leber: Für die Weltform. Sollen wir nochmal kurz... Ja genau, sollen wir einen Stopp machen kurz? Keine Ahnung. Oder einfach zulaufen lassen? Harald Wild: auf Pause drücken? Ach so, ja, weiß ich gar nicht. Das ist ja immer das Blöde. Jetzt redet er weiter. Mike Leber: Stopp, Stopp, Stopp. Warte, Mark... Ich mache jetzt einmal einen Marker. Jetzt habe ich einen Marker kreiert. Schauen wir mal, was das bedeutet. Clipmarker. Dabei glaube ich, der wird wahrscheinlich nur in Riverside erkennbar sein. Harald Wild: Hmm. Mike Leber: Ciao, mal wiedersehen! sein Rechner hat jetzt wahrscheinlich noch zum hochladen aber es ist letztlich egal. Besser wenn wir nochmal starten glaube ich, sonst wird es wieder kompliziert. Harald Wild: Mhm. Mike Leber: Hallihallo! Tim Klein: Keine Ahnung, was los war. Ich war weg. Harald Wild: Ja, das wurde immer schlechter und dann auf einmal warst du raus. Mike Leber: Kein Problem. Und wir kennen das schon, dass dann bei dir, wenn du noch online bist, natürlich noch weiter rekordet wird. Das heißt, am Schluss wird das ein ziemlicher Mess. Aber ich glaube, jetzt macht es Sinn, das noch einmal kurz aufzusetzen. Zurück noch einmal. Tim Klein: Ich habe versucht, zu Ende zu sprechen, weil ich das kenne. Mike Leber: Ja. Tim Klein: Ich glaube, ich habe den logischen Zusammenhang rausgebracht, aber ich kann einfach nochmal ansetzen. Mike Leber: Hm, sollen wir die Frage nochmal stellen oder... Tim Klein: Ja. Mike Leber: ..einfach du schmeißt die Antwort gleich nochmal rein? Tim Klein: Nö, das war ja im Endeffekt, das war ja im Endeffekt, hat es ja gefragt. Nur kognitiv und ja. Mike Leber: Genau, was hat sich für dich verändert? Harald Wild: Okay, genau, dann nochmal kurz Ohren zu halten. Ich klatsche mal eben für den Track. Tim Klein: Ja, was hat sich verändert? Also ich mache das ganz gerne fest an dem Verständnis von diesem etwas vielleicht schon gefährlichen Wort, agiles Mindset. Was meine ich damit? Ich folge da so der Darstellung von der Autorin Svenja Hoferth oder auch dem Dennis Willkomm, der auch inzwischen ja Autor ist. Und mit Dennis haben wir mal eine Podcastaufnahme gemacht zum Thema gibt es ein Product Owner Mindset. Und Dennis erklärt das. Thema Mindset, also Haltung, so dass es ein Dreiklang ist aus Fühlen, Denken und Handeln. Das heißt Fühlen einer emotionalen Bewertung einer Situation, Denken der kognitiv-rationalen Bewertung einer Situation und Handeln im Endeffekt der ausführbaren und damit auch beobachteten Aktionen und Handlungen, die ein Mensch macht. Und das ist auf meine eigene Situation gemünzt, glaube ich so, dass ich Damals, ich habe diese Schulung gemacht, hier Scrum Alliance, Product Honor Training, Scrum Master Training, so diese Foundation Sachen und ich habe kognitiv auch verstanden, weshalb wir das jetzt brauchen, weshalb wir da in dem Unternehmen auf Agilität und Scrum setzen sollten. Ich habe das aber emotional noch nicht gefühlt. Also ich habe, ich war emotional da noch nicht angedockt und wie habe ich gehandelt? Na ja gut, ich habe halt so geta... so, wie soll ich sagen, Agiles Theater oder wie auch immer. Ich habe so gut genug versucht, ein Product ohne Rolle auszuüben, wie ich es halt verstanden hatte zu dem Zeitpunkt. Und das heißt, nach außen, und das finde ich immer wichtig in solchen Transformationssachen, von außen können wir ja nur sehen, wie die Menschen sich verhalten. Also das Handeln. Wir können dabei ja nie hinter die Stirn gucken und wissen nicht wirklich, wie denken und fühlen die Menschen über die Herausforderungen einer solchen Transformation, Agilathemen, Änderungen im Stichwort modernes Produktmanagement etc. Und das ist das, was ich selber ein Stück weit dabei gelernt habe, retrospektiv gelernt habe, dass ich selber erstmal nur funktioniert habe sicherlich eingangs. Also ich habe so die PO-Rolle. zum Beispiel gelebt, wie ich es dachte, zu tun. Aus heutiger Sicht würde ich sagen, verdammt, ich habe gar nicht richtig Produktmanagement dabei gemacht. Also Product Owner sein, ohne Produktmanagement zu können. Ein immer noch sehr weit verbreitetes Problem, glaube ich, heutzutage. Das habe ich immer mehr reflektiert. Und als dann, ich sagte eben so anderthalb oder ein ein Viertel Jahre später, als das dann sozusagen von meinem Bauch in mein Herz gewandert ist, dann habe ich diese emotionale Bewertung, also dieses Fühlen. glaube ich auch immer mehr dazu genommen und dementsprechend diesen Dreieck lang aus meiner eigenen Transformation hin zu jemanden der sagt ja ich glaube das also ganz konkret gesagt ich glaube heute immer noch dass Agilität kein Selbstzweck ist also ich mache das den ganzen Kram agile Produktentwicklung nicht weil uns das dann weil wir schön Bäume umarmen und es uns allen besser geht also ich hoffe auch dass es uns allen besser geht das ist wichtig aber Ich bin so überzeugt von dem Ansatz modernen Produktmanagements und agiler Produktentwicklung, weil ich einfach glaube, dass wir bessere und erfolgreichere Produkte damit entwickeln können oder Services. Und da hat sich, glaube ich, für mich viel verändert. Ich glaube, ich habe das früher eingangs eher selber so mechanistisch gelebt und habe da, glaube ich, wie gesagt, auf dem Rahmen meiner Lernreise, die nie zu Ende ist, glaube ich, mehr und mehr verstanden. worauf es wirklich ankommt und das ist eben nicht irgendwie den Scrum Guide nachzubeten. Ich bin ein riesen Verfechter von Scrum, wenn es denn an der richtigen Stelle eingesetzt wird. Das muss man immer dazusagen. Harald Wild: Jetzt hast du die ganze deine Reise beschrieben und es gibt ja ganz viele Unternehmen, die sich überlegen, auf die Reise zu gehen, die sich überlegen, irgendwas zu verändern, aus verschiedenen Gründen, hoffentlich aus guten. Aber was sind denn aus deiner Erfahrung die wichtigsten Themen, die jemand beachten sollte, wenn er sich auf diese Reise begibt oder wenn jemand noch in den Anfängen steckt? Welche Fehler sollte man nicht machen? Welche Ratschläge kann man geben? Was ist wichtig, wenn man gerade startet? Tim Klein: Jetzt im Rahmen einer agilen Transformation oder Transformation des Produkts. Harald Wild: Ja, oder agile Produktentwicklung. Das heißt, man ist noch in den linearen Projekten hauptsächlich unterwegs. Das ist ja auch das, was man so ein bisschen Projektagilität nennt. Erst mal oftmals startet es in Unternehmen ja so, dass man in IT erst mal Projekte versucht, in eine agile Produktentwicklung umzuwandeln. Und das sind ja viele Gedanken, die da in Unternehmen laufen und viele Prozesse, die man in Frage stellt oder und da so ein bisschen Orientierung zu bieten. Tim Klein: Ganz entscheidend sind für mich zwei Dinge. Das erste ist, Komplexität zu verstehen. Oder den Unterschied zwischen Kompliziertheit und Komplexität. Ich habe das eben schonmal angedeutet. Also im Endeffekt, dass wir, dass uns bewusst ist, dass wir nicht alles ex ante wissen. Das ist, glaube ich, schon eine Grundlage, eine Foundation dafür, dass ich mich anders bewege als in klassischen Projekten. Und der zweite Punkt ist dann eben wegzukommen von einem projektzentrierten Vorgehen hin zu einem produkt- und kundenzentrierten Vorgehen. Und ich glaube, das aufzulösen in einer Organisation, diese ganze Projektlogik bis hin zu Budgetierung, bis hin zu Teamzusammensetzung, bis hin zu … temporär was zu tun. Ich meine, das ist alles nach dienen normiert und definiert, wie ein Projekt definiert ist. Aber das haben wir drei, glaube ich, alle schon zu genüge in früheren Jahren mitgemacht. Das ist man ein vermeintlich neues Produkt, vielleicht hat man damals nur Anwendung gesagt, mit einem Projekt entwickelt. Und wenn man dann sozusagen fertig ist, stellt man fest, oh, das matcht aber gar nicht mit den Bedürfnissen des Marktes des Kunden, des Nutzers. Aha, also brauchen wir noch irgendwie ein Follow-up-Projekt, eine Projektphase 2, Stabilisierungsprojekt, you name it. Oder es gibt sowieso dann Budgetprobleme, irgendwie in einen Maintenance-Mode vernünftig zu kommen. Und gerade wenn man als Externer, wie ich unterwegs war, wird ein Projekt fertiggestellt, dem Kunden sozusagen ans Bein genagelt oder an die Wand genagelt oder man sucht irgendwen, dem man es übergeben kann. Das sind häufig die armen Betriebsorganisationen oder Anwendungsbetriebsgeschichten, die dann sowas übernehmen müssen ohne Wissen. Das heißt, wir müssen weg von dieser Projektdenke hin zu einer Produktdenke. Und damit meine ich, dass wir ein Produkt verstehen müssen als ein langfristiges, lifetime getriebenes Produkt. Also bis zu dem Moment, wo ich einen Rampdown mache und es aus dem Markt rausnehme, wie jetzt zum Beispiel letztes Jahr bei Xing, Gruppen und Events, große Produktbereiche, die die bewusst abgekündigt haben, weil es nicht mehr zu ihrer strategischen Ausrichtung passte. Mike Leber: Hmpf... Tim Klein: gibt es ein Produkt. Und wir haben dementsprechend viele Produkte in unseren Organisationen, die vielleicht 20, sogar 30 Jahre alt sind, aber keiner weiß mehr genug dazu und wir haben Schwierigkeiten, das zu maintainen. Also nehmen wir mal ein ganz konkretes Beispiel. Jetzt kommt AI um die Ecke, wir haben Disruption, wir müssen uns überlegen, wie wir unsere bestehenden Produkte, künstliche Intelligenz vielleicht als Enabler oder Enhancement reinbauen können. Sind wir in der Lage, das produktmäßig zu denken? Die alten Systeme sozusagen zu erweitern im Rahmen ihres Produktlebenszyklus? Und das ist für mich dann ganz nah dran an der Fragestellung Produktverantwortung. Also wer hat denn über den gesamten Produktlebenszyklus die Produktverantwortung? Und ich würde da immer empfehlen, das in sogenannte empowered Teams, empowered Product Teams zu verlagern, also cross-funktional aufgestellte, kollaborativ arbeitende Teams, die wirklich eine Ownership für den Erfolg des Produktes übernehmen und nicht nur für die Delivery. zu einem Zeitpunkt x nach dem Motto, Projekt ist zu Ende, wir liefern ab. Mike Leber: Das wirft noch mehr einen interessanten. Harald Wild: Das ist echt interessant. Und wenn du jetzt in Unternehmen Komplexität erklärst, wie startest du da? Klassisch Kynephin und Stacey? Oder wie erklärst du in Unternehmen, wie Komplexität sich auswirkt, was es mit auch der empirischen Seite der Erfahrungswelt macht? Tim Klein: Ich finde Knaffen zu kompliziert am Anfang oder zu schwierig zu erklären. Es ist ja nicht meins. Ich gehe da eher in das Dacy-Matrix rein, um etwas einfacher und schneller zu haben. Aber ich sage immer, wenn uns die Pandemie irgendwas Positives gebracht hat, dann ist es doch ein wunderbares Beispiel für Komplexität. Also im April 2020 oder März, April 2020 hatten waren wir noch nah am Chaos oder vielleicht hoch im komplexen Umfeld. Wir wussten. Wenig über das Virus und über die Übertragung. Das heißt, das war es. Es war relativ volatil. Das Wie, wie wir also zum Beispiel Ansteckung vermeiden konnten, war noch nicht sehr bekannt. Das heißt, überleg noch mal die Jahre zurück. Wir haben Lieder geträllert beim Händewaschen, damit wir uns lange noch die Hände waschen, weil wir glaubten, das war die Hypothese. Mit genug langem Händewaschen schaffen wir es, die Übertragung zu reduzieren. Ganz in den allerersten Wochen hat man sogar auf Masken verzichtet. Dann hatten wir die Hypothese, die Corona-Warn-App würde uns helfen. Dann hatten wir die Hypothese, die erste eine Impfung würde uns helfen. Und was haben wir gelernt durch die Pandemie? Wir wissen, dass wir vorab nicht alles wussten. Das heißt, iteratives Arbeiten, also inkrementell iteratives, hypothesenbasiertes Arbeiten im Sinne von Feedback-Zyklen zu etablieren. So ist es in der Politik leider nicht komplett gekommen. Aber das ist eigentlich war das wäre es perfekt gewesen. Nach dem Motto Wir machen eine Gesetzesentscheidung. Wir probieren mal was aus. Klar waren ein paar Legging Indicators dabei, die ein bisschen zeitverzögert reagierten. Aber dann gucken wir mal nach vier Wochen drauf und reagieren dann und adaptieren im Zweifel wieder, dass das in der Medienlandschaft nicht so ungefähr ging. Verstehe ich. Aber zurück. So schwierig das Thema ist, natürlich Pandemie zu argumentieren. Und ich will da um Gottes Willen keine falsche Diskussion aufmachen. Aber. ein Verständnis zu haben, dass wir stand heute wesentlich besser das Thema im Griff haben, nämlich quasi Stacey-Matrix-mäßig von oben rechts nach unten links gewandert sind. Und wir heute ja auch offiziell die Pandemie beendet haben, weil wir über entsprechende Maßnahmen, weil wir das Zeug besser in den Griff bekommen haben, weil wir das Was auf der Stacey-Achse besser verstanden haben und das Wie in der Umsetzung besser verstanden haben. Also von daher, das nutze ich nach wie vor ganz gerne, um den Unterschied zwischen Komplexität und Komplizität zu erklären. Harald Wild: Jetzt hast du gerade gesagt, dass du das quasi an der Story festmachst. Also das heißt, du erzählst eine Geschichte um Komplexität greifbar zu machen. Das ist ja trotzdem eine Form von Wissensvermittlung. Wie schätzt du denn die Wichtigkeit von Wissen methodisch und fachlich ein, bevor man oder wenn man in eine agile Produktentwicklung startet? Da ist ja erstmal in Unternehmen häufig, sage ich mal, nichts vorhanden oder wenig vorhanden. Wie ist der Einstieg in die Wissensvermittlung? Vor allem muss ja aus dem Wissen irgendwann können werden. Wenn man jetzt gerade mal so in die Product Owner Ecke geht, da macht jemand dann vielleicht den klassischen, die Zertifizierung. Das ist ja dann so ein bisschen der Blick durch den Spalt in der Tür, in die bunte Welt der Agilität. Mehr vielleicht auch nicht. Um aber wirklich, sage ich mal, Product Ownership zu zeigen und zu haben, ist ja da doch einiges an Erfahrung und Können notwendig. Wie würdest du den Weg sehen von? jemanden, der damit startet und das aber dann in eine Richtung entwickeln will im Unternehmen, die dann auch werthaltig ist oder auch im Endeffekt diesen Wertstrom erzeugen kann, den man gerne hätte. Tim Klein: Ich glaube, wir sind mittlerweile weiter, also wir sind ja nicht mehr an dem Punkt, dass alle Unternehmen sozusagen bei Null starten. Also viele Unternehmen haben schon erste Transformation oder Agilitätserfahrung. Wir kriegen Mitarbeitende von außen, die schon an anderen Unternehmen mehr oder weniger gute Agilitätserfahrung gemacht haben. Immer klarer wird, glaube ich, zumindest in unserer Blase, dass so ein alleines zweitägiges Training, Zertifizierungstraining. nicht viel mehr ist als, wie der Kollege Ralph Kruse immer sagt, ein amerikanischer Führerschein. Du hast die Berechtigung sozusagen mit dem Zertifikat, aber noch kein Können. Du kannst deshalb noch nicht fahren. Das heißt, um auf deine Frage zurückzukommen, ich glaube, es ist zunehmend wichtig, sich als Transformationsverantwortliche klarzumachen und das auch in die Organisation reinzukommunizieren, dass wir ex ante nicht alles wissen. Und das ist, glaube ich, ein großer Shift zu klassischem Vorgehen. Also wo Führungskräfte eben früher auch ganz klar, also Leadership verstanden wurde im Sinne von gibt eine Führung vor, wir wissen, was wir wollen. Die geben neue Entscheidungen, neue Organisationen, neue Struktur vor. Und dann läuft die Organisation da lang. Ich glaube, da ist der große Shift zu sehen, dass wenn heutzutage modernes Leadership, agile Führungskräfte loslaufen. müssen und sollten sie auch der Belegschaft klar machen, wir wissen selber noch nicht, wie wir vorwärtskommen. Wir können definieren, wo die Vision ist, wo wir hin wollen. Also das war es, was wir für Wirkungen erzielen wollen mit den Maßnahmen. Aber da wir uns im komplexen System befinden, sobald wir mit Menschen zusammenarbeiten, kann man das halt eben nicht mit einem Projektplan erschlagen. Also ich kann Agilität nicht mit klassischer Planung einführen, das ist ein No-Brain-Eye. Das heißt, wir müssen die Organisation auch schon als Produkt verstehen. Produkt im Sinne von wir liefern Releases aus. Mal ein Major Release, das kann eine Org-Struktur sein, und dann vielleicht Minor Releases, um eben Adaptionen vorzunehmen, nachdem wir was gelernt haben. Und das ist, glaube ich, eine große Herausforderung für Führungskräfte oder für entsprechende Transformationsteams oder wie wer auch immer das in die Hand nimmt. Dafür vertrauen sowohl auf den... Ja, in der C-Suite, also auf dem Top-Management-Level, als auch in der breiten Belegschaft zu bekommen, dass man sich auch Zeit nimmt. Ich glaube, dass das weitere große Thema, dass viel zu viel Ungeduld bei so was vorhanden ist und dass man das letztlich grundsätzlich als Riesen-Change-Vorhaben versteht. Und eben, es gibt keine Gurus, die wissen, wie es genau für diese Organisation funktioniert. Deshalb bin ich ein riesen Skeptiker von allen Blueprint-Ansätzen, die sagen, hier, das ist das Skalierungsframework, was du benutzen musst. Also diese Simplifizierung und Vereinfachung, die man auch häufig dann bei Anbietern im Netz findet, die machen wir große Sorgen. Und Timoto, ist alles so einfach hier und agil wird man schnell eben eingeführt und kannst du in drei Monaten und ist Bullshit. Sorry. Es geht nicht. Harald Wild: Jetzt hattest du gerade gesagt, C-Suite, was muss aus deiner Sicht denn die C-Suite beachten, wenn sie solche Veränderungsprozesse durchführen will, umsetzen will, umsetzen lassen will, wobei man damit ja schon vorsichtig sein muss. Was ist der Mindset oder was ist das Wissen, was die C-Suite braucht, um zu gewährleisten, dass auch die Organisation unter ihnen wachsen kann und entsprechend sich weiterentwickelt. Tim Klein: Also erstmals sollten diese Menschen selber versuchen, Wissen aufzubauen über das, was sie da entscheiden. Nämlich viel zu oft wird da, glaube ich, was entschieden ohne grundlegendes Wissen und dann wird so ein bisschen die Büchse der Pandora geöffnet. Nach dem Motto, wir führen mal schnell Scrum ein und wir heißen jetzt alle Product Owner. Also nach dem Motto, aus, ne, Rider heißt jetzt Twix, sonst ändert sich nichts. Also sprich, die bisherigen Projektleiter heißen jetzt bitte Product Owner und blups, wir sind agil. Was ein Bullshit. Leider schon oft genug gesehen. Am besten per Hammerschlag mit 100 Teams auf einmal und zum Chaos verurteilt. Was sollten Sie also tun? Erstens Wissen aufbauen, zweitens der Organisation Zeit geben, drittens den handelnden Personen Vertrauensvorschuss geben und auch dabei deutlich machen, dass man sich auch irren kann und dass Fehler zulässig sind. Ich bin übrigens kein Freund des Begriffs Fehlerkultur. auch wenn er weit verbreitet ist, also eine neue Fehlerkultur schaffen, bla bla bla. Ich glaube, kein Mensch macht gerne Fehler. Ich möchte das gerne umframen und von einer Lernkultur sprechen. Das heißt, eine Lernkultur im Unternehmen ausrufen und sagen, okay, wir gewinnen Insights, wir machen Learnings, also sprich, wir rennen mal gegen die Wand. Aber ich würde das nicht als Fehler, sondern als Lernoption verstanden wissen und sagen, toll, dass wir das jetzt gelernt haben. Lass uns das. adaptieren. Lass uns das anpassen. Lass uns natürlich nicht nochmal gegen die gleiche Wand laufen. Also das sind so meiner Ansicht nach die Key Facts, also Zeit slash Geduld, Vertrauen, das natürlich zurückgezahlt werden muss. Also machen wir uns nichts vor. Also wie gesagt, das ist kein Selbstbeschäftigungsvorhaben hier, Transformationsteams. Da muss auch ein Ergebnis bei rumkommen. Da bin ich ganz im Herzen BWLer und sag, wie gesagt, ich bin Kaufmann. Also das das nicht aus Spaß und Freude, sondern wir machen das, damit unsere Organisationen robuster werden, dynamikrobuster werden in komplexen sich ändernden Märkten. Und das Beispiel, jetzt haben wir seit, schlagt mich tot, was, acht Monaten Open Air, acht, neun Monaten, Clash of Duty und Co. Also jetzt so an der Oberfläche, das Zeug gibt es ja schon viel länger, aber das ist ja nur der Anfang der Disruption, was da passieren wird. Und darauf muss eine Unternehmung mit seinen Produkten und Und das meine ich so mit Robustheit oder Resilienz. Das... Also, ich finde dieses Bild, ich glaube, von Jürgen Appello war das mal ursprünglich, mit Barbara Papa. Also, die Eltern unter uns, wir hier unter uns kennen ja noch vielleicht Barbara Papa, diese Zeichentrick-Serie. Das war ja ein Formwandler, dieser Blob oder was das war. Er konnte Herausforderungen und... wie war es, Abenteuer lösen, indem sich diese Kunstfigur in unterschiedliche Formen wandelte. Und ich finde dieses Bild, das ist schon etwas älter, aber ich finde das nach wie vor total klasse, dass man das so ein bisschen auf Unternehmen überträgt und sagt, wir müssen wandelbar bleiben und nicht nur so als Bullshit-Satz, sondern wir müssen wandelbar und anpassbar an neue Rahmenbedingungen werden. Und das Thema AI ist ein super Exempel, wo wir sehen werden, wie wandelbar und robust Organisationen sind. Mike Leber: Jetzt würde ich da gerne mal kurz einhaken, Tim, und zwar dabei, du hast schon bis so gewesen gerade alle Punkte aufgezählt, auf die es ankommt. Wir müssen uns zu einer Produktorganisation wandeln. Bei Produkten geht es ja um Kunden angeblich, das ist irgendwie auch ein Kundenverständnis nötig. Und bei der ganzen agilen Sache hat man ja zu Anfang schon einmal eine essentielle Sache reingeschrieben, nämlich Businessleute und IT-Leute müssen jeden Tag permanent miteinander arbeiten. So, jetzt würde gerne einer Sache auf den Grund gehen, nämlich viele Organisationen, da kennst du wahrscheinlich auch ein oder zwei, haben ja sowas wie eine IT-Organisation. Und dann reden die von Fachbereichen. Und dann kommt ja der ganze Rattenschwanz, den wir kennen, da wird erstmal was über den Zaun geworfen, Anforderungen werden dekliniert. Ich glaube, amerikanische IT-orientierte Produktanbieter kennen ja sowas gar nicht mehr wie einen Fachbereich. Ich rede jetzt von denen aus dem Silicon Valley, die IT-Produkte herstellen. Und dann gibt es ja das Gerücht, dass heutzutage jedes Produkt irgendwo ein Softwareprodukt ist. So. Wie gehst du... Also erst mal, was sind deine Einschätzungen in solchen Situationen, wenn wir von Agilität sprechen, wenn wir wirklich zu einer Produktorganisation werden wollen? Also wie kommen denn dann dorthin, wenn wir, wenn wir zwischen denen das tun sollen? Also die IT-Fachleute. und denen, die es letztlich verwenden sollen, also den eigentlichen Kunden, erst mal dieses riesen Gap ist. Wenn der Kunde der Fachleute eigentlich in der Fachbereich ist, also der IT-Fachleute, wie löst sich das deiner Meinung nach irgendwann mal auf? Tim Klein: Ich fange mal beim Kundenbegriff an. Der Kundenbegriff ist für mich, da habe ich eine relativ klare Mike Leber: Und was fährt die Transformation an? Tim Klein: Meinung, immer damit verbunden, also Kunde oder Nutzer, mal in einer Person, mal in mehreren. Das sind die Menschen oder Organisationen, die uns Geld dafür bezahlen, dass sie unser Produkt oder unseren Service nutzen. Ich mag es nicht, von internen Kunden zu sprechen. Das sind Stakeholder, aber das sind nicht unsere Kunden. Es können Nutzer sein. Ja, wenn wir Enabling Products schaffen, meinetwegen irgendwelche Cloud Platform oder sonst was. Ja, dann haben wir vielleicht interne Nutzerinnen und Nutzer. Das gehe ich noch mit. Aber das ist den Kundenbegriff. Da bin ich ein bisschen allergisch, den intern zu verwenden. Aber das ist jetzt nur so ein Randthema. Ich hänge da der der Idee von Empowered Teams an und Empowered Teams ist nur das eine, das ganze. Also eigentlich so ein Product Organization Model zu verfolgen. Das ist noch relativ jung, relativ in den Kinderschuhen. Also vieles von dem sieht man so in den Büchern und Blogposts von Martin Keggen sehr stark. Der sehr stark immer unterscheidet zwischen The Best Companies und The Rest. Und The Rest ist eigentlich immer damit beschrieben, dass so ein Organisationsmodell, wie du es skizziert hast, nach dem Motto IT ist ein interner Dienstleister. schlimmsten Fall noch Cost Center oder sonst was, eine Enabling Function. Solange das gesehen ist, sind wir weit weg von einem produktzentrierten Organisationsmodell. Ich glaube, das hatte der glaube ich in der Diskussion mit dem EPA, wie heißen sie? Gesso auch, im Call, IT ist Business. Also ich glaube, da müssen wir hinkommen. IT ist genauso ein Teil von Product, wie es Fachlichkeit, wie es Regulation, wie es Legal, wie es whatever ist. Ich hänge grundsätzlich an diesem Verständnis ein Product oder Service. ist für mich ein Zusammenspiel aus drei Dimensionen, nämlich User Dimension, Technical Dimension und eben Business Dimension. Und solange wir nur über die IT diskutieren oder über Technical Product Manager, Technical Product Owner, hängen wir viel zu stark in dieser technischen Domäne. Ich glaube, wir müssen uns alle bewusst sein, dass nur dieses also Theresa Torres sieht da eher so ein Trio, so aus Product, aus User-Verständnis und aus IT, so kann man das ein bisschen in Analogie sehen. Das ist nur dieses Zusammenspiel aus dem User-Verständnis, also ein Verständnis über die Probleme unserer Kundinnen und Nutzer, für die wir antreten, sie zu lösen. Ein Verständnis über die Business-Domäne, das heißt, what serves the business, was brauchen wir mit unseren Produkten? im Endeffekt ein wirtschaftlich tragfähige viable products werden und dann vielleicht erst oder dieser Dreiklang und dann ist da eben auch noch die technische fachlich technische Umsetzung, also die feasibility und ich glaube die die problematik die wir haben dass das ganze thema agilität viel zu stark letztlich groß geworden ist im IT umfeld also das IT-organisation Heaviness, Crumb, wir machen Safe, wir machen Kann-Mann, wir machen Blob. Da sind auch sehr viele IT Menschen oder Menschen mit IT Background in diese Rollen, meinetwegen in Product Owner Rollen, reingewachsen und haben diese Rollen auch sehr technisch dann ausgelebt. Ich glaube, davon müssen wir weg. Ich habe letztens so eine Diskussion geführt nach dem Motto, brauchen wir Technical Product Owner? Ich sage, warum brauchen wir dann nicht zusätzlich auch User Product Owner oder Business Product Owner? Also warum nur diese eine der drei Dimensionen? Mike Leber: Hm. Tim Klein: Kekes Beispiel. So und dieses Verständnis, also wenn ich zum Beispiel mit einem als Diplomkaufmann mit Business Background herkomme und sage, okay, plus ich habe irgendwie in wischen 23 Jahre in der IT oder IT Nage gearbeitet, dann habe ich Business Domäne ganz gut im Griff. Ich habe viel Erfahrung in der IT Domäne, aber meine Schwachstelle ist am ehesten die User Domäne. Das muss ich mir bewusst machen und das mache ich mir bewusst und ich gucke ganz explizit. in die Richtung nach dem Motto, wie kann ich da noch mehr lernen? Wie kann ich da noch mehr Erfahrungen sammeln? So und das jetzt bezogen auf deine Frage auf Organisation. Ich glaube, wir müssen uns viel stärker fragen als Organisation. Wo sind unsere organisatorischen Schwachstellen in diesen drei Domänen? Und IT ist selten die Schwachstelle, also dass wir zum Teil bessere IT bauen können, geschenkt. Aber die wirtschaftliche Tragfähigkeit von Feature-Entscheidungen zum Beispiel besser zu reflektieren und nicht so hippomäßig wünscht dir was. Wer am lautesten schreit? Sprich, die hypothesenbasierte Produktentwicklung einfließen zu lassen im Sinne von welche Annahmen haben wir eigentlich, wie businesskritisch sind diese Annahmen, wenn sie nicht zutreffen? Wie viel Evidenz haben wir eigentlich durch Userbefragung oder andere Business-Testing-Geschichten überhaupt schon erzielt? ist es uns überhaupt wert, diese Wette, die wir ja eigentlich immer eingehen, mit der Product Delivery dann umzusetzen. Also ich glaube, die meisten aller meisten Organisationen, nach meiner Beobachtung, haben immer noch das Riesenproblem. Wir brauchen folgende Anwendung. Wir benötigen unbedingt dieses Feature oder interne Stakeholder. Sie sagen, wir glauben, wir wissen, was die Kunden wollen. Wir müssen die Kunden nicht befragen. Das ist ja das Schlimmste. Wir brauchen die Kunden nicht befragen. Wir wissen als Vertriebler, als whatever, als Business Developer, was die Kunden wollen. What the fuck? Mike Leber: Hm. Tim Klein: Entschuldigung, darf man das sagen bei euch? Was für ein Blödsinn, ja? Wir glauben zu wissen, was die wollen. Wir können uns so dermaßen täuschen. Und ich war selber mit beteiligt bei großen Umsetzungen, wo wir sechs Monate in die falsche Richtung entwickelt haben. Verdammt, es war für die Katz. Es hat kein bisschen an Return verbessert, wo wir einen Mike Leber: Vielen Dank. Tim Klein: ein Team komplett sechs Monate haben drauf arbeiten lassen. Was sind das für Kosten? Da gucken wir nie hin. Das sind Zahnkosten. Ist ja schon in einer großen Organisation projektmäßig verbucht, schön budgetmäßig verbucht. Das ist keine Ownership. Sorry, kriege Emotionen. Mike Leber: Sie hätte noch eine Frage hinterher. Harald Wild: Hahaha. Mike Leber: Ein bisschen in die Praxis. Wie löst du das am Ende aufnehmen? Ich glaube, die meisten Coaches in dieser ganzen agilen Domäne, kennt man ja, würden gerne, verstehen das auch so wie du. In der Realität treffen sie dann halt andere Möglichkeiten an und geben sich geschlagen. Aber ich glaube, immer mehr sagen dann irgendwann einmal, okay, ich suche mir jetzt das Projekt mal so aus, dass ich es zumindest einmal von Anfang an klar mache, was es braucht, damit da etwas Sinnvolles rauskommt. Wie würdest du da reingehen? Weil wir gehen mal davon aus, das aufzulösen ist ja auch wieder keine kognitive Frage, sondern ich würde mal die Hypothese in den Raum stellen, vorrangig eine politische. Da geht es doch um wahnsinnig viel Macht. Also wenn wir sagen, IT und Fachbereiche, jetzt legen wir das mal zusammen, das muss eins sein. Da hast du sofort jede Menge Gegenwinde. Wie gehst du da rein oder was würdest du da raten? Tim Klein: Also ich setze nochmal an den Punkt an Produktverständnis herstellen. Also Verständnis, dass wir hier in Produktentwicklung und nicht in Anwendungs- oder Softwareentwicklung sind. Das ist vielleicht nur ein kleiner, simantischer Unterschied, für mich aber schon entscheidend. Zweitens verstehen, dass wir eben über den gesamten Produktlebenszyklus Ownership Verantwortung übernehmen sollten. Und das als ganze Company. Ich glaube, es ist offensichtlich, dass die Nutzerinnen und Kundinnen unserer Systeme oder unsere Produkte und Services derende ist. egal wie sich eine Organisation intern organisiert. Also sorry, gibt es entsprechende Gesetze ja sogar zu oder Beobachtungen, dass sich dann auch Produkte oder Systeme und Architekturen so verhalten, wie die Organisation sich aufgestellt hat. Nee, ich glaube, wenn man von dieser Produktdenke her kommt, also das ist glaube ich schon der erste wichtige Shift, in Produkt zu denken, in Nutzerverständnis zu denken und dann in Hypothesen zu denken, also dieser Dreiklang, Wir wissen nicht, was der Kunde braucht. Wir versuchen zu verstehen, das Kundenproblem zu interpretieren und das Kundenproblem zu verstehen. Das Schwierige ist ja, der Kunde, der Nutzer, der weiß ja selber nicht, was oftmals sein Problem ist. Oder er kann es, sie kann es schwer selber formulieren. Meistens kommt ein Kunde ja eher drauf, Lösungswünsche, Feature-Wünsche zu formulieren. Aber das dahinter liegende Problem... ist schwer zu greifen. Da bin ich ein Riesenfan von so Sachen wie Jobs to be done Ansatz etc. sich damit zu beschäftigen, um, du sagst es ist ein kultureller Change, dann auch irgendwie zu verstehen, dass wir nicht alles wissen innerhalb der Organisation, dass wir rausgehen müssen, get out of the building, lass uns befragen, lass uns beobachten. Dann zweitens, ich glaube, wir müssen einfach verstehen, dass wir in den Organisationen besseres Verständnis für modernes Produktmanagement brauchen. Ich führe das weiter und sage, also meine Beobachtung, ist jetzt vielleicht eine steile These, ist, dass die ganze agile Szene einen riesen Lack hat darin, Produktmanagement zu verstehen. Sorry, aber die meisten, die Product-Owner-Trainings geben, ich meine mal ganz spitz, haben wahrscheinlich noch nie als Product-Owner gearbeitet. Geschweige denn als Produktmanager. Und Product-Owner ist eine Rolle in Framework Scrum. Produktmanager wäre für mich der Job. Wer von uns hat denn wirklich echte... Produktmanagement-Erfahrung, also Skin in the Game, mal gehabt. Ich glaube, da haben wir einen riesen Nachholbedarf. So. Und einfach nur, ich bin, ihr wisst, wir von den Produktwerkern, wir machen einen kompletten Podcast rund um die Rolle Product oder die Verantwortlichkeit Product Owner und agile Produktentwicklung. Aber uns ist in den letzten drei Jahren mehr und mehr auch klar geworden. Es geht nicht um die Rolle, es geht um... um das Thema agiles Produktmanagement, überhaupt Produktmanagementverständnis reinzubringen in die Organisation. Und dann bist du wieder beim gleichen Punkt, in Produkten zu denken, kundenzentriert zu denken, aber auch eben, dass es der Organisation dabei gut geht. Sorry, jetzt kriege ich wieder Emotionen direkt. Also ich glaube, dass da ein Riesen-Lag ist und ich muss allerdings auch umgekehrt sagen, meine Beobachtung ist auch vielleicht ein bisschen spitz formuliert, aber das umgekehrt in der Produktmanagementszene, in der ich mich inzwischen viel mehr rumtreibe. umgekehrt, aber auch ein Riesen, wie soll ich sagen, Bedarf an Agilitätsverständnis ist. Also ich habe am Anfang immer gedacht, ah, die sind so ein bisschen beyond agile, also bei denen kommt es nicht mehr darauf an, ob du Scrum-Cumbern machst, sondern die sind schon weiter. Nein, ich beobachte, dass da auch fürchterliches Nichtwissen zum Teil ist, oder Falschwissen, oder sehr verkürzt gebashed wird auf Mike Leber: Beispiel. Tim Klein: Naja, Beispiele des erfahrenen Produktmanager von einer sehr, sehr großen Company, sogar dann als Product Coach unterwegs, beim Begriff Kanban mich fragte, ist es das, was bei Toyota in Autoproduktion eingesetzt wird? Also das ganze Thema, man muss jetzt nicht Kanban-Experte sein im Sinne von Kanban in der Wissensarbeit, aber das zumindest zu kennen. Also die ganzen Ansätze, auch von Flight Levels. Zweites Beispiel ist, dass es in der Product Management Community ein Riesen-Bashing auf Product Owner gibt. Also Product Owner ist bad in der Product Management Szene. So kannst du das verkürzt sagen. Sehr stark verkürzt. Weil die einfach sagen, sorry, das ist einfach nur Delivery. Und ja, als Agilisten müssen wir uns diesen Vorwurf auch aussetzen und sagen, ein Framework wie Scrum ist komplett Delivery orientiert. Wo ist eine Discovery? Wie kriegen wir... inkorporieren wir Discovery-Aktivitäten, um zu einem kontinuierlichen Discovery-Habit zu kommen, wie Theresa Tories es fordert. Da sind wir in der agilen Szene noch verdammt schwach und alles, was um agile Transformation und so rumtunt, also auch Coaches, Berater, etc. Wer bringt denn da Product Coaches mit? Wer bringt denn da Produktmanagementwissen ein? Also ich würde sagen, zumindest in der Dachregion ist es noch verdammt, verdammt wenig. Mike Leber: Was sollte sich da ändern? Harald Wild: was ja noch dazu kommt, ist ja, dass das Wissen über das Produktmanagement im gesamten Unternehmen nicht wirklich gut verteilt ist. Das ist ja das eine. Aber was ich auch sehr interessant fand, war die Aussage, dass es wechselseitig so ist. Entweder ist das Wissen über Agilität, also über die Methodik, wie gehe ich vor, oder eben über das Produktmanagement, wie erstelle ich gute Produkte für Kunden, dass das wechselseitig nicht vorhanden ist. Ich würde aber gerne noch mal reingreifen. Und zwar hattest du vor kurzem, glaube ich, auch mal Austausch auf LinkedIn dazu. Wie siehst du denn das Know-how, dass ein Product Owner braucht im technischen Bereich? Also das heißt, muss ein Product Owner in dem Fachgebiet, in dem er unterwegs ist, muss er da viel Wissen mitbringen? Oder ist es nur ein Vorteil oder braucht er das gar nicht? Wie siehst du es denn an der Stelle, wenn man jetzt so auf der einen Seite Product Management, auf der anderen Seite Product Owner? und die Technik mal die dritte Seite aufmacht. Wie viel Wissen braucht ein Produkt oder über die Sachen, die er da holt. Tim Klein: Ja, das war eine Diskussion, wie viel Domainenexpertise braucht ein Product Owner? Und meine These ist grundsätzlich, braucht er das nicht? Also ich würde mich jetzt mal ganz frech hinstellen, ich nehme mal so regulierten Bereich aus, das ist vielleicht was anderes, aber ich würde mich hinstellen und sagen, wenn ich mit Produktmanagementmethodik ausgestattet bin, mit Produktmanagementerfahrung, grundsätzlich auch mit dem Wissen, zum Beispiel über so ein Framework wie Scrum als Beispiel. dann kann ich erstmal per se so eine Product Owner Rolle umsetzen. Auch ohne Top Experte zu sein. Warum? Weil ich doch bitte das Verständnis habe, kollaborativ mit meinem Team gemeinsam Product Ownership zu etablieren. Und das heißt, keine One Man Show bin oder One Woman Show bin, sondern dieses Wissen, dieses technische oder dieses domän, fachliches Domänwissen, das muss natürlich in meinem Team drin sein. Das ist der Nachsatz dabei. Also wenn ich von einem cross- funktionalen Scrum-Team rede, dann rede ich nicht über Software-Engineers nur da drin. Also wir hier glaube ich alle drei nicht, sondern über cross- funktional aufgestelltes Team, wo im Endeffekt die Expertenbereiche abgedeckt sind. Das heißt, ich muss als Product Owner, mir muss bewusst sein, was ich nicht weiß. Und so wie das eine UX-Ecke ist, mag das in einer technischen Ecke sein und mag das in einer fachlichen Ecke sein. Dann muss ich natürlich möglichst schnell mich dann da reinarbeiten. ausruhen, so wie ich mich in eine technische, in eine fachliche New-Ex-Perspektive reinarbeiten muss, um diesen Markt, um diese Domäne immer besser zu verstehen. Aber es ging um die Frage, ob das sozusagen eine Grundvoraussetzung ist, um ein guter Product-Owner zu sein. Jetzt mal so sehr stark verkürzt, das ist ein bisschen aus dem Zusammenhang gerissen. Und da würde ich behaupten, sind die methodischen Fähigkeiten und die Erfahrung im Produktmanagement und die Denke, hypothesenbasierter Entwicklung von Produkten, wichtiger. als das Fachwissen, was ich eben auch von anderen Menschen in so ein Team reinbringen kann. Mike Leber: Das würde ich gerne challengeen. Ich verstehe, wo du herkommst, ich kann das nachvollziehen. Klingt für mich so, als würde man sagen, du brauchst in einer Fußballmannschaft nicht unbedingt Stürmer, die Tore schießen können. Irgendwie wird es selbst der Tormann und wäre auch immer noch dazu beitragen, dass man scoret. Aber wenn ich jetzt noch mal, ich zoome da ganz gern zum Vergleich, in den Bereich Silicon Valley, würde ich jetzt bei Google anheuern wollen Tim Klein: Hm. Mike Leber: und sagen, von Technik habe ich jetzt nicht grundsätzlich viel Ahnung. Aber ich verstehe, was eure Kunden wollen. Und da kann ich mich wunderbar einbringen. Ich glaube, ich kriege den Job nicht. Soweit ich nehme, ich weiß, muss selbst ein Senior Manager dort zeigen, dass er coden kann. So und jetzt frage ich mich ja doch jetzt kommt ja AI auch um die Ecke. Es geht ja nicht nur um das Erleben der Kunden, sondern es geht ja um die Idee zu verstehen, wie führe ich die Fäden zusammen oder oder verstehe da was falsch? Ich meine, ich könnte jetzt natürlich sagen, hey, ich bin wie ein CEO. Ich bin Steve Jobs. Ich weiß, wie die richtigen Leute an den Tisch bringen und mein. meine Vision in die Welt setze. Aber fehlt dann etwas, wenn ich nicht das technische Know-how habe und mich womöglich entschuldige und sage, naja, ich komme aus dem Fachbereich und bin halt Product-Homer geworden. Tim Klein: Ich finde das immer tatsächlich ein bisschen gefährlich, direkt mit Google zu argumentieren, weil die wenigsten Unternehmen, mit denen wir hier arbeiten oder in denen wir sind, sind Google-like. Ich möchte Google gar nicht absprechen, dass das eine tech-driven-Company ist und über ganz andere Mechanismen auch geführt wird als viele Unternehmen hier. Und Google hat nicht viel mit Agilität zum Beispiel zu tun, würde ich behaupten, ohne jetzt selber daran gearbeitet zu haben, aber die haben andere Ansätze. Oder Amazon. Ich kann das Argument nachvollziehen, dass man sagt, okay, es muss eine riesen technische Expertise vorhanden sein. Aber was ist denn dann das Gegenargument, dass man sagt, ja, und warum muss keine extreme User-Perspektive oder User-Kennnis vorhanden sein? Also für mich ist es wiederum nur eine dieser drei Dimensionen. Und moderner Produktmanager ist oder Produktmanagerin ist für mich eine Person, die diese drei Dimensionen mit an einen Tisch bringt und vereint und dafür eben... Ich weiß nicht. Ich glaube, es kommt nicht auf das Wissen zwischen diesen zwei Ohren an, sondern es kommt eher auf die Fähigkeit an, Menschen zusammenzuführen. Weil gerade in der komplexen Welt brauchen wir so viele unterschiedliche Erfahrungshintergründe und Blickwinkel, die wir zusammenführen müssen. Und dementsprechend auch das, was du mit AI ansprichst. Ich muss verstehen können und komplex denken können im Sinne von, wie verbinde ich das alles? Also... bin ich in einem Umfeld, und da bin ich wieder ganz bei dir, Mike, bin ich in einem Umfeld, wo die Tech-Expertise mission critical ist? .. dann bin ich bei dir, dann muss ich mich da... .. sehr technisch orientieren als Product Manager. Wenn ich aber in einem sehr umkämpften Markt bin, Blue Ocean, oder in einem sehr neuen Marktsegment und wir noch sehr wenig wissen über Nutzerverhalten, ich glaube, dann ist nicht die Technik der USP, sondern eigentlich das beste Problemverständnis unserer Nutzerinnen und Nutzer. Und wenn wir kein gutes Verständnis von einem vernünftigen Viability-Ansatz, also Business Case mal verkürzt gesagt haben, also wie wir wirtschaftlich tragfähig was umsetzen können, hilft uns das auch nicht lange weiter. Also was hilft jetzt? Die beste Technik, meinetwegen auch mit AI, vielleicht auch das beste User-Verständnis, wenn wir es zum falschen Preispunkt anbieten und damit halt... Keine Ahnung, nach einem halben Jahr oder nach einem Jahr unser VC-Money oder sonst was verbrennen und dann wieder draußen sind, wenn wir jetzt mal vom Start-up her denken. Also ich glaube, diese Ausgeglichenheit dieser drei Dimensionen, ich komme immer wieder gerade auf den Punkt zurück, merkt ihr ja, ist für mich ganz entscheidend. Und nochmal, warum muss ich denn als Product Manager oder Product Owner diese Top-IT-Expertise haben, wenn ich in einem, ich sage jetzt mal normal ausgeglichenen Produktumfeld unterwegs bin? Lass uns das gerne weiter diskutieren. Mike Leber: Jetzt haben wir schon viele gute Weichenstellungen gelegt, angefangen bei deiner eigenen Entwicklung Harald Wild: Vielleicht. Mike Leber: und das, was du so aufgezogen hast, was den Unternehmen auch helfen kann, auf was sie achten sollten, wenn sie Product Manager, Product Owner empowern. Ich würde nur gerne dazu legen, welche Eigenschaften sollten Product Manager Owner nicht haben. Das macht es nämlich oft einfacher, ein bisschen draufzuschauen, was sollten wir vermeiden. Tim Klein: Schöne Frage. Glaube... Also man muss eine ausbalancierte Art haben. Roman Pichler hat das mal als Balanced Product Leadership beschrieben. Das fand ich ganz treffend in dem Blogpost von 2018. Eine ausbalancierte Art, zwischen den Extrempositionen Feature Broker, also nur dafür da zu sein, zu Anforderungen von Stakeholdern zu dispatchen ans Team. Und auf dem anderen Extrem war dann abgebildet, im Endeffekt so Product Dictator zu sein, nach dem Motto Le Terser Moi. Ich weiß genau, was Phase ist und ich höre gar nicht hin. Das heißt übertragen, ich glaube Ignoranz wäre schlecht. Also das sollte man nicht sein ignorant als Product Manager. Ich glaube es ist ganz schlecht, wenn ich Menschen nicht zuhöre, selbst wenn ich die auf der Beziehungsebene nicht mag, aber sie können immer noch recht haben. Also es ist so diese These sei dein größter Kritiker, wenn du Feedback empfängst. Sei dein größter Fan oder Fan des Produktes, wenn du über das Produkt sprichst, über dein Vorhaben, aber sei der größte Kritiker, wenn du Feedback empfängst und verteidige dein Baby nicht, was schwer genug ist, sondern die könnten ja Recht haben. Das heißt, eine gesunde Selbstreflektion ist wichtig oder andersrum, wenn ich die nicht habe, weder schadhaft. Zweitens, sich selber zu behöhen im Vergleich zu den restlichen Teammembers wäre. Das wäre genau wie so in der Fußballanalogie zu bleiben ein Spieler oder eine Spielerin, die sich selber als Superstar sieht und gar nicht das Team mitnimmt, weil Produkt ist halt auch Teamsport, so wie beim Fußball. Wir können nur zusammen gewinnen. Und dementsprechend wäre eben schlecht, das war ja die Frage, verschlossen zu sein, sich nicht weiterzubilden, nicht offen zu sein für neue Lösungsideen. sind wir auch wieder bei AI und solche Sachen, ich muss das beobachten. Ich kann nicht sagen, ne, ne, das brauchen wir unser Produkt nicht oder das haben wir noch nie gemacht oder das haben die Kunden. So und eben genauso auch schlecht verschlossen zu sein gegenüber User Feedback, sprich gar nicht rauszugehen aus dem Gebäude, gar nicht Nutzerinnen mal zu befragen, mit welchen Techniken auch immer, sondern was ich eingangs sagte, zu glauben, zu wissen. Das ist, glaube ich, eine der Schwierigkeiten, sowohl in der Produktmanagementrolle, aber auch bei Stackholern erleben wir das ja sehr viel. Also, dass Leute rankommen und sagen, wir brauchen das Feature, wir brauchen das Produkt, das Projekt, das rettet uns den Hintern. So, gerade wenn Firmen an der Wand stehen, dann noch schlimmer. Also, ich glaube, das ist in Summe, noch mal positiv andersrum formuliert, brauche ich eine große Empathie in der Rolle. Menschenkenntnis und die Möglichkeit, Menschen auch in Gruppen zu verbinden und gemeinsame Diskurse, also kollaborative Kommunikation und so auszulösen, das ist auch in der Produktmenschher Rolle, glaube ich, ganz wesentlich. Also ich bin Gastgeber dann für viele am Tisch, so der Thomas Gottschalk, der Wissen am Tisch bringt, aber entscheidet. In allerletzter Konsequenz entscheide ich. Am schönsten ist, wenn ich eine Community habe, eine stakeholder Community, mit der ich zusammen entscheiden kann. Aber in Zweifel muss allen klar sein, ich bin nicht die Flipperkugel, sondern wenn ihr euch nicht einigen könnt in einem bestimmten Timeslot, dann entscheide ich halt. Weil ich eine wirtschaftliche Verantwortung habe, auch für den Produkterfolg. Harald Wild: Jetzt haben wir ja ganz viel über den Product Owner gesprochen und die Rolle und welche Eigenschaften, Muster haben. Wenn wir jetzt mal wieder ein bisschen rauszoomen auf das Unternehmen oder auf Anforderungsbearbeitung oder eigentlich, sage ich mal, Umsetzung von Anforderungen. Das ist es ja, wenn man ganz weit rauszoomt, ist es, ist es das ja eigentlich, wie setze ich Anforderungen an etwas so um, dass es werteilig ist, dass der Outcome gut ist und Letztendlich ist ja alles irgendwie Anforderungsbearbeitung. Das heißt eigentlich, ob ich jetzt arbeite und mein Tagesgeschäft erledige, wie man das so schön nennt, oder ob ich eine Software entwickle. Am Ende sind alles irgendwie Anforderungen bzw. ist das jetzt auch die Frage, wie kann denn die Organisation oder das Systemunternehmen von agiler Produktentwicklung lernen und sind das aus deiner Sicht überhaupt ähnliche oder gleiche Prinzipien, wenn es um ein wertehaltiges Produkt und dessen Entwicklung geht oder wenn es um. Tagesgeschäft und die eigene Arbeit oder die Arbeit von Teams geht in Unternehmen. Tim Klein: Hm, als du die Frage so formuliert hast, habe ich die ganze Zeit gedacht, müssen wir nicht überhaupt den Begriff Anforderung reframeen? Also ist überhaupt die Bezeichnung Anforderungsmanagement nicht schon falsch? sondern vielleicht müssen wir eher in Problemmanagement, also jetzt Kunstwort, so Problem Understanding kommen und... die Nutzer besser, Nutzerverständnis zu verstehen. Weil Anforderungen, das suggeriert doch wieder dieses Bild, dass jemand vor der Tür steht mit vielen Schulterklappen und sagt, ich habe hier folgende Anforderungen, setz mal um. Gemeint ist aber ja damit, ich habe hier folgendes Problem erkannt bei uns im Markt, bei den Nutzern, bei den Kunden. Findet mal eine Lösung, wie wir dieses Problem lösen können. Sprich, ich glaube, wir müssen wegkommen, dass es eine Denke gibt, dass da Menschen kommen und Lösungswünsche. Jetzt mal ganz überspitzt, uns über den Zaun kippen, gerade in die IT-Reihen, weil man nochmal so klassisch weiter denkt. Wir müssen hinkommen, gemeinschaftlich in der Organisation über alle Silo-Grenzen hinweg, also die erstmal aufzulösen und zu sagen, hey, lass uns den Markt verstehen, hey, lass uns den Wettbewerb verstehen, hey, lass uns die Nutzer verstehen. Was haben die für Probleme? Wie kommen die da drauf? In welcher Nutzungssituation? Also was ist der Produktkontext? Was ist der Problemkontext? Und dann gemeinsam zu überlegen, ah, okay, welche Lösungshypothesen haben wir dafür? Welche Annahmen haben wir dabei getroffen für diese Lösungshypothesen? Wie viel Evidenz, also Beweise, haben wir denn schon dazu? Oder ist das nur unser tolles Bauchgefühl? Oder weil wir uns selber hochjessen und cool finden und in einem nicht diversen Team, das kommt ja auch noch dazu, ja? Viele white old men. die sich dann auch noch gegenseitig irgendwie auf die Schulter klopfen, was der andere für eine geile Idee hatte. Das kennen wir doch alles. Also ich glaube dieses Umsetzen in oder Umformen in diverse Teams hinzukommen, immer so in den Problemraum reinzustechen, das Problem besser zu verstehen. Das ist mühsam und auch nicht immer spaßig, weil wir haben alle viel mehr Bock, Lösungen zu diskutieren. Ich eingeschlossen, das nehme ich da gar nicht raus. Aber es braucht dann einen im Raum. Der sagt, hey, Tim, diskutieren wir nicht gerade, du inklusive, nicht gerade wieder nur die coolste Lösung. Ja, stimmt. Mist. Ja, lass uns erst noch mal überlegen, ob wir das Problem überhaupt richtig gut verstanden haben. Und dann, das ist mit kontinuierlicher Product Discovery gemeint, immer wir haben eine Lösung, eine Problemhypothese. Lass uns die überprüfen, vielleicht mit einem Proof of Concept, mit einem Prototypen oder sonst was. Ah, okay, haben wir wieder was gelernt, haben Feedback bekommen. Zurück zu unserer Problemhypothese, müssen wir vielleicht anpassen. Okay, haben wir das Problem ein bisschen besser jetzt verstanden. Und das ist so, Spielband, Standbein immer wechseln zwischen Discovery und Delivery. Ich glaube, das ist das, wo wir hinkommen müssen. Das ist vielleicht so ein neues Modell von Anforderungsmanagement. Wie gesagt, lassen wir uns mal überlegen, ob der Begriff überhaupt noch richtig ist. Mike, was meinst du zum Begriff? Harald Wild: Ist denn die Analogie, die du jetzt aufgemacht hast, gilt die auch für Arbeit im Unternehmen? Also lassen sich die gleichen Prinzipien aus deiner Sicht auch auf ganz normale Arbeitsabläufe im Unternehmen anwenden? Tim Klein: Okay, du hast ja auch nach dem Grundrauschen oder nach der normalen Arbeit gefragt. Die Frage ist berechtigt, immerhin zu hinterfragen, wozu tun wir das hier eigentlich? Und ich glaube, wir kennen alle in Organisationen, gerade die größeren Organisationen, viel Selbstbeschäftigung mit dem System. Also in meiner Zeit bei einem großen Pharmakonzern habe ich das Gefühl gehabt, dass dieser Konzern intern sich vor allem mit sehr vielen Menschen sehr viel mit sich selber beschäftigt. Und also... Prozesse für andere Abteilungen, für andere Bereiche oder so macht. Also dieser Selbstbeschäftigungsreferenz in Großunternehmen ist, glaube ich, schon mal ein Punkt. Und das heißt auf entsprechende Arbeit, wie du es nennst, oder Grundrauschen oder... Es muss zumindest immer hinterfragt werden, welchen Sinn hat das? Auf was zahlt das ein? Also was enabelt das? Was für ein größeres Problem wird damit gelöst? Und das ist manchmal sehr, kann manchmal sehr indirekt sein. Das will ich gerne zugestehen, dass das nicht immer so offensichtlich ist. Aber den Sinn von sowas muss immer hinterfragt werden. Das fängt bei ganz banalen Dingen für mich an wie eine Meetingserie. Ja, Meetings are live forms oder so hieß es mal. Also eine Meetingserie ist schnell erstellt in Teams oder Outlook. Wupp wupp wupp und plötzlich sitzt du jede Woche eineinhalb Stunden in Meeting X und in den ersten vier Wochen mag das auch noch sinnvoll gewesen sein und das kennen wir alle. Nach ein paar Wochen sitzt du da und gehst dahin denkst, warum sitze ich hier? Ja und also mit so was ganz praktischem wie Meeting Hygiene. Ja, lass doch mal alle drei Monate mal alle Meetingserien löschen und mal ernsthaft wieder überlegen. Also es geht einfach. Einfach mal die Serie löschen und mal ernsthaft überlegen, wozu machen wir das noch? Brauchen wir das in der gleichen Kadenz? Brauchen wir das in der gleichen Länge? Ist uns eigentlich noch klar, was wir hier ursprünglich machen wollten? Oder beschäftigen wir uns, ist jetzt ein bisschen kätzerisch, beschäftigen wir uns eigentlich nur mit uns selbst. Mike Leber: Ich würde jetzt, wir kommen jetzt schon, glaube ich, gegen's Ende unseres Session hier, eine kleine provokative Frage nachschießen, die wahrscheinlich die großen Unternehmen gar nicht interessiert, weil die ja alle mit SAFE unterwegs sind. Hat Scrum deiner Meinung nach eine Zukunft? Tim Klein: Also ich komme ja auch aus dieser Bubble ursprünglich und glaube, dass wir da sehr viel Selbstreferenz drin haben. Also Scrum und Agilität und dass wir uns da selber mit der ganzen Scrum-Sache ziemlich überhöhen. Ich verfolge nicht diese These, was kommt nach Scrum und ist Scrum tot und so. Das ist nicht mein Thema. Ich glaube, dass Scrum eine sehr, sehr gute Berechtigung hat, wenn es an der richtigen Stelle eingesetzt wird. Und genau darin sehe ich das Problem, dass Scrum heutzutage an viel zu vielen Stellen eingesetzt wird, wo es nicht hingehört. Also wo es nicht um eine Produktentwicklung oder Serviceentwicklung in einem komplexen Umfeld geht. Und da ist Scrum einfach Bullshit. Da sollte Scrum keine Zukunft haben. Da verbrennt Scrum auch seine, wenn man so will, seine Reputation, glaube ich. Zweitens ist die Also das Schwierige bei Scrum ist doch, es richtig zu implementieren, also was heißt richtig, es erfolgreich so zu implementieren, dass es wirklich ein Outcome produziert, Business Needs Delivered etc. Das ist schwierig und das Schaffen, sind wir doch mal ehrlich, das Schaffen doch die allerwenigsten Unternehmen. Meistens Unternehmen hilft erstmal überhaupt die Umsetzung von Elementen von Scrum, das ist dann kein Scrum mehr, aber meinetwegen überhaupt die Einführung von Daily Standups, von Retrospectiven, überhaupt von vielleicht iterativen, damit getakteten. vorgehen. Das kann schon helfen, um dem eigenen Problem nicht fokussiert arbeiten zu können, vielleicht Herr zu werden ein Stück weit. Von daher können uns glaube ich auf deine Frage hin die Ideen von Scrum sehr wohl, also in der Kombination mit den Prinzipien und Werten von Agilität sehr wohl weiterhin sehr stark helfen. Das Framework selber müsste nach meinem Verständnis dieses ganze Thema Product und Discovery wirklich inkludieren und stärker fokussieren. Ich glaube, das ist bei den Entstehungsgeschichten, das AG-Manifest und so, das Thema Product einfach noch nicht gedacht worden, soweit ich das weiß. Das ist halt schon später dazugekommen. Und wir haben jetzt gerade so in den letzten vielleicht auch fünf bis acht Jahren. eine wahnsinnige Entwicklung im Produktmanagement. Und ich nenne es jetzt mal im modernen Produktmanagement, weil Produktmanagement gibt es schon seit Procter & Gamble, die Kamei-Seife irgendwie in den 50er Jahren damit erfunden hat. Also das Produktmanagement da erfunden hat. Aber was verstehen wir denn überhaupt als Produktmanagement? Das ist ja im deutschsprachigen Raum ein total Irre, was alles als Produktmanagement definiert wird. So, also was ich meine, ist ein modernes Produktmanagement Verständnis. Und das geht Scrum. komplett ab, finde ich. Und da habe ich eine große Kritik. Sprich, solange sich Scrum so stark auf Reihen-Delivery fokussiert, sehr stark auf das, ich verkürze es mal rein zwischenmenschliche, verliert es immer mehr seine Legitimation. Und ich muss auch selber sagen, ich bin nicht mehr so ein glühender Verfechter, wie ich jetzt vor einigen Jahren noch war, muss ich ganz klar sagen. Weil Scrum per se, das finde ich, ist der Punkt, ist kein Selbstzweck. Also Scrum des Scrum-Willens ist, glaube ich, der schlechteste Rat, den man Unternehmen geben kann. Und trotzdem machen es natürlich viele, hip ist, weil viele Unternehmen dann glauben, nur so kriege ich noch neue Mitarbeitende und nach außen, das ist ein bisschen agiles Theater dann. Und das ist eines der großen Probleme, dass Scrum häufig eben nur so, da sind wir wieder beim agilen Mindset, nur so im Handeln gespielt wird, ich übersplitze jetzt etwas, und nicht wirkliches Fühlen und Denken in den Scrum-Ideen, die ja alle valide sind und gut sind, durchgeführt wird. Das heißt, schlechtes Scrum. ist das, was Scrum diskreditiert und was Scrum auch weniger Zukunft haben lassen könnte. Das ist jetzt alles hypothetisch. Wir wissen es ja auch nicht. Harald Wild: Jim Hidesmith hat es, glaube ich, so genannt, er würde die Agilität gerne wieder in ihre Jugend zurückführen und Begeisterung dafür schaffen, aber auch er sieht es als sinnvoll an, dass man jetzt nicht Frameworks um das Frameworks-Willen nutzt. Ich meine, das ist eine Plattitüde mittlerweile, das weiß, glaube ich, jeder, dass das so ist. Aber er hat es schön formuliert, er hat gesagt, man sollte erst mal den Bedarf nach einem Tool oder einer Regel wecken, bevor man in Betracht zieht, es einzusetzen. Wie siehst du das? Ist das in... Tim Klein: Also eine meiner ersten Fragen, in der Auftragsklärung ist immer, welches Problem wollt ihr denn überhaupt lösen? Ja, schön, dass ihr jetzt hier mit mir irgendwie ein Strong Product Owner Training oder mit uns buchen wollt. Das machen wir ja recht regelmäßig. Oder Klassiker ist, kann man bei dir ein Training zum, wie schreibe ich gute User Stories buchen? Ich denke so, also User Stories schreiben schon mal gar nicht, erfolgreich mit User Stories arbeiten, ja, aber sie sind nicht zum Schreiben da, sie sind zum drüber reden da. Und okay, was ist das Problem? Mike Leber: und in der Trainingart zu. Tim Klein: Ja, genau. Was ist das Problem dahinter, was ihr lösen wollt? Wenn das nicht klar ist, ich glaube, da biegen die meisten Unternehmen falsch ab. Weil ja, es muss schneller werden. Das ist auch so ein Klassiker gerade. Es muss schneller werden. Ja, dann Scrum machst du nicht, um schneller zu werden, würde ich behaupten. Ja, dann mach lieber oder kombiniere es mit Kanbanen im Sinne von und nennen es um Gottes Willen nicht Scrumbanen. Das ist das Allerschlimmste. Ja, also eine eigene Folge wahrscheinlich wert. Also man kann scrummen und kann man wunderbar kombinieren. Ich glaube für Durchlaufoptimierung, für das Problem schnellere Time to Market und schneller ist kann man super. Aber bitte auch nicht nur schneller in der IT Organisation, sondern schneller im Sinne von from the idea to the impact. Also bis zur Auslieferung, bis zur Wirkung. Und wenn das Problem ist, unsere Produkte und Services werden nicht gefragt. Ja, dann haben wir das Produkt. Das Problem der Nutzer wahrscheinlich noch nicht gut genug verstanden und dann ist nicht Scrum die Lösung. Dann gibt es andere Methoden, die man ansetzen sollte. Harald Wild: Das ist, glaube ich, ein schönes Abschlussstatement, oder? Tim Klein: Oder? Harald Wild: Also ich muss ganz ehrlich sagen, ich finde deine Klarheit sehr gut, aber auch deine Anschlussfähigkeit. Und ich glaube, wenn man merkt, dass du eine sehr lange Erfahrung hast in linearen Bereichen, du kennst die Schmerzen, die dich verursachen können, oder die Vor- und Nachteile sehr gut. Und ich glaube, das führt auch dazu, dass du sehr gut verstanden wirst in den Thesen, die du aufstellst und in den Gründen, die du benennst, weil einfach in vielen Unternehmen ist auch der Anschlussfähigkeit, sage ich mal, vielleicht auch ein bisschen das Problem ist, zu verstehen, was die Aussage hinter dem Ganzen ist. Aber was ist denn jetzt bei dir das nächste? Wo sind deine nächsten Themen? Was hört man demnächst von dir? Tim Klein: Gut, also grundsätzlich machen wir weiter unseren Podcast, die Produktwerke, den Podcast für Product Owner und, oder den deutschsprachigen Podcast für Product Owner und Agiles Produktmanagement. Das machen wir seit dreieinhalb Jahren und was da sozusagen immer neu, auch bei unseren Live-Events und Trainings reinkommt, dass wir, wir uns diese Mission eigentlich jetzt vorgenommen haben. Wir wollen die Brücke schlagen, so ein bisschen aus der, von der agilen Insel. hin zur Produktmanagementinsel. Wir wollen uns nicht verheben und sagen, wir machen die Brücke andersrum, sondern wir fangen an, die Brücke aus unserem agilen Verständnis herzubauen und die agile Blase, die Product Owner Blase, denen immer mehr Verständnis einzuhauchen und mitzugeben und das zu begleiten, dass es einen Bedarf an Produktmanagement Know-how gibt, wenn ich als Product Owner oder als produktzentrierte Organisation arbeiten will. Dementsprechend das ganze Thema Richtung Wie komme ich zu Empowered Teams? Wie komme ich zu einer produktgetriebenen Organisation oder produktdenkenden Organisation? Da gibt es mehrere Begriffe, die jetzt zu weit führen würden. Wie komme ich also weg von der reinen Delivery-Einheit hin zu einem Verständnis? Wie schaffe ich Outcome? Also sprich, schaffe neue Möglichkeiten, Probleme für Kunden und Nutzer zu lösen. und gleichzeitig eben dem Business zu dienen. Das ist ein bisschen solemnonisch gesagt, aber da wähle ich hin, dass wir die Product-Owner-Rolle mit immer mehr Produktmanagement anhauchen. Also so Oberthema könnte sein. Wir versuchen, Product-Ownern-Produktmanagement beizubringen. Mike Leber: Ja wunderbar, ich glaube dann sind wir eigentlich schon in der Zukunft angelangt und damit am Ende unserer Session hier. Ich denke es bleibt uns nur mal übrig dir Danke zu sagen Tim, ein spannendes Gespräch. Ich denke da haben wir einiges mitgenommen und hoffen viele unserer Hörer holen da auch einiges raus. Und ich denke du hast schon angesprochen Produktwerker für die die eventuell euch nicht kennen. Ich gehe nicht davon aus, aber einfach in Google eingeben und ich glaube es kommt eine... Liste an Links, zu Tage, Podcast, Website und dergleichen, um euch zu kontaktieren. Nochmal vielen herzlichen Dank an der Stelle. War spannend und vielleicht gibt's ein nächstes Mal. Tim Klein: Sehr gerne, auf meiner Seite herzlichen Dank. Ansonsten kontaktiert mich gerne über LinkedIn. Da bin ich und folgt mir auf LinkedIn. Da bin ich am meisten aktiv, Monter. Inzwischen nicht mehr bei Twitter und Xing. Harald Wild: Ich fand es auch sehr toll, dass du auch Stellung beziehst, dass du dich nicht scheust, einfach die Meinung auch klar zu sagen. Das bringt, glaube ich, am meisten auch den Zuhörern und auch uns. Deswegen vielen Dank, dass du heute hier warst und wir freuen uns auf das, was von den Produktwerkern noch kommt.