Product Owner Days 2024: Was POs nicht aus dem Scrum Guide erfahren – aber asap wissen sollten!

Summary

Der Sprecher diskutiert die Rolle des Product Owners im Kontext von Scrum und敏捷性, betonend, dass die Bedeutung von 'Product Owner' je nach Organisation und Produkt stark variieren kann. Er betont die Notwendigkeit, kontinuierlich zu lernen und sich im Produktmanagement weiterzubilden, da jeder Kontext einzigartig ist. Der Fokus liegt auf der Bedeutung der Vision, der Kommunikation mit Stakeholdern, der Bedeutung der Entscheidungsfindung und der Notwendigkeit, die Grenzen der Verantwortung des Product Owners zu verstehen. Zudem wird die Bedeutung des Zuhörens und des Fokus auf eine Sache zur Maximierung des Wertes hervorgehoben.

Takeaways

• 😀 Der Sprecher betont die Bedeutung des Kontextes im Product Owner-Role und wie unterschiedliche Kontexte unterschiedliche Aufgaben erfordern.
• 🤔 Es wird darauf hingewiesen, dass der Begriff 'Product Owner' in verschiedenen Organisationen unterschiedlich interpretiert werden kann, was zu Missverständnissen führen kann.
• 📚 Der Sprecher teilt seine Erfahrung, dass es wichtig ist, sich im Bereich Produktmanagement weiterzubilden und nicht nur auf Scrum zu fokusieren.
• 🎯 Er betont die Notwendigkeit, die Lücke zwischen der Produktvision und dem Product Backlog mit geeigneten Tools und Methoden zu schließen.
• 🤝 Der Sprecher plädiert für eine stärkere Zusammenarbeit mit Stakeholdern, um ein besseres Verständnis und Engagement für die gemeinsame Produktentwicklung zu erreichen.
• 💬 Die Bedeutung des Zuhörens bei der Kommunikation mit Stakeholdern wird hervorgehoben, da es zu einer Verbesserung der Beziehungen und Empathie führen kann.
• 🃏 Der Vergleich von Product Owner Arbeit mit einem Pokerspiel unterstreicht, dass Entscheidungen oft unter Unsicherheit getroffen werden müssen.
• 🔍 Der Sprecher erläutert, dass Product Ownern die Vision und den Backlog miteinander verbinden und eine konsistente Geschichte für die Produktentwicklung erzählen müssen.
• 📉 Er diskutiert die Herausforderungen, die mit der Priorisierung des Product Backlogs einhergehen und wie dies oft das Hauptthema in Trainings ist.
• 🤖 Der Sprecher reflektiert über die Rolle des Scrum Masters und wie diese bei der Unterstützung von Product Ownern und der Organisation wichtig sein kann.
• 🔗 Er weist darauf hin, dass es notwendig ist, sowohl in der agilen als auch in der Produktmanagement-Community tätig zu sein, um ein ganzes Bild zu erhalten.
• 🚀 Schließlich betont der Sprecher die kontinuierliche Lernreise des Product Owners und die Bedeutung, sich mit neuen Themen und Ideen aus verschiedenen Quellen fortzuwenden.

Q & A

Was ist der Hauptthema des Vortrags?

Der Vortrag konzentriert sich auf das Verständnis und die Rolle des Product Owners in unterschiedlichen Kontexten, die Herausforderungen und die Bedeutung des kontinuierlichen Lernens im Produktmanagement.

Was bedeutet der Sprecher mit 'Product Owner ist nicht gleich Product Owner'?

Der Sprecher betont, dass die Rolle des Product Owners je nach Unternehmen und Kontext sehr unterschiedlich sein kann, was die Bedeutung und die Verantwortlichkeiten betrifft.

Was sind die Hauptbestandteile des Vortrags?

Der Vortrag beinhaltet persönliche Erfahrungen, die Bedeutung des Produktlebenszyklus, die Unterschiede zwischen Scrum Product Owner und anderen Produktmanagement-Rollen, sowie die Notwendigkeit, sich im Produktmanagement weiterzubilden.

Was versteht der Sprecher unter 'Produktmanagement Bubble'?

Die 'Produktmanagement Bubble' bezieht sich auf die Isolation innerhalb der Produktmanagement-Gemeinschaft, die sich möglicherweise nicht ausreichend mit der agilen Community verbindet und umgekehrt.

Was ist die Rolle des Scrum Masters im Vortrag?

Der Scrum Master wird als Helfer und Unterstützer der Product Owner in der Organisation und bei der Zusammenarbeit mit Stakeholdern dargestellt.

Was bedeutet 'Spielen wir Poker und nicht Schach'?

Dieser Ausdruck soll verdeutlichen, dass die Arbeit des Product Owners mit Unsicherheiten und Wetten einhergeht, im Gegensatz zu Schach, wo alle Informationen klar sind und der nächste Zug logisch folgt.

Wie sieht der Sprecher die Bedeutung der Vision für den Product Owner?

Die Vision ist für den Sprecher wichtig, aber es muss eine Brücke zwischen der Vision und der Product Backlog geschlossen werden, um eine konsistente Produktentwicklungsgeschichte zu erzählen.

Was sind die Schwierigkeiten, die der Sprecher bei der Zusammenarbeit mit Stakeholdern sieht?

Der Sprecher identifiziert die Schwierigkeit, alle Beteiligten auf ein Thema zu fokussieren und die Notwendigkeit, Stakeholder als Teil eines zweiten Teams zu betrachten, das zusammen mit dem Entwicklungsteam arbeitet.

Was ist der Vorschlag des Sprechers für die Arbeit mit Stakeholdern?

Der Sprecher schlägt vor, Stakeholder als ein zweites Scrumteam zu betrachten und regelmäßig Reviews von Entscheidungen durchzuführen, um eine bessere Aligned-Ziele zu erreichen.

Was unterscheidet den Sprecher zwischen der agilen Community und der Produktmanagement-Community?

Der Sprecher sieht zwei getrennte Communitys, die zwar ähnliche Herausforderungen haben, aber unterschiedliche Ansätze und Begriffe verwenden und nicht genügend miteinander kommunizieren.

Was ist der letzte Punkt, den der Sprecher anspricht?

Der letzte Punkt, den der Sprecher anspricht, ist die Notwendigkeit des kontinuierlichen Lernens und die Anerkennung, dass sich der Kontext des Product Owners im Laufe der Zeit verändern wird.

Outlines

00:00

😀 Willkommen und Einführung

Der Sprecher begrüßt die Teilnehmer und betont die Bedeutung der Perspektive im Plenum. Er möchte nicht viel über sich selbst erzählen, sondern den Teilnehmern nach dem Vortrag Gelegenheit geben, Fragen zu stellen. Er erwähnt, dass er während der gesamten Veranstaltung verfügbar ist. Der Sprecher betont die Bedeutung des Product Owner-Konzepts und teilt mit, dass er in den letzten Jahren viel gelernt hat und seine Erfahrungen teilen möchte. Er reflektiert über die unterschiedlichen Rollen und Verantwortlichkeiten von Product Owners in verschiedenen Kontexten.

05:01

🤔 Die Rolle des Product Owners im Kontext

Der Sprecher erklärt, dass der Begriff 'Product Owner' je nach Kontext unterschiedliche Bedeutungen haben kann. Er kritisiert, dass viele Product Owner möglicherweise nicht genug über das tatsächliche Produktmanagement wissen und dass die Rolle des Product Owners in Abhängigkeit zur Scrum-Richtlinie variiert. Der Sprecher betont die Notwendigkeit, die Aufgaben und Verantwortlichkeiten im richtigen Kontext zu betrachten und kritisiert, dass viele/Product Ownerinnen möglicherweise nicht die nötigen Kenntnisse haben, um ihre Aufgaben effektiv auszuführen.

10:02

📈 Produktmanagement und Scrum

Der Sprecher diskutiert die Verbindung zwischen Produktmanagement und Scrum. Er betont, dass Scrum seine Stärken im Produktlebenszyklus am Ende zeigt, wenn das Produkt betrieben und iteriert wird. Der Sprecher kritisiert, dass viele Product Owner nicht genug über moderne Produktmanagement-Techniken wissen und dass sie sich mehr mit diesem Thema auseinandersetzen sollten. Er erwähnt auch die Herausforderungen, die mit der Verantwortung als Product Owner verbunden sind und wie man unter Unsicherheit Entscheidungen treffen muss, vergleicht es mit dem Spielen von Poker anstatt Schach, wo man auf incomplete Informationen agiert.

15:03

🛠️ Produktvision und Backlog-Management

Der Sprecher konzentriert sich auf die Bedeutung der Produktvision und wie diese in die Backlog-Management-Praxis integriert werden kann. Er kritisiert, dass Scrum-Richtlinien zu wenig darüber sagen, wie man von einer Vision zu einem Backlog kommt, und dass viele Product Owner sich zu sehr auf das Priorisieren des Backlogs konzentrieren, anstatt die Lücke zwischen Vision und Backlog zu schließen. Der Sprecher betont die Notwendigkeit, eine konsistente Geschichte für die Produktentwicklung zu erzählen und die Lücke zwischen Vision und Backlog mit sinnvollen Dingen zu füllen.

20:06

🔍 Fokussierung und Stakeholder-Management

Der Sprecher diskutiert die Bedeutung der Fokussierung im Produktmanagement und wie Product Owner ihre Arbeit auf eine Sache reduzieren sollten, um den größten Wert zu maximieren. Er betont, dass die meisten Product Owner zu viele Dinge gleichzeitig erledigen und dadurch den Fokus verlieren. Der Sprecher reflektiert auch über die Rolle des Product Owners in der Beziehungs- und Kommunikationsarbeit mit Stakeholdern und betont die Notwendigkeit, aufzuhören zu überzeugen und zuzuhören, um eine echte Verbindung aufzubauen.

25:07

🤝 Die Rolle des Product Owners in der Zusammenarbeit mit Stakeholdern

Der Sprecher vertieft das Thema der Zusammenarbeit mit Stakeholdern und wie diese als ein zweites Scrum-Team behandelt werden kann. Er betont die Notwendigkeit, Stakeholder zusammenzubringen, um die bestmöglichen Produkt- und Geschäftsentscheidungen zu treffen. Der Sprecher reflektiert über die Herausforderungen, die mit der Arbeit in verschiedenen Communities verbunden sind, und betont die Bedeutung, sowohl in der agilen als auch in der Produktmanagement-Community tätig zu sein, um ein ganzes Bild zu bekommen.

🌟 Kontinuierliches Lernen und Zusammenarbeit

Der Sprecher schließt mit der Betonung des kontinuierlichen Lernens und der Notwendigkeit, sich mit neuen Themen und Ideen auseinanderzusetzen. Er betont, dass die Rolle des Product Owners ständig wechselt und sich verändert und dass es wichtig ist, offen für neue Ideen zu bleiben. Der Sprecher empfiehlt, sich in beiden Welten, der agilen und der Produktmanagement-Community, zu bewegen und nicht in einer einzigen Hinsicht zu verankern. Er betont die Herausforderung und das Potenzial, das in der Rolle des Product Owners liegt und fordert die Teilnehmer auf, aktiv an Fortbildungen teilzunehmen, um ihre Fähigkeiten zu erweitern.

Keywords

💡Product Owner

Ein Product Owner ist eine zentrale Rolle im Scrum-Framework, verantwortlich für die Definition und Priorisierung des Produktbacklogs. Im Video wird betont, dass der Product Owner in verschiedenen Kontexten unterschiedliche Aufgaben und Verantwortlichkeiten hat, abhängig von der Art des Produkts, dem Lebenszyklus und der Branche. Der Product Owner wird auch als eine Art 'Pokerspieler' beschrieben, da er unter Unsicherheiten Entscheidungen trifft.

💡Product Ownership

Product Ownership bezieht sich auf die Praxis des Managements eines Produkts im Rahmen von Scrum. Es umfasst die Fähigkeit, ein Produkt im Einklang mit den Bedürfnissen der Stakeholder zu entwickeln und zu pflegen. Im Video wird darauf hingewiesen, dass viele Product Owner möglicherweise nicht über die notwendigen Kenntnisse im Produktmanagement verfügen und dass dies ein Bereich ist, auf den sich/Product Owner konzentrieren sollten.

💡Scrum

Scrum ist ein Framework für Agile Produktentwicklung, das in der Softwareindustrie weit verbreitet ist. Im Video wird Scrum als Kontext für die Rolle des Product Owners diskutiert, und es wird betont, dass Scrum spezifische Anforderungen an die Product Owner-Rolle stellt, die sich von anderen Produktmanagement-Rollen unterscheiden können.

💡Produktlebenszyklus

Der Produktlebenszyklus beschreibt die verschiedenen Phasen, die ein Produkt von der Idee bis zum Ausscheiden vom Markt durchläuft. Im Video wird erwähnt, dass die Rolle des Product Owners und die damit verbundenen Aufgaben von der Phase im Produktlebenszyklus abhängen können, in der das Produkt sich befindet.

💡Produktvision

Die Produktvision ist eine klare und übergeordnete Beschreibung des Zwecks und der Richtung, die ein Produkt verfolgen soll. Im Video wird darauf hingewiesen, dass die Verbindung zwischen der Produktvision und der tatsächlichen Produktentwicklung (durch den Product Backlog) oft nicht ausreichend klar ist oder untersucht wird.

💡Produktstrategie

Die Produktstrategie ist ein Plan, der die Ziele, Prioritäten und den Weg für die Entwicklung eines Produkts festlegt. Im Video wird erwähnt, dass Product Owner sich mit der Produktstrategie auseinandersetzen müssen, um eine konsistente Geschichte für die Produktentwicklung zu erzählen.

💡Produktbacklog

Das Produktbacklog ist eine Priorisierungsliste von Anforderungen, die für die Entwicklung eines Produkts erfüllt werden müssen. Im Video wird die Bedeutung der effektiven Verwaltung des Produktbacklogs und die Herausforderung, diese in Einklang mit der Produktvision zu bringen, diskutiert.

💡Wettbewerbsanalyse

Die Wettbewerbsanalyse ist der Prozess, bei dem ein Unternehmen den Markt und seine Wettbewerber untersucht, um seine eigene Positionierung und Strategie zu verbessern. Im Video wird die Tatsache hervorhebt, dass Product Owner Entscheidungen unter Unsicherheiten treffen, ähnlich wie bei einem Pokerspiel, wo man Informationen sammelt und dann Wetten eingehen muss.

💡Stakeholder

Stakeholder sind Personen oder Gruppen, die ein Interesse an den Ergebnissen des Projekts oder Produkts haben. Im Video wird die Bedeutung der Kommunikation und des Zuhörens auf Stakeholder hervorgehoben, um eine effektive Produktentscheidung zu treffen.

💡Agiles Framework

Ein agiles Framework wie Scrum bietet eine Sammlung von Regeln und Prinzipien, die die flexible und iterative Entwicklung von Produkten unterstützen. Im Video wird betont, dass das Verständnis und die Anwendung eines agilen Frameworks für Product Owner von entscheidender Bedeutung sind.

💡Produktmanagement

Produktmanagement ist die Disziplin, die sich mit der Verwaltung und dem Marketing eines Produkts befasst, von der Idee bis zur Marktlaunch und -pflege. Im Video wird die Notwendigkeit für Product Owner, fundierte Kenntnisse im Produktmanagement zu haben, hervorgehoben, um erfolgreich zu sein.

💡Kontinuierliche Lernreise

Die kontinuierliche Lernreise beschreibt die ununterbrochene Entwicklung und das Erlernen neuer Fähigkeiten und Kenntnisse. Im Video wird die Bedeutung eines lebenslangen Lernens für Product Owner betont, um mit den sich ständig verändernden Anforderungen und Herausforderungen des Marktes Schritt zu halten.

Highlights

Begrüßung und Einführung: Der Sprecher begrüßt das Publikum und betont die Bedeutung der Perspektive im Plenum.

Persönliche Einführung: Sprecher möchte weniger über seine Person sprechen und stattdessen über sein und das Publikums' Engagement für das Thema.

Produktbesitzer-Rollenverständnis: Es wird ein allgemeines Verständnis von Product Owner und product ownership diskutiert.

Erfahrungsbericht: Der Sprecher teilt seine Erfahrung im Bereich Scrum und Product Owner und betont die kontinuierliche Lernreise.

Kontextabhängigkeit: Der Fokus liegt auf der Bedeutung des jeweiligen Kontextes im Product Owner-Umfeld.

Produktlebenszyklus: Es wird über die unterschiedlichen Phasen im Produktlebenszyklus und die Rolle des Product Owners in diesen Phasen gesprochen.

Produktmanagement-Kenntnisse: Der Sprecher betont die Bedeutung von Produktmanagement-Kenntnissen für Product Owner.

Scrum-Framework-Kritik: Es wird kritisiert, dass das Scrum-Framework nicht ausreichend zwischen Produktvision und Backlog-Management vermittelt.

Produktvision und Backlog: Der Sprecher diskutiert die Lücke zwischen der Festlegung einer Produktvision und der tatsächlichen Backlog-Management-Praxis.

Priorisierung des Backlogs: Es wird auf die Herausforderungen und die Bedeutung der Backlog-Priorisierung eingegangen.

Produktowner-Entscheidungen: Der Sprecher betont, dass die Entscheidungen des Product Owners von der gesamten Organisation akzeptiert werden müssen.

Kommunikation und Beziehungsarbeit: Es wird auf die Wichtigkeit von Kommunikation und Beziehungsaufbau mit Stakeholdern hingewiesen.

Produktowner-Rollenverständnis: Der Sprecher teilt seine Sichtweise auf die Rolle des Product Owners und ihre Verantwortung.

Produktowner-Entwicklung: Es wird über die kontinuierliche Entwicklung und das Lernen im Bereich Product Ownership gesprochen.

Produktmanagement-Community: Der Sprecher fordert eine stärkere Vernetzung zwischen der agilen Community und der Produktmanagement-Community.

Produktowner-Kontinuität: Es wird betont, dass das Wissen und Lernen als Product Owner eine nicht endende Reise ist.

Schwerpunkte für Product Owner: Der Sprecher listet verschiedene Aspekte auf, auf die Product Owner achten sollten, wie z.B. Stakeholder-Management und Vision-Umsetzung.

Einladung zu Trainings: Der Sprecher teilt Informationen über anstehende Trainings und wie man ihn kontaktieren kann.

Transcripts

schön dass Ihr alle da seid ähm ich

hoffe bei Martin sind auch noch ein paar

weil ja weil der Raum so voll wirkt ich

habe eben hinten gesessen die

Perspektive ist ganz anders

freut mich sehr

m ich möchte gar nicht so viel über

meine Person sagen ich halte das so ein

bisschen wie der Holger eben wenn er

euch dafür interessiert was ich so mache

was wir so machen wenn ihr fragen habt

kommt gerne irgendwie nach dem Talk zu

mir ich bin auch die ganzen zwei Tage da

sprecht mich an ähm dann können wir uns

so dieses ganze ich muss euch erzählen

ne wer ich bin und was ich alles so

gemacht habe sparen weil die halbe

Stunde auch durchaus sehr knapp bemessen

ist ich würde euch aber gerne

zumindestens zwei drei Sätze mitgeben

dazu ähm warum es sich vielleicht lohnen

könnte zuzuhören ähm und dass ich was zu

erzählen habe ähm stefan hat das ja

schon angedeutet ne also es gibt ähm

ein gewisses Verständnis von Product

Owner oder von product ownership was ich

auch immer wieder ja draußen beobachten

darf wenn ich Trainings gebe wenn ich

Leute unterstütze wenn ich

ein Mentoring annehme und ich habe halt

vor es lass es jetzt auch 12 13 Jahre

das erste Mal Berührung mit Scrum und

auch mit der Verantwortlichkeit des

Product owners gehabt und glaube dass

ich in diesen letzten Jahren noch

relativ viel gelernt habe was ich damals

nicht wusste also ich bin gewissen Weg

gegangen hab eine gewisse lernreise für

mich selber gemacht jetzt stehen wir da

wo wir halt sind aber wenn ich so ein

bisschen zurückblicke denke ich immer da

war mal eine Abzweigung da habe ich

damals nicht besonders gut

hingeguckt da hätte ich mal besser

hingucken sollen und wenn ihr nur aus

dem Talk zwei drei Punkte mitnimmt wo

ihr denkt da habe ich noch gar nicht so

sehr drüber nachgedacht da lohnt es sich

vielleicht mal hinzugucken und drüber

nachzudenken ob das für mich in meinem

Kontext in meinem meiner Entwicklung die

ich mache für mich relevant sein könnte

dann hätte ich mein Ziel dieses talks

eigentlich schon

erreicht gut viel mehr gar nicht dazu

dann lasst uns direkt in den Inhalt

Starten der holger hat das eben auch

schon so ein bisschen angedeutet aber

ich würde verschiedene Aspekte noch mal

anders

Frame Product Owner ist nicht gleich

Product Owner wenn wir ein Unternehmen

gehen wenn wir in der Organisation

sind und jemand sagt ich bin Product

Owner oder ich mache hier product

ownership in dem scum Team

ist der Aussagegehalt von dieser Antwort

für mich quasi gleich null ich weiß

überhaupt nicht was der macht ne obwohl

ich 12 Jahre product ownership mache und

ihr werdet das auch feststellen wenn

euch draußen mit dem einen oder der

anderen unterhaltet ihr heißt vielleicht

alle Product Owner oder ihr seid Product

Owner in so Teams aber er macht

höchstwahrscheinlich in nur nicht nur in

Nuancen sondern vielleicht auch im

Detail ganz viele andere Dinge das eine

hat mit dem anderen gar nichts zu tun

und es liegt aus meiner Sicht halt daran

dass natürlich der Kontext in dem ihr

unterwegs seid zum Teil komplett anders

ist das kann ein Produkt liegen ne also

ihr habt ein ganz unterschiedliches

Produkt vielleicht habt ihr ein B2B

Produkt die anderen haben B2C Produkt

vielleicht liegt es daran wo ihr mit

eurem Produkt im Produkt Lebenszyklus

euch aufhaltet vielleicht seid ihr

gerade in der Phase wo ihr überhaupt

drüber nachdenkt was ist denn eigentlich

das Kundenproblem ähm was sind denn

Ideen wie wir das Kundenproblem lösen

vielleicht ist seid Ihr aber auch in der

Phase wo euer Produkt eigentlich nur

noch abgewickelt werden muss und ihr ähm

hinterher nur noch guckt dass er eine

gewisse Art von maintenance oder Betrieb

irgendwie dieses Produktes noch macht

die Branche kann komplett anders sein ne

also bin ich in einem regulierten Umfeld

unterwegs oder wie auch immer und hinzu

kommt glaube ich auch noch zumindestens

komme ich auch aus dieser agilen Bubble

und nicht aus der Produktmanagement

Bubble ursprünglich ein Problem kann

auch noch sein dass ähm sag mal so die

agile Community wenn man sie

weitergreift sich auch glaube ich kein

Gefallen damit getan hat zu sagen in

Scrum gibt ist den Scrum Product Owner

und das ist auch ein bisschen das was

Stefan gerade gesagt hat aber in safe in

einem skalierungsf gibt's auch die Rolle

des Product owners der hat aber mit dem

Scrum Product Owner gar nichts zu tun

das heißt ihr werdet auch wenn ihr auf

stellenusschreibung guckt für Product

Owner lesen und wenn ihr eure eene

Aufgaben die ihr gerade habt so ein

bisschen reflektiert dass das eine mit

dem anderen gar nichts zu tun hat und

das ist was was mir am Anfang z.B gar

nicht klar war ne ich habe gedacht ich

kan aus dem Training raus oder habe in

samgide geguckt und habe gedacht völlig

klar was so Po macht ich brauche nur das

machen was man mir beigebracht hat aber

ihr müsst alles was ihr tut zumindestens

aus meiner Sichtweise immer in den

richtigen Kontext setzen und überlegen

was braucht ihr für eure Aufgabe und wie

gestaltet ihr eure Aufgabe tatsächlich

dann irgendwie aus ja und keine Ahnung

es muss auch nicht so sein dass ihr

alles mögt also ich kann aus eigener

Erfahrung heraus sagen ich bin nicht

besonders gut bei Produkten die noch

so weiß ich nicht ein am Anfang sind wo

Markus der wahrscheinlich sehr stark ist

der sitzt hier vorne oder wo wo es viel

und Innovation und wie auch immer geht

wenn wir aber in so eine Phase kommen

von jetzt ist eigentlich klar was das

Kundenproblem ist und wir fangen an zu

bauen und zu iterieren also da wo in

meiner Welt zumindestens Scrum auch

seine Stärken ausspielen kann da bin ich

wieder besonders gut wenn wir am Ende

des produktlebenszyklusses sind und

eigentlich das Produkt nur noch

betrieben werden muss und keine da bin

ich wieder total schlecht also mir

geht's auch darum dass ihr mitnehmt es

ist überall unterschiedlich der Kontext

ist Unterschied und reflektiert

vielleicht auch wo habt ihr eure Stärken

oder wo wollt ihr auch

sein und am auffälligsten finde ich wird

das auch immer bei Stellenausschreibung

auf die ihr guckt und ich würde genau

diese Fragen tatsächlich wenn ihr

irgendwann eine neue Aufgabe übernehmt

auch beim neuen Arbeitgeber in der neuen

Organisation tatsächlich auch

stellen was könnte ich euch noch

erzählen das ist glaube ich ein Punkt

der eben auch schon mal klarer

artikuliert wurde für mich ist Product

Owner eine Verantwortlichkeit eine Rolle

innerhalb des Scrum Frameworks was ich

übernehme aber das was ihr tun solltet

ist Produktmanagement machen vielleicht

agil Produktmanagement machen und was

ich beobachte ist dass ganz viele

Product Owner die ich kennenlerne und

das ist jetzt gar nicht ne ich kenne

euch alle nicht ne aber ich ziehe mich

mal mit damit ein überhaupt keine Ahnung

von Produktmanagement haben oder was

state of the art Produkt ement

eigentlich ist wie man ein Produkt

entwickelt und Gott sei Dank haben wir

hier viele andere Speaker auch die

gerade in diesem Thema vielleicht sogar

noch viel mehr Ahnung haben als ich und

euch ein paar Sachen erzählen können

eine Roadmap nicht wie ein releasepan

behandelt wird sondern eher etwas was

irgendwie auf outcomes aus ist oder wie

ich innovativ unterwegs bin auch der

holger hat ja bestimmte Dingen erzählt

ne und ihr müsst euch zumindestens aus

meiner ganz subjektiven Sicht mit dem

Thema Produktmanagement auseinanders

setzen ja und es reicht nicht zu sagen

ja ich habe jetzt verstanden wie denn

dieses Scrum Framework und die

Verantwortlichkeiten funktionieren weil

das hat Stefan auch gesagt da gibt's

ganz viel dazwischen was überhaupt nicht

erklärt ist da wird auch nicht erklärt

den Entwicklern ähm ob wie sie denn zu

entwickeln haben ne das ist der Sinn und

Zweck eines Frameworks aber Product

Owner product ownerin zumindest in

meiner Beobachtung beschäftigen sich zu

wenig mit Produktmanagement und auch das

ist etwas was ich am Anfang gar nicht

klar hatte sondern gedacht habe ich bin

eigentlich gut unterwegs und es ist eine

Motivation

euch eher auch mit dem Thema

Produktmanagement noch mal

auseinanderzusetzen und da genauer

hinzugucken sage ich aber gleich im

Anschluss auch noch mal ein bisschen was

dazu ein dritten Punkt der mir wichtig

ist und ich habe gerade eben auch mit

mit Markus der vorne sitzt der die

schlusskinot hält ein bisschen schon

gesprochen ähm dass er vielleicht auch

darauf Bezug nehmen wird ähm das Spiel

was wir hier spielen die Aufgabe die wir

haben als Product Owner ja das ist nicht

Schach und was meine ich mit Schach

schach ist wenn ich vor dem Schachbrett

sitze und guck mir an wo die Figuren

stehen dann zu überlegen dass ich alle

Informationen habe weil es ist ja

vollkommen klar wo welche Figur steht

und dann kann ich auf Basis der

vollständigen Information den nächsten

Zug machen sonder das Spiel was wir

spielen ähnelt viel eher als Product

Owner Poker weil wir gehen Wetten ein

unter Unsicherheit also wir haben eine

gewisse Hand oder wir haben gewisse

Informationslage und wissen ja so und so

stehen wir gerade da so stehen wir mit

unserer Entwicklung so ist der Mark

gerade mit unseren Wettbewerbern wie

auch immer und wir wissen aber nicht wie

die anderen auch ihre Züge machen wir

können uns vielleicht

Wahrscheinlichkeiten ausrechnen wie gut

wir da stehen und welche Wette wir

gewinnen können aber es ist eher etwas

wo wir ich glaube es Annie Duke

irgendwie dieses thinking in bets Buch

dass wir in Wetten denken und nicht in

klaren Abfolgen unter vollständiger

Information und ich habe ganz viel

geplant am Anfang ne selbst als

producter ich habe mir überlegt jetzt

machen wir das und dann machen wir

Roadmap und dann kommt die Roadmap

verfällt dann häufig auch eher in

Richtung eines releasepes oder eines

klaren Planes und ich glaube dass das

nicht hilfreich ist sondern wir müssen

uns klar sein dass das alles unter

Unsicherheit passiert und dass es eher

wie ein Pokerspiel anzusehen ist was wir

da tun und mit der Haltung herangehen

als dass wir Schachspieler

sind ein Punkt den ich euch auch noch

mitgeben würde oder versuche

mitzugeben mein oder eins meiner größten

Probleme mit dem Scrum Framework ist

dass dort über produktvision geredet

wird als etwas was da sein muss und

worum sich eine product ownerin ein

Product Owner kümmert und dann gibt es

in der weiß ich nicht zwei Drittel Seite

Beschreibung der Verantwortlichkeit

Product Owner wird sehr viel über

product backlock management geredet ne

was da drunter zu verstehen ist welche

Aufgaben habe nimmt ungefähr auch die

Hälfte glaube ich ein von dieser zwei

Drittel

Seite

und alles was dazwischen passiert was

vielleicht Produktmanagement ist in

unserem Verständnis wie komme ich denn

von der Vision zu einem gescheiten

backlock was steht da drin in welcher

Priorität steht da irgendwas drin wird

nichts gesagt und wenn ihr in einer

Situation seid dass ihr vielleicht sogar

in eurer Organisation es geschafft habt

andere davon zu überzeugen wir brauchen

eine

produktvision und ich ich dann in

manchen Trainings gehört habe ja wenn du

eine Vision hast dann kannst du auch

dein backlock daran orientieren und

priorisieren dann glaube ich stimmt das

nicht das ist viel zu abstrakt was da

als Vision ist ihr müsst die Lücke

zwischen der produktvision und dem

backlock mit geeigneten Tools Methoden

wie auch immer füllen und was eigentlich

ist passiert ist dass ihr immer weiter

ein Funnel kleiner machen werdet ja also

wenn ihr jetzt sagt das ist meine Vision

und dann fangt der euch mit

Produktstrategien zu beschäftigen dann

werden die Option was wir gerade machen

könnten vielleicht immer kleiner und

wenn wir dann vielleicht noch outcome

basierte Roadmaps haben die noch eher in

konkretere Pläne gehen und dann meinfing

für den nächsten Sprint für die nächste

Iteration das ist das Ziel was wir

erreichen wollen und kommt dann die

Geschichte so erzählt auf die

backlockebene wäre meine These ist

priorisieren des backlocks keine Aufgabe

mehr da bleiben nur sechs Sachen

übrig in fast allen Trainings die ich

gebe ist das Hauptthema priorisieren des

Product backlocks in fast allen weil

nämlich der Rest fehlt so und die

Motivation ist dass ihr versucht durch

die Methoden die euch helfen und da

werden der ein oder die andere auch von

den anderen Speakern euch wesentlich

konkretere Tipps geben guckt wie ihr

diese Lücke tatsächlich schließen könnt

um diese Geschichte zu erzählen um nicht

zu sagen ja gut jetzt habe ich immer

noch

7000 Alternativen was ich alles machen

kann und wann ich was machen kann und

ich bin immer noch keinen Schritt weiter

und versteht mich nicht falsch das ist

auch gut dass das Scrum Framework dazu

nichts Konkretes erzählt ja es ist ein

Framework aber es gibt so die Haltung

und manchmal auch bei den

Coaches und Sam mastern ja wir brauchen

ja nur eine Vision oder ein backlock das

ist das was ich eigentlich so ein

bisschen stressen möchte oder wo ich

euch noch mal darauf hinweisen

möchte was habe ich noch jetzt haben wir

in scam so Werte ne also glaub fünf

Stück wenn ich das noch richtig im Kopf

habe ne immer noch Stefan Nick g sei

Dank ne weil die werden ja auch manchmal

gerne vergessen oder nicht so behandelt

in meiner Welt ne ist alles subjektiv

was ich hier erzähle oder meine eigenen

Erfahrung ich glaube das Fokus für die

Product Owner der wichtigste Wert ist

der da drin steht ne da kann man sich

lange drüber streiten können wir auch

beim Kaffee oder beim Bier oder was auch

immer aber ich sehe ganz viele product

ownerinen und Product Owner die sehr

viel Arbeit da reinstecken

meintwegen die backlock Items die Sie

ins backlock packen zu bessern

schöner zu gestalten mehr zu diskutieren

wie auch immer aber dann wenn sie in

eine Iteration starten oder wenn sie in

sprintplan und wie auch immer auf einmal

wieder ein wildes samelsorium von ganz

vielen unterschiedlichen Themen haben

und ich glaube wenn wir es irgendwie

schaffen und ich glaube auch der Felix

Ring Krieg redet heute oder morgen oder

sowas eher aus der kann manw ich glaube

wenn wir es schaffen die Zahl der Dinge

die wir gleichzeitig tun zu minimieren

und maximal vielleicht im oder

optimalerweise nur eine Sache zu machen

nur ein Ziel zu erreichen dass es der

größte Hebel ist den wir als Product

Owner haben um den Wert zu maximieren

ihr könnt bei ganz vielen Dingen überall

viel besser werden aber der Effekt den

ihr erreicht wenn ihr nicht auf einmal

an dem Button arbeitet und dann noch an

dem Menü und dann noch irgendwas im

Backend was irgendwie in dre Monaten

kommt s ihr schafft euer Team euch

selber und alle Beteiligte auf ein Thema

zu fokussieren dass ihr damit den

größten Hebel habt in Hinblick auf

wertmaximierung relativ einfach

ausprobieren ne also in Trainings sehe

ich manchmal ne da werden so Sachen wie

was ist das Name Game glaube ich von

Henrik Nieberg manchmal gemacht und

solche Sachen dann wird das auch relativ

offensichtlich dass er darüber

eigentlich den größte die größte

Möglichkeit habt Mehrwert zu schaffen

und euch auf irgendwas zu fokussieren

und damit auch euer

Team

gut und wenn ich schon so 8 9 10 Punkte

mitgebracht habe muss ich natürlich auch

den Punkt mitbringen wo Tim und ich vor

Jahren irgendwie sehr intensiver

unterwegs

waren ich glaube im scramgide heißt es

immer noch damit der Product Owner

erfolgreich sein kann müssen die

Entscheidung des Product owners von der

gesamten Organisation akzeptiert werden

ja ich glaube ich die die Aussage die da

ist ne also Stefan Nick das ist immer

gut wenn da vorne einer ist der den

scrumgide besser kennt als ich und dann

nickt sehr gut ähm aber das als gefühlt

in meiner Realität sehr wahrscheinlich

in eurer auch völlig utopisch ne die

gesamte Organisation muss alle

Entscheidungen des productonas

akzeptieren das wäre schön wenn es so

ist vielleicht auch gar nicht ne also es

kann ja sein dass jemand auch vielleicht

nicht die Fähigkeiten und Skills hat

diese Verantwortung wahrzunehmen das

Produkt richtig zu entwickeln aber das

ist eigentlich das wie Scrum auf die

Produktentwicklung und auf die

Verantwortlichkeit des producters guckt

und ich glaube da gibt's natürlich nicht

nur schwarz und weiß sondern gibt's

immer auch irgendwas dazwischen und das

wird in den Unterneh in die ich

reingucken kann nie explizit gemacht

also wie weit geht denn mein

Verantwortungsbereich denn eigentlich so

als product ownerin oder als Product

Owner und ich glaube ihr nimmt euch so

viel Zeit

Stress unnötige Diskussion wie auch

immer weg und schiebt die vom Tisch wenn

ihr darüber redet und wenn ihr das ganze

explizit macht und das muss ja auch

nicht ein Stein gemeißelt sein es kann

ja sein dass es sie über Zeit auch

verändert weil ihr mehr

Verantwortlichkeit bekommen hat und ich

habe gesagt Tim und ich haben da lange

drüber diskutiert und manchmal sieht man

das in auch so einer product

unerschulung kann ich euch hinterher

auch mitgeben wir haben damals so ein

Tool entwickelt wo man das selber mit

sich mit seinem Team irgendwie machen

kann nennt sich product ownership

Evolution

Model gibt's aber auch ein Youtube Video

zu ne da brauche ich jetzt heute nicht

so lange drüber zu sprechen und euch zu

erklären wie das ganze funktioniert mir

geht's eher darum macht es explizit weil

jeder der kommt wird eine andere

Vorstellung davon haben ja der wird

sagen ja das darfst noch entscheiden das

darfst aber nicht entscheiden oder hier

möchte ich mitreden oder nicht mitreden

ähm ihr müsst das versuchen allen

Beteiligten ein gemeinsames Bild zu

entwickeln und dann gibt's was

ähm was mich eigentlich die letzten 12

Jahre begleitet und was mir am

allerschwersten ganz persönlich fällt

ähm ich habe so ein bisschen beigebracht

bekommen oder immer da vielleicht auch

eher das Gefühl gehabt ich muss andere

Leute überzeugen und sie ihnen erzählen

was wir denn jetzt zu tun weil ich ohne

ja das Produkt ja ich gehe voran und sag

hier guck mal das die Entscheidung hier

machen wir das ja oder im Zweifel ich

glaub der Roman Pichler erzählt das

häufig in den Trainings zumindestens da

wo ich vorbei dabei war ja die können

auch gerne selber diskutieren als

developmentteam was zu tun ist aber wenn

du als Product Owner das Gefühl hast das

ist jetzt nicht gut investierte Zeit

wenn wir noch eine halbe Stunde darüber

reden dann nimmt der Product Owner die

product ownerin die Entscheidung Stopp

jetzt der Button ist rot und nicht grün

in der Hoffnung dass im nächsten Sprint

den einfach auf Grün verändern können

oder so aber wenn es nicht wertstiftende

Diskussionen gibt ne ist immer besser

wenn das Team natürlich sich selber mit

einbringt vielleicht selber das Problem

löst ne ihr als product own es nicht

vorgibt aber in den Fällen wo das nicht

passiert oder nicht effizient und

effektiv ist habe ich die gesonderte

Mütze auf und sag jetzt treff ich die

Entscheidung jetzt machen wir erstmal

links rum ja so

und dafür müsst ihr den anderen aber

zuhören ihr dürft nicht die jenigen sein

die nur vorne wegen und sagen ja wir

gehen machen jetzt das dann machen wir

das ich habe ja schon eine Roadmap mit

dem habe ich das vereinbart und die

ganze Zeit erzählen denn ihr müsst

zuhören was die anderen sagen wir sind

komplexen Welt ihr könnt das gar nicht

alleine alles entscheiden das wäre für

mich Argument Nummer 1 und Argument

Nummer Z was ich habe ist dass das

natürlich auch auf der Beziehungsebene

was ganz anderes macht also das

Hauptproblem was ich häufig zwischen

product und ein Stakeholdern sehe ist

dass der Stakeholder irgendwas möchte

erzählen will und der Product Owner

kommt und sagt wir haben aber das und

das schon entschieden und erzählt nur

seine Geschichte ich glaube wenn ihr in

einen Modus kommen könntet oder ab und

zu mal dran denkt einfach mal nicht zu

sagen und einfach nur zuzuhören was er

erzählt werdet

ihr eine Reaktion bekommen dass das

Zuhören Schritt für Schritt für Schritt

auch zu einer Veränderung auf der

Beziehungsebene führt und vielleicht

auch zu einer gewissen Form von Empathie

irgendwann weil wenn ihr nur erzählt ich

will was anderes und der will das dann

werdet ihr nie auf einer Beziehungsebene

zusammen arbeiten und ich glaube dass so

Kommunikation und äh Beziehungsarbeit

mit eine der Hauptaufgaben ist da geht's

gar nicht um Prozesse und Tools in der

Product Owner Rolle ihr müsst alle

mitnehmen zusammenbringen auch lateral

zu in vielen Fällen dass er noch nicht

mal bestimmen könnt dass das nach links

und rechts geht und ich glaube dort eher

fragend unterwegs zu sein als Aussagen

treffend ja also ja warum willst das

denn gibt's noch irgendwas was du willst

dann fängt er an weiter zu erzählen oder

sie weiter zu erzählen und noch

irgendwas ihr müsst damit ja nicht

einverstanden sein ne also was er sagt

aber es zu verstehen glaube ich hilft

total weil ihr dann auf der

Beziehungsebene weiterkommt und erst

wenn eine gewisse Form von empathiee

sich entwickelt hat also man das Gefühl

hat dass man irgendwie miteinander

verbunden ist dann glaube ich kann man

auch anfangen seine eigenen Bedürfnisse

zu adressieren und dann werden sie auch

gehört und wir hören viel zu wenig zu

als POS aus meiner Sicht wir reden viel

zu viel ne also auch ich habe viel zu

viel geredet und versucht andere zu

überzeugen und das ist

auch nicht so einfach ist einfach mal

auszuhalten und

zuzuhören was ich vielen product

ownerinnen und Product Owner noch

mitgebe und wo ich gerne auch im

Nachgang kontrovers mit wenn es

interessiert drüber diskutiere ist ich

habe versucht meine Stakeholder oder die

Gruppe der Stakeholder als ein zweites

scrumteam zu betrachten ich glaube dass

eine Eins zu Eins Arbeit Diskussion mit

einzelnen Stakeholdern schwierig ist

weil im Zweifel haben die noch

verschiedene Ziele der eine will das

Unternehmensziel Erreichen der nächste

das der nächste das und ich bin dann

immer nur wie so eine Art Proxy mit dem

einen wird das abgeklärt ich nehme das

zurück dann versuche ich den zweiten das

zu verkaufen weil die drei sich nicht

einigen können oder es keine Align oder

abgestimmte Ziele auf der anderen Ebene

ist bin ich derjenige der versucht da in

irgendeiner Art und Weise zu

vermitteln und ihr müsst versuchen die

Stakeholder

zumindestens in meiner Sicht

zusammenzubringen ja also mit denen

gemeinsam zu reden und ich glaube dass

es helfen kann wenn ihr das macht wenn

ihr eher mit dem Gedanken rangeht weil

das ist auch ein scrumteam ich habe die

Entwickler die Developer als scrumteam

und die liefern das und auf der anderen

Seite habe ich aber meine Stakeholder

und mit den gucke ich wie wir

bestmögliche Produktentscheidung treffen

schrästrich Business Entscheidung

treffen und ich habe tatsächlich auch

schon mit product Ownern und mit Teams

das so gelebt

ähm dass sie tatsächlich mit denam

gemacht

haben jetzt kann man sagen was gucken

die sich in so einem Review an

vielleicht die Qualität der Entscheidung

die wir hier gemeinsam treffen oder die

Art wie wir gemeinsam Entscheidung

treffen warum soll ich nicht eine Art

von entscheidungsreview irgendwie führen

ist dann nur ein anderer Punkt den ich

da betrachte aber vielleicht treffen wir

uns auch regelmäßig und diskutieren

irgendwie in der Art von

refinement wie wollen wir denn mit

welchen Entscheidungen wieder auch immer

vorangehen es hat nämlich noch einen

interessanten Nebeneffekt dass die

Stakeholder viel mehr verstehen wie denn

dieses agile Framework was ihr anwendet

wie das ganze funktioniert weil sie es

nämlich selber mitspielen müssen und ich

glaube dass auch da ein großer

Hindernisgrund ist dass es wenig

Akzeptanz auf Stakeholder Seite gibt wo

ihr wie unterwegs seid und wie ihr das

mit dem Team macht weil die selber gar

nicht in dem Spiel irgendwie mit drin

sind ihr müsst nur aufpassen und

deswegen auch dieses Bild eigentlich

habt ihr das Trikot von beiden an ne

also das ist die Schwierigkeit darin und

ihr müsst euch klar sein wann spiele ich

mit dem Einen oder mit dem anderen Team

oder spiele ich die ganze Zeit mit

beiden Teams und ich würde als weiteren

Tipp auch mein Scrum Master wenn ihr

denn einen habt ne habe ich hier schon

gehört dass hier viele ohne Scrum Master

oder AG Coaches leider unterwegs sind

den zu motivieren euch auch da zu helfen

und euch da auch zu unterstützen weil

das ist dann Arbeit mit der Organisation

oder mit anderen Beteiligten was in

meiner Welt auch squam Master Aufgabe

wäre und dann kommen wir zu einem

vorletzten

Punkt und der ist schon so ein bisschen

auch in der Moderation von dem

Programmbeirat angesprochen worden was

ich ganz spät verstanden habe ist dass

es da draußen eine Produktmanagement

Produkt Bubble Community gibt und es

gibt eine Agi Bubble und Agi Community

und eigentlich beschäftigen sich mit den

gleichen Herausforderungen und die haben

teilweise auch ähnliche Lösung die

benutzen vielleicht andere wordings und

ne also manche Sachen passieren

schneller in der einen Community und

langsamer in der anderen Community aber

die haben viel zu wenig Schnittpunkte

und ihr seid Product Owner und

eigentlich habe ich am Anfang gesagt

seid ihr viel eher in der

Produktmanagement welelt unterwegs oder

solltet es zumindestens aus meiner Sicht

sein und ich finde ihr müsst gucken dass

ihr euch nicht auf eine Seite stellt

also ich habe hier ein hartes Ploier

dafür nicht zu sagen ja ich bin ja in

der ED Community total gut unterwegs und

da gehe ich auf irgendwie

Veranstaltungen ihr werdet

auf internationalen Scrum gatherings

greif mal so groch relativ wenig Produkt

Themen Product Owner Themen oder Speaker

mit Erfahrung über Produktmanagement

treffen ja wenn ihr Glück habt taucht

Stefan auf oder Jeff Patton oder wer

auch immer ne weil die in dem Umfeld

noch unterwegs sind und noch Expertise

haben aber dann wird's irgendwann auch

schon relativ dünn ne und ich würde auch

nicht vorschlagen zu sagen ja gut dann

bewege ich mich nur noch in der

Produktmanagement oder product Bubble

weil ich glaube dann fehlen euch auch

bestimmte Dinge weil natürlich schlaue

Ideen auch in der agilen oder scam Welt

oder Community gibt und ihr müsst gucken

wie ihr da nicht so ein schwarz-weiß

habt und die beiden Communities sich zum

Teil auch gar nicht wirklich sehen und

aneinander vorbeigucken und manchmal

auch dieses unerträgliche Bashing der

anderen Community irgendwie stattfindet

und zu sagen ja die haben alle keine

Ahnung ne also hatten wir gestern in der

Diskussion beim speakers Dinner keine

Ahnung Marti Kagen halt in seinem

inspire Buch über Reviews und plannings

und Iteration und was auch immer alles

spricht aber sagt das sind alles Idioten

aber die Begriffe aus dem Scram

Framework halt einfach benutzt weil das

halt erwartet ne und das führt uns

glaube ich nicht weiter sondern mein

playdoier ist eher zu sagen wir müssen

da mehr zusammenkommen weil ich glaube

dass aus eins und eins dann eher drei

wird anstatt irgendwie sich voneinander

abzugrenzen und der letzte Punkt den ich

habe und der kam ja eben auch schon mal

durch ähm das eins sicher ist und wenn

eins sicher ist was ich so gelernt habe

ist das hört nicht auf sich mit diesen

Themen zu beschäftigen und zu lernen und

ihr müsst euch klar sein wenn ihr diese

verantwortlich als Product Owner

übernehmt dann wird so viel im Laufe der

Zeit passieren also auch einfach

methodisch von Ideen die da draußen sind

dass ihr bereit sein müsst immer weiter

auch zu lernen und euch mit diesen

Themen zu beschäftigen ihr müsst gucken

dass ihr da so versucht irgendwie zu

gucken ja aber jetzt habe ich das

gelernt und dann schlage ich die Brücke

vielleicht auch wieder zu dem Kontext

Thema am Anfang dann wird sich euer

Kontext verändern euer Produkt

vielleicht die Firma das was ihr macht

in der Branche und dann werden

vielleicht ganz andere Dinge total

relevant und ich glaube dass product

Ownern klar sein muss dass es nicht so

ist dass wenn sie in den äh in so ein

Training gehen oder mein Scrum Guide

gucken dass sie verstanden haben wie das

Spiel funktioniert sondern das eine

kontinuierliche sehr wahrscheinlich

nicht endende lernreise irgendwie sein

wird weil immer wieder neue Themen

aufkommen werden und ihr feststellen

werdet da gibt's noch so viel zu

entdecken und aus meiner Sicht macht das

gerade auch diese Herausforderung total

spannend und äh

erstrebenswert ich weiß aber das

Menschen gibt die das nicht mögen oder

auch nicht so gerne haben deswegen

wollte ich das noch mal

anbringen nachdem wir Stefan schon die

Kärtchen hochhält will ich das zumindest

noch einmal kurz zusammenfassen weil ich

gelernt habe wenn man alles mal auf

einer Folie hat dass das manchmal auch

hilfreich sein kann das ist g meine ganz

persönliche Sicht ne also Product Owner

sollten aus meiner Sicht bewusst sein in

welchem Kontext Sie unterwegs sind und

sich bewusst machen dass jeder Kontext

anders ist und sehr wahrscheinlich auch

jeder Product Owner und sollten sich mit

Produktmanagement beschäftigen Fähigkeit

und Fertigkeiten im Produktmanagement

aufbauen und diese Veranstaltung ist ja

wahrscheinlich auch ein guter erster

Schritt viele Dinge kennenzulernen und

nutzt die in den in den nächsten zwei

Tagen ihr spielt Poker und kein

Schach ja also ihr geht mit Wetten und

mit Unsicherheiten um ihr müsst

versuchen das was nicht beschrieben ist

im Scrum Guide zwischen Vision und

backlock mit sinnvollen Dingen zu füllen

damit ihr eine konsistente Geschichte

eurer weiteren Produktentwicklung

erzählen könnt

m versucht den maximalen Fokus auf so

wenig Themen wie möglich herzustellen

für alle Beteiligten euch immer daran zu

orientieren je weniger wir machen Zeit

gleich desto besser ist es im Zuge von

ich bin derjenige der wertmaximierung

für mein Produkt betreiben sollte

m vielleicht ist es schlau drüber

nachzudenken mehr zu fragen und weniger

zu antworten und selber weniger zu reden

ähm guckt mal auf die Stakeholder aber

mit denen nicht eher als Team vielleicht

sogar als samteam in ein gewissen Logik

unterwegs sein könnt in ein gewissen

Regelmäßigkeit mit Rhythmus ähm und auch

nicht im eins zu eins

ähm versucht euch in beiden Welten zu

bewegen und

äh wisst dass sehr wahrscheinlich das

nur

ein ganz kleiner Auszug ist von den

Dingen die ich noch alles hätte erzählen

können ähm und ihr in allen Bereichen

auch noch hättet Weiterlernen können und

dass das Lernen sehr wahrscheinlich auch

nie

ausbleibt

gut wer ein bisschen mehr erfahren will

wir machen paar Trainings das muss ich

nur hinten dran werfen ne also könnt ihr

mich aber auch ansprechen ich versuche

gerade auch so durch ein Training von

der Vision bis zum backlock dazwischen

auch in einem zweitage Training das ein

oder andere product ownerin und Product

Owner

mitzugeben ich gebe die Slides ab ne

braucht er jetzt nicht fotografieren ne

also kriegt auch hier genauso wie beim

Nils 20%

Rabatt und wenn es dann Fragen gibt ich

gucke mal gerade so in Richtung vom

Stefan und

wenn ihr noch Anmerkungen habt zu dem

einen oder anderen Punkt

dann können wir das gerne jetzt noch

machen ist fast Punktlandung ne und auf

die produktwecker muss ich trotzdem noch

kurz hinweisen der Dominik der eben hier

im Programmbeirat war der Macht am 23.4

kostenfreies Live Event über Skalierung

von product ownership wenn er da Lust

habt guckt gerne mal bei uns rein ähm

wir versuchen da so ein bisschen was

anzubieten Impulse zu geben und wenn die

ein oder der andere mal vorbeikommt dann

freuen wir uns danke

euch