Der Product Owner verständlich erklärt

Jasmine

Herzlich willkommen zum Agile Growth Podcast. Ich freue mich total, dass du wieder mit dabei bist. Heute dreht sich alles rund um den Product Owner. Die Product Ownerin, eine unglaublich wichtige Rolle im Scrum Rahmenwerk. Aber was macht denn der oder die überhaupt? Und wozu braucht es den? Was macht der Product Owner oder die Product Owner nicht? Und wie wachse ich überhaupt in diese Rolle rein? All das beleuchten Kai und ich in den nächsten paar Minuten.

Sprecher

Herzlich willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

Kai

Herzlich willkommen zum Agile Growth Podcast. Wir sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen, Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT-Wissen vorauszusetzen. Und heute geht es um eine Rolle, die für mich viele Jahre lang irgendwie eher ein Buch mit sieben Siegeln war. Mittlerweile hat sich das Gott sei Dank verändert, denn sie ist unglaublich wichtig, wenn man agil arbeiten möchte. Denn heute geht es um den Product Owner oder die Product Ownerin

Jasmine

Und ja, es ist der Product Owner. Es ist nicht der Project Owner. Da sind wir, glaube ich, schon am ersten Punkt der großen Unterscheidung. Wenn ich jetzt so von meiner Organisation, von einer ganz klassischen Projektorganisation, vielleicht in eine eher Produkt Organisation umdenke, dann reicht es nicht, meine Projekte auf einmal Produkte zu nennen, weil zwischen dem Projekt und dem Produkt gibt es erhebliche Unterschiede. Ein Produkt ist dazu gedacht, langlebig zu sein. Ein Produkt wird anders wahrgenommen, anders klassifiziert. Das heißt, wenn ich einfach meine ganze Projektorganisation nehme und sage Okay, jetzt haben wir überall Project Owners drin und vielleicht noch Scrum Master und ihr seid jetzt halt Scrum Teams. Dann wird das Ganze da nicht funktionieren. Und auch das, was der Projektleiter früher gemacht hat, das ist was anderes als das, was der Product Owner machen wird. Da gibt es sicherlich Überschneidungen. So, und wenn du jetzt als Projektleiter unterwegs warst oder vielleicht auch als Produktmanager unterwegs  warst, dann wird es Überschneidungen geben mit dieser Product Owner Rolle.

Jasmine

Sehr viele sogar. Und du wirst ganz viele Fähigkeiten, die du schon pre agil genutzt hast, weiter nutzen. Aber diese Product Owner Rolle für uns ist ein Umdenken und wir hören halt diesen Project Owner bei vielen unseren Kunden immer noch und da wissen wir schon Aha, da müssen wir vielleicht noch mal rangehen. Also wir würden gerne anfangen mit was macht denn so ein Product Owner überhaupt?

Kai

Ja, der owned das Produkt, also das gehört demjenigen oder derjenigen. Und das bedeutet auch, so was wie eine Vision überhaupt mal zu haben. Was wollen wir denn hier materialisieren? Also was gibt es im Moment nur in unseren Köpfen und Vorstellungen? Und was soll denn mal als Produkt entstehen hier? Und dazu braucht es viel Dialoge mit Leuten, die irgendwie Anforderungen haben an dieses Produkt, dann an die Stakeholder, um das rauszufinden, um das mit zu gestalten, was denn da drin sein soll. Und es braucht natürlich Leute, die das dann umsetzen, mit denen Produkt oder auch ganz stark zusammenarbeitet.

Jasmine

Das heißt in Kurz Diese Product Owner Rolle ist eine sehr, sehr kommunikative Rolle. Also wenn du stark in der Kommunikation bist und es dir auch Spaß macht, mit Leuten zu interagieren, Visionen zu spinnen, ich würde schon fast sagen zu träumen, weil daraus entstehen oft ganz, ganz gute Produktideen, dann kann das deine Rolle sein. Und wir tun das mit unterschiedlichsten Zielgruppen. Also idealerweise mit den Stakeholdern, mit deinen Endusern, die das Produkt dann auch wirklich benutzen. Das können andere Gruppen sein, sind in den meisten Fällen andere Gruppen mit den Geldgebern, aber auch mit den Leuten, die das Ganze umsetzen werden. Also deine Entwickler und Entwicklerinnen.

Kai

Und ich finde immer so das Bild von einem Start up Unternehmen oder einer Start up Unternehmerin ganz gut. Da gibt es meistens so einen Vor Träumer, der hat eine Idee davon, was dann in der Welt existieren soll und der besorgt sich eben auch die Mittel dazu, das tun zu können und stellt sich ein Team zusammen, um das dann zu erreichen, dass es meistens jemand, der auch gut kommunizieren kann, also der auch pitchen kann für diese Idee und der überzeugen kann für diese Idee. Der ist also kommunikativ stark und auch oft entscheidungsfreudig unterwegs.

Jasmine

Und Kai hat gerade was Gutes erwähnt, der besorgt sich auch, oder die besorgt sich die Mittel, um diese Idee umzusetzen. Ein guter, befreundeter Trainer von uns sagt immer: Der Product Owner hat der Arsch in der Hose. Schnelle Entscheidungen und Geld in der Tasche. Und ich finde, mit diesem Spruch reinzugehen in viele Organisationen trennt schon die Spreu vom Weizen. Viele Product Owner, die wir wahrnehmen, sind Ticket Schubser. Also Leute, die Anforderungen aufschreiben dürfen, aber nicht drüber entscheiden und die irgendwie ins Team rein schubsen dürfen.

Kai

Klingt jetzt ein bisschen böse. Auch das kann in einem Scrum Team sehr viel Wert haben, wenn Menschen sind, die eine tiefe Requirements Engineering Fähigkeit besitzen, eine tiefe Business Analysefähigkeit. Nur dass wir dieses Beispiel aus dem Blickwinkel von Scrum Rahmenwerk als Teammitglieder sehen würden, weil der Product Owner eben entsprechend dieser strategische Visionär ist, der Entscheidungsberechtigt und befugt ist. Eine gute Lackmustest Frage, die man sich stellen kann, ist auch, ob ich der Product Owner bin. Kann ich eine wichtige Product Funktionalität streichen? Kann ich das Produkt vielleicht sogar einstampfen? Daran kann man das oft festmachen. Und was wir sehen in Organisation ist, dass diese Rolle unglaublich oft falsch besetzt ist. Da ist dies nicht mit der richtigen Entscheidungsbefugnis versehen, das heißt meistens der Product Owner Ebene zu tief in den Teams, also auch in der Unternehmens Hierarchie. Wenn das ein klassisches Unternehmen ist, bräuchte man jemanden eine Stufe höher in der Hierarchie. Oft heißen die Produktmanager oder Programmmanager oder so was. Das sind eigentlich häufig die, die dann eine Befugnis haben. Die Frage kannst du dich selber stellen.

Kai

Das heißt hier der Product Owner, dem soll das Produkt wirklich gehören? Der ist also nicht nur ein Verwaltender Aspekt,  zu dem irgendwas runter delegiert worden ist, sondern dem gehört das Produkt. Und das ist oft schon eine radikale Veränderung, gerade wenn ich aus dem klassischen Umfeld komme.

Jasmine

Und da gibt es natürlich dann zwei Arten, wie ich mit dieser Dysfunktion umgehen kann, wenn dem Product Owner das Produkt nicht gehört. Also entweder kann ich den wahren Product Owner suchen und meinen Product Owner zum Teammitglied machen, weil diese Business Requirements Fähigkeiten, die brauche ich als Team auch und die sind unglaublich wertvoll. Aber ich brauche doch jemand, der schnell Entscheidungen treffen darf und kann und tut. Oder ich gucke dass mein Product Owner, meine Product Ownerin, die ich gerade habe, dass ich die befähigen kann. Das heißt, ich starte. Ich fange an, mit der Organisation zu arbeiten und zu gucken: Ach okay, wir haben Programm Management drüber. Was brauchen die denn, damit der Product Owner, die Product Ownerin, die wir haben, schnelle Entscheidungen treffen kann und damit das Geld in der Tasche ist und der Arsch in der Hose. Also entweder kann ich’s aufbauen oder ich kann gucken. Wir suchen den richtigen oder die richtige Product Ownerin.

Kai

Und diese Entscheidungsfähigkeit ist eine Haupt-Dienstleistung vom Product Owner gegenüber seinem Entwicklungsteam und gegenüber den Stakeholdern. Denn vielleicht kennst du das auch, wenn er so einen Kreis mal hast, wo eine Entscheidung dann vorgelegt wird. Der trifft sich alle Nase lang. Dann dauern diese Entscheidungen unglaublich lange. Und das ist uns im agilen Arbeiten nicht effizient genug. Wir wollen eine Entscheidung zügig haben, und es ist ja schon schwierig genug, sich als einen Menschen Kopf zu machen. Da will ich nicht noch mehrere Menschen beteiligen. Deswegen gibt es da eine ganz klare einzelne Verantwortung hier an dieser Stelle, und das ist dann die Dienstleistung, schnell zu entscheiden, auch in der Unsicherheit. Und das ist natürlich da, wo agiles Arbeiten vorwiegend genutzt wird, nicht da, wo ich noch mit weiterer Analyse total gut verstehen kann, was der Masterplan ist. Da brauche ich nicht agil arbeiten. Es ist ja eher wie Autofahren im Nebel. Da wo ich viel Überraschungen habe, da habe ich Unwägbarkeiten, manch einer benutzt diesen VUCA-Begriff ich. Mag den nicht so unglaublich gern, der ist so plattgetreten mittlerweile, aber

Kai

auch da ist natürlich was dran. Eine Welt, die volatil ist, die unsicher ist, die komplex ist und die Doppeldeutigkeiten hat und sich durch diesen Nebel da durch zu fräsen und einfach trotzdem Entscheidungen zu treffen ist ein Produkt Owner Job.

Jasmine

Und da sind wir schon an der Frage Warum braucht es denn eigentlich Product Owner? Weil wir eben in dieser hochkomplexen Welt sind, wo es nicht die richtige Entscheidung gibt, sondern es gibt eine unzählige Anzahl an Möglichkeiten und wir müssen uns ganz oft sehr schnell entscheiden, einfach mal was auszuprobieren  damit wir lernen. Und das ist ja das ganze Ziel von Scrum, es ist ein Lern Framework. Wir wollen lernen, damit wir unser Produkt möglichst schnell und gut an den Markt bringen. Das heißt, wir wollen sehr viele Fehler möglichst früh machen. Wir wollen sehr schnell lernen und da braucht es auch schnelle Entscheidungen. Und da brauche ich einen Product Owner, der die Entscheidung trifft und dann auch dahinter steht. Oder eine Product Ownerin. Und wir waren jetzt gerade in mehreren Projekten drin, wo das nicht der Fall war. Und das ist frustrierend, sowohl für die Product Owner wie auch für die Entwickler und Entwicklerinnen, aber auch für die gesamte Organisation. Also wenn es dann immer so ja, wenn aber doch Entscheidungen gibt, und man rechts, links, aber auch geradeaus fahren müsste, dann macht das das Endprodukt auch einfach unglaublich komplex, viel komplexer als es sein müsste.

Jasmine

Es braucht viel mehr Entwicklungszeit, das verschwendet unglaublich viele Ressourcen. Und am Ende haben wir eine eierlegende Wollmilchsau, die weder Eier legt, noch Milch gibt, noch Wolle gibt.

Kai

Und dafür braucht unser Produkt ohne Fähigkeiten zum Customer Discovery. Also der muss wirklich den Kunden immer wieder entdecken. Auch das ist eher ein kontinuierlicher Prozess. Also was einmaliges, ein gutes Ohr am Markt haben verschiedene Möglichkeiten über Daten getrieben, über Customer Interviews irgendwie rausfinden. Was brauchten denn die Leute als nächstes und wo darf ich meinen Fokus drauf legen, damit dieses Ding ein Erfolg wird? Und dass das eine ziemlich schwierige Herausforderung ist, sieht man auch an den Fehlschlag Quoten von Start ups. Das scheitert natürlich nicht immer nur an dem Produkt, das nicht zum Markt passt. Das scheitert auch mal an anderen Dingen, dass es menschelt oder was auch immer. Aber es ist eben auch ein Faktor, dass man dann am Markt vorbei entwickelt. Und um genau diese Schleife immer wieder zu schließen – Jasmine hat es Lernframework genannt Scrum haben wir unser Sprint Review, wo wir dann immer wieder auch, ja potenziell freundliche Nutzer treffen oder auch Stakeholder, mit denen wir dann schnell rausfinden, ob das, was wir gebaut haben, irgendwie das ist, was der Markt auch braucht.

Jasmine

Also ein guter Product Owner für mich oder eine gute Product Ownerin, die unterhält sich kontinuierlich mit End Nutzern. Kontinuierlich. Und das sind nicht drei Interviews, die ich mal mache im Monat. Das sind, das sind eher 20 oder 30, wo ich mit einem Endnutzer mich unterhalte und frage “Hey! Hast du das Produkt benutzt? Was würdest du dir noch wünschen? Wo funktioniert’s? Wo erleichtert dieses Produkt dein Leben? Wo noch nicht?” Und so weiter. Also ganz, ganz viel von dieser Discovery macht der Product Owner die Product Ownerin, um wieder neue Ideen zu haben, neue Visionen zu haben, wo es weitergehen könnte und die auch wieder den Stakeholdern, Auftraggebern, den Geldgebern pitchen zu können, aber auch das Team motivieren zu können. Also da zu sagen Hey, ich habe mit den Leuten gesprochen, eine signifikante Zielgruppe von uns vermisst das und das, weil die möchten das und das tun damit. Und das ist sehr viel motivierender für ein Entwicklungsteam zu wissen, warum sie Dinge tun, wie, das das Leben von anderen Menschen erleichtern würde.

Jasmine

Was für ein Impact, das Feature oder die Feature Gruppe, die man gerade baut für den Endnutzer hat es so viel erstens motivierender, aber zweitens beeinflusst auch die Lösung enorm, wenn ich ein gutes Verständnis darüber habe, was der Nutzer denn tun möchte, was er vermisst. Manchmal kann der Nutzer ja nicht sagen, was er tun möchte oder sagt sehr genau, was er tun möchte. Aber es ist überhaupt nicht das, was er will. Aber wenn ich ein Verständnis dafür habe, wie arbeitet der denn damit? Oder die? Und was vermisst der? Dann wird die Lösung einfach auch erheblich beeinflusst und sehr oft vereinfacht.

Kai

Und vielleicht hast du schon mal gehört Verkaufen zum Beispiel ist ein emotionaler Prozess. Keiner der durch Fakten funktioniert. Wir Menschen kaufen was, weil wir es irgendwie geil finden. Und dann sucht unsere Ratio Gründe dafür, warum wir das dann auch wirklich tun. Also ganz viel unserer Verkaufsprozess und Kaufprozess passieren auf so einer Bauch Ebene, hätte ich fast gesagt. Und als Produkt verkauft man auch unglaublich oft Dinge, nämlich die Vision gegenüber dem Team und Features gegenüber dem Team und die Vision gegenüber Kunden und Stakeholdern. Und so weiter. Und weil das eben so ein emotionaler Prozess ist, geht es da darum, die zusammenzubringen, also das Entwicklungsteam mit den Anwendern zusammenzubringen. Weil da passiert die Emotions-Übertragung zwischen diesen zwei Welten. Und wenn ich das immer abstrahieren und weg halte von meinem Team, dann verpasse ich eine unglaublich starke motivatorische Qualität, die ich sonst haben könnte. Insofern ist der Product Owner auch so eine Art Meddler, hätte ich gesagt. Wie sagt man auf Deutsch? Mittelmann, ne Strippenzieher gefällt  mir fast noch besser.

Kai

Also ein Strippenzieher, der das zusammenbringt, die Leute, die das Produkt brauchen und die, die es bauen.

Jasmine

Und vielleicht bist du jetzt am Punkt und sagst Ah ja, gut und recht schön, dass ihr mir das sagt jasmine und Kai. Aber mein Team hat überhaupt keinen Bock darauf. Die interessiert das gar nicht. Das kann sein. Das habe ich schon öfters erlebt, dass im ersten Moment Teams das gar nicht interessiert.

Kai

Die wollen coden, die wollen programmieren, die wollen in Ruhe gelassen werden und hinter ihren Rechnern sein. Ich bin jetzt voll im Informatiker Klischeebild Ich darf das ja, weil ich Informatiker bin. Ich mache das ja auch ganz gerne.

Jasmine

Ich wollt gerade sagen, mir geht es ja auch so.

Jasmine

Bleib mir weg mit deinem Feedback. Ich will jetzt einfach meine Idee umsetzen.

Kai

Und das ist aber dann auch nur die halbe Wahrheit, weil ich natürlich auch geile Lösungen bauen möchte. Und wenn ich natürlich merke, dass ich da was entwickle, was dann nachher keiner braucht, frustriert mich das auch. Unglaublich. Und das ist auch so meine Wahrnehmung. Wenn man dann mal anfängt, weiß ich nicht, in einem Microsoft Teams Kanal dann Anwender mit dem Entwicklungsteam zusammenzubringen und dann schreiben die Anwender irgendwas, was sie stört oder wo sie Probleme haben. Dann geht ganz oft dann bei den Ingenieuren auch das Herz auf oder der Lösungsmechanismus. Die Leute stürzen sich da drauf. Wie können sie das besser machen? Vielleicht auch, weil sie sich in der Ehre gekränkt von was auch immer, das im Einzelnen sein mag. Aber daraus entsteht dann was, von wem man eigentlich vorher dachte. Das braucht gar nicht und es will auch niemand. Passiert es trotzdem.

Jasmine

Und. Es kann noch andere Gründe haben, ganz viele andere Gründe. Also woran werden die Entwicklungsteam gemessen, wenn die an Zeilen Code gemessen werden oder irgendwann mal gemessen wurden? Das muss gar nicht mehr so sein. Das kann vor zehn Jahren so gewesen sein. Aber das ist eingebrannt in die Firmen DNA. Das ist, in ORSC würde man sagen. Das ist eine Ghost Voice oder eine Ghost Role, die ist immer noch da. Dann empfinden die das natürlich als Zeitverschwendung, mit einem Kunden zu reden, weil daran werden sie ja nicht gemessen. Also Sie werden nicht für gute Zeilen Code gemessen, sondern für viele Zeilen code zum Beispiel. Kann sein, es kann aber auch einfach eine Angst sein, weil wir sind ja eh schon ausgelastet. Ganz ehrlich, wir sind ausgeplant bis 2023. Ist ja schön, wenn mir jetzt jemand noch Feedback gibt. Aber wann soll ich denn das noch tun? Ja, wenn ich kein Slack drin habe und eben mein Product Owner oder meine Product Owner keine Entscheidungen treffen kann und auch der Kurs unseres Backlogs nicht verändern kann, dann macht dieses Feedback nicht viel Sinn, weil dann geht es irgendwie Back of Backlog, irgendwo ist es dann drin, aber da hätte ich mir sparen können

Jasmine

Mit dem Kunden zu reden, das frustriert ja nur alle Seiten.

Kai

So, das ist so eine Art Entrepreneur, haben wir gesagt. In größeren Umfeldern kann man sich das vorstellen und das klingt wahrscheinlich alles total logisch. Wird das diese Rolle beschreiben? Und die Chance ist hoch, dass wenn du gerade zuhörst, dass du denkst, aber bei uns ist das anders. Und das geht uns natürlich auch so Ich würde sagen, in 78,35 % der Fälle ist der Product Owner, den wir antreffen, im agilen Umfeld, der das irgendwo auf seiner Visitenkarte draufstehen hat kein wirklicher Product Owner, sondern eben, wie eben beschrieben, ein Business Analyst, Requirements Engineer, jemand, der etwas mittelbar verwaltet. Was dazukommt ohne diese emotionale Visions Verkaufs Qualität und ohne die Entscheidungsfreude und ohne das Vorangehen. Das heißt, diese Leute findet man auch gar nicht so leicht im Unternehmen. Und das ist dann natürlich auch so ein Ding, wo man als Scrum Master rangeht und guckt, okay, der Mensch, der da steht, will der sich weiterentwickeln, traut er sich das selber zu, dem mal die Rolle aufzuzeigen und Product Owner zu begleiten oder dann eben auch irgendwann zu schauen

Kai

Okay, wenn das so nicht funktioniert, welche anderen Möglichkeiten haben wir?

Jasmine

Und wenn wir jetzt so gucken, welche Charakteristiken würden wir sagen, braucht ein Product Owner ich? Ich würde mal sagen. Es muss ein visionärer Mensch sein, ein Mensch, der gerne in die Zukunft denkt und das dann mit der Gegenwart verbindet. Für mich sollte ein Product Owner oder eine Product Owner auch ein Mensch sein, der gerne Risiken eingeht. Natürlich kalkulierbare Risiken. Aber wenn, wenn du ein sehr Angst behafteter Mensch bist, sehr viel Sicherheit brauchst, dann kann das vielleicht bei gewissen Produkten wie ich weiß nicht, Medizin Tech Bereich oder so okay sein, aber auch da nicht.

Kai

Na ich glaube, da muss man auch ganz schön vordenken, je nachdem, was man da kreieren will.

Jasmine

Eigentlich schon.

Kai

Also da würde ich, glaube ich, eher die ängstlichen oder die sicherheits orientierten Menschen als Teil des Entwicklungsteams sehen, um da entsprechend dafür Sorge zu tragen, dass dann auch entsprechend alle Vorschriften usw eingehalten sind und dass man dann noch mal die extra Meile in der Qualitätssicherung geht. Aber ich glaube schon beim Vordenker, das ist eher, das ist schon diese Visions Qualität, die da auch ganz viel reinkommt.

Jasmine

Genau. Ein Product Owner ist oft auch nicht der Mensch der eine Vision von irgendwo braucht. Also der, sagt er, das muss jetzt das Unternehmen sagen, wo ich hingehen soll. So ein Product Owner ist wirklich ganz oft so auch ein bisschen wie der Scrum Master, so der Unternehmens Anarchist, der sagt ja, okay, gib eine Unternehmens Vision. Ich habe eine geile Idee, die wird uns vorantreiben als Unternehmen. Also machen wir das jetzt einfach mal.

Kai

Und da drin ist glaube ich, der Product Owner auch mehr Politiker als Ingenieur, weil es ja da auch darum geht, dann entsprechend politische Entscheidungen durchzusetzen und den Buy In zu gewinnen. Ich glaube heute haben wir ein Bullshit Bingo in der Folge.

Jasmine

Sehr Denglisch heute bei uns

Kai

Um die Unterstützung der Leute zu gewinnen, die dann auch funktionale Wünsche haben an das Produkt und die halt eben auch den Budgetrahmen mit beeinflussen. Und so weiter. Also da eher ein strategischer Politiker als ein Ingenieur. Und ganz schwierig ist es oft für sehr technische Menschen, die dann in die Product Owner Rolle reinkommen. Wieso? Weil die oft im Lösungs Raum unterwegs sind. Und ich habe gestern einen Joke auf LinkedIn hingeschrieben. Was macht der Product Owner im Lösungs Raum?

Jasmine

Sich zurückziehen.

Kai

Ist n Flachwitz, ne? Genau. Der Lösungsraum gehört den Entwicklern, also den Produktentwicklern im Scrum Rahmenwerk. Und die dürfen sich die Lösung dafür überlegen. Und dem Product Owner gehört der Problem Raum. Den teilte sich mit den Kunden und den Anwendern zusammen. Also was sind die Probleme, die gelöst werden sollen? Und die sammelt er zusammen und bringt in der Reihenfolge der Wichtigkeit und Dringlichkeit der Probleme. Und da merkt man schon so, dass es an der Stelle ja eher ein gutes Gespür dafür braucht, was jetzt der Markt und die Leute brauchen und das auch noch verkaufen zu können. Warum man diese Strecke lang geht? Stichwort Politiker als das zu analysieren im Detail.

Jasmine

Und da sind wir vielleicht schon am Punkt von was macht der Product Owner denn alles nicht? Ganz oft höre ich von den Entwickler und Entwicklerinnen Ja, wir brauchen Product Owner, der uns jetzt diese Tickets oder diese, egal was er nutzt, also ob ihr jetzt ein Miro Board nutzt mit euren Zettelchen drauf oder Jira oder was auch immer, der uns das genau spezifiziert. Das würde in meinen Augen ein Product Owner nicht machen. Das heißt nicht, dass er kein Jira Ticket schreibt oder sie. Natürlich tun die das aber eher im Sinn von ein Versprechen auf ein Gespräch. Also ob ich jetzt dieses User Story Format da verwende, “als hmhmhm möchte ich hmhmhm damit hmhmhm” schreib ich das mal so auf und im Hinterkopf habe ich ja natürlich als Nutzer. Ja, welcher Nutzer? Ist es die Marie, die 22 ist und super viel mit dem Computer macht und einfach Digital Native sowieso, drag and drop und alles geht. Oder ist es Tante Erna oder oder? Also diese Gedanken macht sich der Product Owner und die Product Ownerin Zielgruppe. Auf welche spezialisieren wir uns gerade?

Jasmine

Welche gucken wir an? Für wen ist dieses Feature? Wer will was damit tun, aber ausspezifizieren, wie denn jetzt genau die Lösung auszusehen hat. Das machen Product Owner nicht. Das machen wir zusammen mit den Entwickler und mit den Entwicklerinnen im Refinement. Und das Refinement ist dadurch meistens nicht ein zwei Stunden Termin, den ich azyklisch zum Sprint Wechsel habe, weil das reicht ja gar nicht, sondern es ist vielleicht ein zwei Stunden Termin azyklisch zum Sprint Wechsel, wo ich die Sachen mal durchgehe, wo wir dann aber auch gucken, wer unterhält sich denn jetzt weiter über diese Anforderung, wer spezifiziert da aus, wer schreibt da mögliche Lösungsansätze schon mal rein? Wer interagiert von unserem Team miteinander und vielleicht sogar mit dem Endnutzer? Um das sehr spezifisch hinzubekommen. Das muss nicht unbedingt ein Product Owner oder eine Product Ownerin sein. Und da haben wir schon so das Wachstumspotenzial. Erstens vom Product Owner, von der Product Ownerin, rein aus diesem raus zu gehen, aber auch vom Team. Weil die Entwickler und die Entwicklerinnen sind das oft ja auch nicht gewohnt, das zu tun.

Kai

Die sind ja fürs Programmieren angestellt worden. Steht auch im Arbeitsvertrag. Übrigens

Jasmine

Genau.

Jasmine

Also wenn die anfangen das tun zu dürfen und sollen, dann darf ich als Scrum Master oder Scrum Masterin ganz viel unterstützen, damit das Team auch dahin kommt, das tun zu können. Und vielleicht ist das dann stückchenweise. Oder ich habe eben diese Business Analysten Fähigkeit im Team drin, die mich dabei unterstützen. Aber auch da wieder immer mit den Entwicklerinnen zusammen.

Kai

Also wenn du jetzt selber Product Owner bist und merkst: Oh, das weicht aber bei mir ein bisschen ab davon, was wir beide hier erzählen. Die gute Nachricht ist Jasmin und ich sind beide sehr große Freunde vom Growth Mindset. Wir glauben daran, dass sich Menschen entwickeln können, wenn sie es wollen. Wenn du es bei dir feststellst und du dich in so eine Richtung entwickeln willst.

Jasmine

Und auch Organisationen können sich entwickeln, wenn sie wollen.

Kai

Dann ist die Chance hoch, dass du das auch kannst, in diese Richtung zu gehen. Auf der anderen Seite habe ich jetzt auch öfters erlebt, dass Leute auf dieser Reise feststellen Vielleicht ist das doch gar nicht so meine Präferenz und das, was ich so unglaublich gerne tue. Und da muss man halt schauen Was heißt das? Ich habe auch Product Owner erlebt, die dann entsprechend in das Team, in die Entwicklungsteam Rolle Entwickler oder und Entwicklerinnerolle. Hach, Scrum Guide Umbenennungen, anstrengend. Also die jetzt im Entwicklungsteam mit drin sind und da entsprechend von innen heraus die Details des Produkts mitgestalten, das denen viel besser gefällt. Und da glaube ich ehrlich zu sich selbst zu sein ist auch wichtig. Also zum einen Potenzial in sich zu spüren, wo könnte es hingehen und wohin will ich mich entwickeln? Und ein guter Scrum Master darf sich darin auch gerne begleiten. Da gibt es ja auch einiges an Methodik und Handwerkszeug, was man als Product Owner kennen und lernen darf. Also ich. Und wenn ich so zugebe ich habe Scrum Master 2007 gemacht.

Kai

Ich habe eigentlich erst 2014 angefangen, mich intensiv mit der Product Owner Rolle auseinanderzusetzen. Also ich habe eine ganze Weile so als einäugiger Scrum Master eigentlich so die eine Perspektive verfolgt. Und doch muss ich sagen, in der Produktentwicklung gibt es auch echt eine ganze Menge an hilfreichen Ideen und Modellen, die man sich rausziehen darf, wenn man Product Owner ist. Und da darf ein Scrum Master es auch gerne begleiten.

Jasmine

Genau. Und neben diesen hilfreichen Ideen und Modellen, die eher dann meistens Produkt lastig sind, darf ich mir ja noch ein bissl was an Marketing aneignen, weil nichts anderes ist, eine Vision rüberzubringen. Es ist Marketing. Also ein bisschen was an Vermarktung darf ich mir auch noch aneignen und ein bisschen was an Kommunikation darf ich mir auch noch aneignen. Und vielleicht fällt dir das eine oder andere schon extrem leicht und vielleicht das eine oder andere nicht. Und dann hilft es, mit einem Scrum Master zusammenzuarbeiten oder auch mit einem Coach zusammenzuarbeiten. Sagen: Hey, ich möchte meine Product Owner Fähigkeiten hier stärken. Etwas, was mir noch auffällt ist Was machen Product Owner nicht habe ich jetzt schon gesagt, sondern Sachen ganz, ganz spezifisch aus detaillieren. In meinen Augen mache ich das mit dem Team zusammen. Ich mache das nicht alleine. Oft wird ja gesagt, ein Product Owner sagt ganz oft Nein. Ich würde sagen, das stimmt so halb. Wahrscheinlich werde ich immer mehr Anforderungen haben an meinem Produkt, als ich umsetzen kann. Deswegen sage ich Nein als Product Owner.

Jasmine

Ja, das stimmt. Aber mehr als das Neinsagen sagt der Product Owner auch mit ganzem Herzen ja. Und das Ja bedingt, das Nein oder das Nein bedingt das Ja. Das heißt der Product Owner oder die Product Ownerin, die dürfen sehr standfest in ihren Entscheidungen sein, natürlich da auch reflektiert da drin. Wenn es eine falsche Entscheidung war, dann muss man viel sortieren. Alles fein, aber dem Team den Rücken freihalten, indem ich eben ein ganz klares Nein und ein ganz klares Ja äußere. Das ist etwas, was ein Product Owner macht. Und ein Product Owner sagt durchaus auch Ja zu ganz vielen Dingen. Wir wollen ja das Produkt vorantreiben für unseren Nutzer.

Kai

Wenn ich jetzt wachsen möchte als Product Owner in meiner Verantwortlichkeit, dann ist die eine Idee. Sprich mal deinen Scrum Master an, ob du mit dem spezifisch an Product Ownership Themen arbeiten kannst. Ich habe vor kurzem noch mal das Buch von Roman Pichler durchgelesen. Agiles Produktmanagement mit Scrum. Ich finde das ist ein gutes Überblicks Werk. Da bekommt man noch mal etliche Impulse, auch ein paar Werkzeuge vom Roman. Bei dem habe ich ja auch damals meine Scrum Master Ausbildung gemacht und ich finde, er hat sich da ganz gut reingefuchst. Da kriegt man auf jeden Fall ein paar gute Ideen und auch noch mal eine Haltung und auch so was eigentlich Sachen, die nicht so gut funktionieren. Also sich da einfach mal ein bisschen einlesen, finde ich hilfreich. Dann ein paar Videos von Jeff Patton finde ich unglaublich gut. Verlinken wir auch mal eins hier in den Shownotes untendrunter. Im Umgang mit Dialog basierter Produktentwicklung würde ich das mal nennen. Das ist eine sehr tolle Quelle.

Jasmine

Was ich auch immer ganz gut finde ist Melissa Perry, glaube ich. Nennt sich die.

Kai

Ähm raus aus der Feature Falle.

Jasmine

Genau. Gibt es mittlerweile auf Deutsch. Wir haben es auch auf Englisch. Spannend. Es gibts mittlerweile auch auf Deutsch. Also ob du jetzt Product Owner bist oder Scrum Master Ich finde diese Bücher und ein bisschen was von Jeff Patton zu sehen lohnt sich für beide Rollen immens. Es kann nämlich auch sein, wenn du Product Owner bist und mit deinem Scrum Master anfängst zu sprechen, dass du merkst, dass dein Scrum Master deine Scrum Masterin nicht so viel Product Ownership Erfahrung hat und dir da nicht so richtig weiterhelfen kann. Dann könnt ihr eine Lerngemeinschaft bilden und euch beide gemeinsam da weiterentwickeln und gucken, wie ihr das Gelernte anwenden könnt in eurem Produkt. Oder eben wo ich ja immer ein großer großer Fan von bin. Such dir einen Mentor. Die Produktwerker haben auch einen ganz tollen Podcast. Zum Beispiel. Es gibt noch andere Menschen in der deutschen Community, die sich eher auf Produkt spezialisieren. Aber such dir da einen Mentor, mit dem du dich ab und zu unterhalten kannst. Ich hatte das am Anfang von meiner Scrum Master Karriere habe ich mit einem Mentor zusammengearbeitet.

Jasmine

Freitags. Es hätte jede Woche sein sollen. Es hat nicht jede Woche stattgefunden, aber wir haben uns unterhalten. Er hat mir immer wieder Tipps und Tricks mit an die Hand gegeben, was ich weiter ausprobieren könnte und so wurde ich zu einem besseren Scrum Master.

Kai

Also da gibt es einen guten Fundus an Methoden, an Haltungen mit denen man rangehen kann. Ich finde auch viel so in dieser ganzen Entrepreneurship Szene kann man sich was abgucken. So das was so Alex Osterwalder da mit Business Model Generation treibt. Da sind viele Impulse drin. Und wenn man so ein bisschen in Richtung Silicon Valley guckt, wie die über Produkte nachdenken, die haben da ja oft eine ganz andere Herangehensweise. Stichwort Fehlerkultur oder so Minimal Viable Product, wie hat der Ried Hoffmann das mal gesagt der ehemalige LinkedIn CTO, “If you aren’t embarassed by your first Product Release then you releases too late.” Also wenn du nicht so ein bisschen angewidert bist von deiner ersten Produkt Auslieferung, hast du zu spät ausgeliefert. Nun, was ja sehr irgendwie aus unserem deutschen oder auch dem Schweizer dem Qualitäts denken irgendwie widerstrebt erst mal auch als eine kulturelle Komponente. Aber so dieser diese ganze Gedankennukleus, das hilft schon dabei, sich da mal darauf einzulassen, weil man eben mit Agilem Produktmanagement doch anders unterwegs ist, als wenn man jetzt aus dem klassischen Projektmanagement kommt und dann eine Product Owner Rolle übernimmt.

Kai

Da ist also schon auch eine gedanklich andere Haltung dahinter. Und da hilft einem natürlich auch wieder das Agile Manifest, Folge Nummer vier in unserem Podcast haben wir mal drüber gesprochen. Ich glaube, es war vier. Und da auch mal reinzuhören. Was ist die Haltung und zum Beispiel die Kunst, die Menge nicht getaner Arbeit zu maximieren ist essenziell. Also wir wollen auf Outcome und nicht auf Output optimieren. Wir wollen nicht noch mehr Output, sondern wir wollen halt einen Impact damit, wollen einen Outcome haben, Dinge die dabei rauskommen. Da fällt mir immer wieder ein wie die Southpark Szene von den Gnomen die die Unterwäsche sammeln irgendwie hier, drei Schritte Geschäftsplan Phase eins Unterhosen sammeln Phase zwei hmm, keine Ahnung. Phase drei Profit und so Gewinne machen. Und oft ist so diese Verknüpfung von wir machen noch ne Story mehr. Wir machen noch irgendwie einen Blogeintrag mehr also Stichwort mehr Unterhosen hinzu und und wie hilft uns das jetzt irgendwie geschäftlich weiter? Macht da draußen irgendwie glücklich? Hat das irgendeine Wirkung? Das ist total unbeantwortet. Und diese Lücke zu schließen Phase zwei ist Product Owner Job.

Jasmine

Genau. Also wenn ich jetzt von diesem klassischen Projektmanager, der in Time in Budget in Scope abliefern möchte, wegkomme, ähm, dann streiche ich meinen Scope weg. Scope Gut und recht. Aber das, was ich ganz am Anfang von einem Projekt oder von der Produktentwicklung als Scope definiert habe, ist zu 80 % fürs Klo. Weil das ist ja der dümmste Moment, wo ich anfangen kann. Dazwischen lerne ich ja ganz viel. Also wie bescheuert ist es denn, meine Metrik drauf anzusetzen, in nem Scope zu liefern, den ich mir an dem dümmsten Moment gewählt habe. Das ist, als würde ich einen Erstklässler fragen Was willst du mal werden? Und er sagt Arzt. Und dann sage ich ihm am Ende seines Studiums: Jetzt hast du aber voll gefehlt. Du bist Chemiker geworden, nicht Arzt.

Kai

Und und da fragen sie natürlich Warum machen wir Menschen das? Nicht weil wir  nicht mehr alle an der Waffel haben. Nein, weil das System das oft begünstigt, dass wir so Sachen tun. Zum Beispiel, weil man gelernt hat aus der Vergangenheit oder weil man Projekt hat, aber so aufgesetzt ist, dass wenn ich nicht am Anfang alles rein kippe, ich nachher keine Chance mehr habe, diese Anforderung noch einzubringen, weil es eben kein dynamisches Backlog gibt, sondern weil ich so vorgegangen bin bisher und das gelernt habe, dass wenn ich am Anfang nicht alles reinkippe, was ich mal brauchen könnte, es dann nicht stattfindet. Und ja, das ist natürlich ein ganz anderes Spiel, was wir da spielen. Deswegen geht Scrum Guide drauf die gültigen Spielregeln für dieses Scrum Spiel, weil es eben eine andere Art der kollaborativen Produktentwicklung ist, die völlig anders funktioniert.

Jasmine

Genau in Time drehen wir auch um. Wir liefern einfach am Ende von jedem Sprint. Wir liefern immer in time, am Ende von jedem Sprint. Und wenn wir das nicht tun, dann kommen wir zu einem ganz wichtigen Punkt, der in unserem Podcast abrundet. Dann kollaborieren wir als Product Owner und als Entwickler und Entwicklerinnen mit unseren Scrum Master zusammen, um zu lernen, wie wir am Ende von jedem Sprint liefern und in Budget. Ja, das ist auch ziemlich einfach zu berechnen. Ein Sprint kostet x Kohle und da kann ich irgendwann mal weiß ich, wie viel ich da ungefähr umsetze. Und dann bin ich auch kontinuierlich in Budget und ich muss halt das Gespräch mit meinen Stakeholdern und Geldgebern führen. Ist es euch das wert oder nicht? Und das Gespräch darf ich vielleicht auch mal mit meinen Entwicklern und Entwicklerinnen führen, wenn ich sage ein Sprint kostet uns 70.000? Du sagst mir, wir wollen hier ein Update machen, dann irgendwas und hier das und das und der Kunde sieht gar nichts davon. Sind die 70.000 dann wirklich gut investiert?

Jasmine

Das kann ja sein, aber es kann auch nein sein. Meine Erfahrung wenn ich diese Budget Diskussion auch mal in das Team nehme, mit den Entwicklern, mit den Entwicklerinnen diskutiere, dann gibt es auf einmal ganz andere Lösungen, weil die Leute ein Bewusstsein dafür bekommen. Wie viel kostet denn das Ganze hier überhaupt? Und es liegt nicht nur an dieser einen Person, die Druck auf andere Personen ausüben muss, damit wir irgendwie im Budget bleiben. Und wenn das jetzt alles ganz viel war und du sagst Hey, an der Stelle sind wir als Organisation nicht, an der Stelle sind wir als Team nicht. Mein Team kann das noch gar nicht so ausspezifizieren etc.. Dann sind wir an dem Punkt von Ja. Da spielt der Scrum Master eine ganz wichtige Rolle rein. Also. Ich habe Teams erlebt, wo der Product Owner und der Scrum Master oder die Product Ownerinnen und der Scrum Masterinnen, sich nicht unterhalten während dem Sprint. Das ist komisch. Weil grundsätzlich stecken die ja die Rahmenbedingungen rund um das System, das ein Produkt baut, und so was wie Teamentwicklung etcetera.

Jasmine

Das gestalten wir gemeinsam aus einer Product Owner Sicht und aus einer Scrum Master Sicht. Das ist wie Ying und Yang, das bedingt sich, das braucht sich. Das heißt, da muss eine ganz, ganz enge Kollaboration stattfinden, so wie der Product Owner die Product Ownerin mit den Endkunden bitte zu reden hat. Hat der Scrum Master oder die Scrum Masterin, mit auch den Product Owner kontinuierlich zu reden und zu sagen: Hey, was könnten wir denn tun? Wie könnten wir es denn verbessern? Wo müssen wir an der Vision schärfen? Wo müssen wir eine Strategie schärfen? Wie geht das Zusammenspiel Product Owner, Entwicklerinnen besser etc.? Also all diese Dinge müssen Scrum Master mit der Product Owner, mit dem Product Owner besprechen und auch die ganzen  organisatorischen Komponenten drumherum. Was brauchen wir denn, damit du als Product Owner, als Product Ownerin in dieser Organisation besser gesehen wirst? Was können wir da machen, damit du effizienter bist, damit du bessere Entscheidungen treffen kannst, schnellere Entscheidungen treffen kannst etc..

Jasmine

Wir freuen uns total, dich oder deine Scrum Master Deine Coaches in unserer Ausbildung im Herbst zu sehen und wir wünschen dir eine wunderbare Woche.